DynamoDB vs ElastiCache

DynamoDB et Amazon ElastiCache stockent tous deux des données dans AWS et sont tous deux qualifiés de rapides, mais ils répondent à des questions différentes. DynamoDB est une base de données serverless entièrement managée faisant office de source de vérité : les écritures sont persistées sur disque et répliquées entre zones de disponibilité. ElastiCache est, selon les termes mêmes d'AWS, « un service web qui facilite la mise en place, la gestion et la montée en charge d'un magasin de données en mémoire distribué ou d'un environnement de cache dans le cloud ». Pour la plupart des systèmes, la comparaison utile n'est pas DynamoDB ou ElastiCache — c'est quel cache, s'il en faut un, se place devant DynamoDB.

Faut-il utiliser DynamoDB ou ElastiCache ?

Utilise DynamoDB pour les données que tu ne peux pas te permettre de perdre : des éléments durables lus et écrits par clé à n'importe quelle échelle. Utilise ElastiCache comme couche en mémoire — cache, état de session, limitation de débit, classements, pub/sub — là où des lectures en microsecondes comptent plus que des garanties de durabilité. Si tu ajoutes un cache spécifiquement pour accélérer DynamoDB, la vraie décision est ElastiCache face à DAX, le cache propre à DynamoDB ; cette comparaison figure plus bas.

DynamoDB vs ElastiCache en un coup d'œil

Caractéristique	DynamoDB	ElastiCache
Rôle	Base de données durable faisant office de source de vérité	Magasin de données en mémoire ou cache managé
Moteurs	Un seul moteur managé (DynamoDB lui-même)	Valkey, Memcached et Redis OSS
Modèle de données	NoSQL clé-valeur et documentaire ; éléments typés jusqu'à 400 Ko	Dépend du moteur — chaînes, hachages, listes, ensembles, ensembles ordonnés et streams sur Valkey/Redis OSS ; clé-valeur simple sur Memcached
Durabilité	Chaque écriture est persistée sur disque et répliquée entre zones de disponibilité	En mémoire par défaut ; les clusters Valkey basés sur des nœuds peuvent activer la durabilité via un journal transactionnel distribué Multi-AZ
Cohérence	Cohérence à terme par défaut ; lectures fortement cohérentes disponibles par requête	Fortement cohérent sur un nœud primaire pour ses propres clés ; les lectures sur réplica peuvent être en retard
Accès	API native (`GetItem`, `Query`, `Scan`, …) plus PartiQL	Commandes du moteur via un endpoint de cache ; aucun langage de requête inter-clés
Modèle de capacité	Stockage sur disque ; évolue avec le volume de données	Limité par la mémoire provisionnée — le mode serverless la fait évoluer pour toi, les clusters basés sur des nœuds se dimensionnent à la main
Modèle opérationnel	Serverless ; rien à provisionner ni à patcher	Cache serverless ou cluster basé sur des nœuds ; AWS gère le provisionnement, la supervision, le remplacement des nœuds et les correctifs
Usage typique	Enregistrements qui doivent survivre	Couches cache-aside, magasins de sessions, limitation de débit, files et pub/sub

Quand DynamoDB est le meilleur choix

Les données doivent survivre. DynamoDB persiste et réplique chaque écriture par défaut. Un cache ElastiCache est d'abord en mémoire ; la durabilité est quelque chose que tu actives sur les clusters Valkey basés sur des nœuds, pas la posture par défaut.
Ton jeu de travail dépasse la mémoire. Le coût de DynamoDB suit le stockage. La capacité d'ElastiCache est limitée par la RAM que tu provisionnes ou par la mémoire jusqu'à laquelle le cache serverless monte en charge.
Tu as besoin de lectures fortement cohérentes. DynamoDB les propose par requête. Un cache placé devant une base de données est par construction en cohérence à terme avec elle.
Tu veux le plan de contrôle AWS. La récupération à un instant précis, les sauvegardes, Streams, IAM et les déclencheurs Lambda sont de la configuration sur une table DynamoDB.

Quand ElastiCache est le meilleur choix

Tu as besoin de lectures en microsecondes. Des données en RAM répondent plus vite qu'un stockage durable, quelle que soit la base derrière.
Tu as besoin de structures de données riches en mémoire. Les ensembles ordonnés, les compteurs, les streams et le pub/sub sont de première classe sur Valkey et Redis OSS, et les modéliser dans un magasin durable demande du travail.
Les données sont réellement éphémères. Les sessions, les fenêtres de limitation de débit et les résultats recalculables correspondent au cycle de vie d'un cache.
Tu mets en cache autre chose que DynamoDB. ElastiCache se place devant n'importe quoi — RDS, Aurora, une API, un index de recherche. DAX n'accélère que DynamoDB.

Les utiliser ensemble

La forme habituelle en production, c'est les deux : DynamoDB détient les enregistrements durables, et une couche en mémoire absorbe les lectures chaudes. ElastiCache le fait comme un étage cache-aside générique pour lequel tu écris du code — ton application interroge le cache, retombe sur DynamoDB, et alimente le cache en cas de miss. DynamoDB propose aussi sa propre alternative, DAX, qui fait la même chose sans le code de cache-aside.

ElastiCache ou DAX devant DynamoDB

C'est la décision que la plupart des équipes prennent réellement, et la documentation AWS y répond plus nettement que les pages marketing.

DAX s'installe sans changement ; ElastiCache est une modification de code. DAX est « compatible avec l'API DynamoDB. Il ne nécessite donc que des modifications fonctionnelles minimes pour être utilisé avec une application existante ». Il réduit les lectures à cohérence à terme « d'un ordre de grandeur, de quelques millisecondes à des microsecondes ». Avec ElastiCache, c'est toi qui écris et possèdes la logique de cache-aside, invalidation comprise.

Quatre raisons documentées pour lesquelles DAX peut ne pas convenir. AWS énumère les cas où DAX n'est pas idéal, et chacun correspond à une charge de travail réelle :

Lectures fortement cohérentes. DAX sert des données en cohérence à terme. Si un chemin de lecture exige ConsistentRead, DAX n'est pas une option pour lui.
Charges à écriture intensive. « Un volume élevé d'écritures entraîne une réplication accrue entre les nœuds DAX d'un cluster », ce qui augmente l'usage des ressources et le risque de disponibilité.
Faible taux de relecture. « DAX est le plus performant lorsque les taux de succès du cache dépassent 90 % ». En dessous, les miss te coûtent des ressources sans t'acheter beaucoup de latence.
Prise en charge des langages. « DAX prend en charge les applications écrites en Go, Java, Node.js, Python et .NET, à l'aide des clients fournis par AWS ». Si ton service est en Rust, Ruby, PHP ou Elixir, DAX t'est de fait fermé et ElastiCache — accessible depuis n'importe quel client Valkey, Redis OSS ou Memcached — est le choix pratique. Cette seule ligne tranche la question plus souvent que n'importe quel benchmark de latence, et elle est facile à manquer.

DAX est par ailleurs « disponible uniquement pour la plateforme EC2-VPC ».

Le piège DAX à connaître avant de modéliser. AWS documente une limitation qui entre en collision avec une habitude de modélisation DynamoDB courante :

Les clusters DAX conservent des métadonnées sur les noms d'attributs des éléments qu'ils stockent. Ces métadonnées sont conservées indéfiniment (même après l'expiration de l'élément ou son éviction du cache). Les applications qui utilisent un nombre non borné de noms d'attributs peuvent, avec le temps, provoquer un épuisement de la mémoire du cluster DAX. Cette limitation s'applique uniquement aux noms d'attributs de premier niveau, pas aux noms d'attributs imbriqués.

Lis ça à la lumière de la façon dont on construit des éléments creux ou hétérogènes. Un élément dont les valeurs sont des horodatages et des UUID ne pose aucun problème. Un élément qui utilise un horodatage, un identifiant de session ou un identifiant de locataire comme nom d'attribut de premier niveau — une forme qui apparaît quand on aplatit une map sur l'élément pour rester interrogeable — fait croître indéfiniment les métadonnées de DAX. Le cache ne récupère pas cet espace quand l'élément est évincé.

L'atténuation relève de la modélisation, pas de la configuration : garde les identifiants dans les valeurs d'attributs et imbrique les clés variables d'un niveau à l'intérieur d'une map, là où la limitation ne s'applique explicitement pas. ElastiCache n'a pas de contrainte équivalente, parce qu'il ne suit pas du tout le schéma de tes éléments.

La durabilité n'est plus une ligne de partage nette. L'affirmation familière selon laquelle ElastiCache ne peut pas être durable est désormais dépassée. AWS documente que « pour les clusters Valkey basés sur des nœuds, tu peux activer la durabilité afin de persister tes données dans un journal transactionnel distribué Multi-AZ », et qu'« avec la durabilité activée, tes données sont protégées même si tous les nœuds de cache tombent en panne ». Cela ne fait pas d'ElastiCache une source de vérité — mais cela signifie que « le cache perd tout au redémarrage » n'est plus un argument que tu peux avancer sans vérifier d'abord le moteur et le type de cluster.

Travailler avec DynamoDB

Quel que soit le cache que tu places devant, DynoTable est un client desktop natif pour parcourir, éditer et interroger les tables DynamoDB en dessous, sur macOS, Windows et Linux. Il lit ta chaîne d'identifiants AWS standard, donc il n'y a rien à migrer. Sa grille décode les clés composites comme USER#123 et marque les attributs TTL, ce qui permet de voir facilement quelles formes d'éléments — et quels noms d'attributs de premier niveau — un cache placé devant la table aurait à retenir.

Pour construire les conditions de clé et les filtres dont ton code d'alimentation de cache a besoin, le DynamoDB Expression Builder gratuit génère une sortie SDK, CLI et PartiQL prête à coller, sans installation. DynoTable est une application commerciale à code source fermé ; cette page décrit ce qu'elle fait, pas comment elle est construite.

FAQ

ElastiCache peut-il remplacer DynamoDB ?

Pas comme source de vérité. ElastiCache est un magasin en mémoire ; même avec la durabilité activée sur un cluster Valkey basé sur des nœuds, il est conçu comme un étage de cache, pas comme la base de données où vivent tes données. DynamoDB persiste et réplique chaque écriture entre zones de disponibilité par défaut.

DAX ou ElastiCache, lequel est le mieux pour DynamoDB ?

DAX si ton application est écrite en Go, Java, Node.js, Python ou .NET, que tes lectures sont en cohérence à terme et que ton taux de succès du cache dépassera 90 % — il est compatible avec l'API, donc tu ne changes presque rien au code. ElastiCache si tu as besoin d'un autre langage, si tu dois mettre en cache autre chose que DynamoDB, ou si tu veux des structures de données en mémoire que DAX ne fournit pas.

ElastiCache perd-il des données au redémarrage d'un nœud ?

Par défaut, il est en mémoire : traite-le donc comme volatil. AWS documente désormais une durabilité optionnelle pour les clusters Valkey basés sur des nœuds, avec persistance dans un journal transactionnel distribué Multi-AZ, si bien que les données survivent même si tous les nœuds de cache tombent en panne. Que ton cache soit volatil ou non dépend du moteur et du type de cluster que tu as choisis.

Voir aussi

Apprends quand utiliser DynamoDB et comment le TTL DynamoDB expire les éléments de type cache.
Compare DynamoDB et Redis pour la question magasin-contre-cache en termes généraux.
Modélise des patterns d'accès durables avec le single-table design.
Télécharger DynoTable pour parcourir, interroger et éditer tes tables DynamoDB.

Références

Dernière vérification le 2026-08-02 par rapport à l'AWS ElastiCache User Guide et à l'AWS DynamoDB Developer Guide officiels. Valkey, Redis OSS et Memcached sont des marques de leurs propriétaires respectifs ; mentionnées ici à des fins d'identification uniquement.