DynamoDB vs ElastiCache

DynamoDB und Amazon ElastiCache speichern beide Daten in AWS und beiden wird nachgesagt, schnell zu sein — sie beantworten aber unterschiedliche Fragen. DynamoDB ist eine vollständig verwaltete, serverless Datenbank als System of Record: Schreibvorgänge werden auf Festplatte persistiert und über Availability Zones repliziert. ElastiCache ist, in AWS' eigenen Worten, „ein Webservice, der es einfach macht, einen verteilten In-Memory-Datenspeicher oder eine Cache-Umgebung in der Cloud einzurichten, zu verwalten und zu skalieren". Für die meisten Systeme lautet der nützliche Vergleich nicht DynamoDB oder ElastiCache — sondern welcher Cache, wenn überhaupt, vor DynamoDB gehört.

Solltest du DynamoDB oder ElastiCache verwenden?

Verwende DynamoDB für Daten, deren Verlust du dir nicht leisten kannst: dauerhafte Items, die im großen Maßstab per Key gelesen und geschrieben werden. Verwende ElastiCache für eine In-Memory-Schicht — Caching, Session-State, Rate Limiting, Ranglisten, Pub/Sub —, bei der Lesezugriffe im Mikrosekundenbereich wichtiger sind als Dauerhaftigkeitsgarantien. Wenn du einen Cache gezielt hinzufügst, um DynamoDB zu beschleunigen, lautet die eigentliche Entscheidung ElastiCache gegenüber DAX, DynamoDBs eigenem Cache; dieser Vergleich folgt weiter unten.

DynamoDB vs ElastiCache auf einen Blick

Wann DynamoDB die bessere Wahl ist

• Die Daten müssen erhalten bleiben. DynamoDB persistiert und repliziert standardmäßig jeden Schreibvorgang. Ein ElastiCache-Cache ist zuerst In-Memory; Dauerhaftigkeit ist etwas, das du auf node-basierten Valkey-Clustern aktivierst, nicht die Standardhaltung.
• Dein Working Set ist größer als der Arbeitsspeicher. Die Kosten von DynamoDB folgen dem Speicherplatz. Die Kapazität von ElastiCache ist durch das RAM begrenzt, das du bereitstellst, oder durch den Arbeitsspeicher, auf den der serverless Cache skaliert.
• Du brauchst stark konsistente Lesevorgänge. DynamoDB bietet sie pro Anfrage an. Ein Cache vor einer Datenbank ist konstruktionsbedingt letztendlich konsistent mit ihr.
• Du willst die AWS-Control-Plane. Point-in-Time-Recovery, Backups, Streams, IAM und Lambda-Trigger sind Konfiguration an einer DynamoDB-Tabelle.

Wann ElastiCache die bessere Wahl ist

• Du brauchst Lesezugriffe im Mikrosekundenbereich. Daten im RAM antworten schneller als dauerhafter Speicher, egal welche Datenbank dahintersteht.
• Du brauchst reichhaltige In-Memory-Datenstrukturen. Sorted Sets, Zähler, Streams und Pub/Sub sind bei Valkey und Redis OSS erstklassig, und sie in einem dauerhaften Speicher zu modellieren ist Arbeit.
• Die Daten sind wirklich kurzlebig. Sessions, Rate-Limit-Fenster und neu berechenbare Ergebnisse passen zum Lebenszyklus eines Caches.
• Du cachst mehr als nur DynamoDB. ElastiCache sitzt vor allem Möglichen — RDS, Aurora, einer API, einem Suchindex. DAX beschleunigt ausschließlich DynamoDB.

Beide zusammen einsetzen

Die übliche Produktionsform ist beides: DynamoDB hält die dauerhaften Datensätze, und eine In-Memory-Schicht fängt die heißen Lesezugriffe ab. ElastiCache erledigt das als allgemeine Cache-Aside-Ebene, für die du Code schreibst — deine Anwendung prüft den Cache, fällt auf DynamoDB zurück und befüllt den Cache bei einem Miss. DynamoDB liefert außerdem seine eigene Alternative mit, DAX, die das ohne Cache-Aside-Code tut.

ElastiCache oder DAX vor DynamoDB

Das ist die Entscheidung, die die meisten Teams tatsächlich treffen, und die AWS-Dokumentation beantwortet sie schärfer als die Marketingseiten.

DAX ist drop-in; ElastiCache ist eine Codeänderung. DAX ist „API-kompatibel mit DynamoDB. Daher sind nur minimale funktionale Änderungen nötig, um es mit einer bestehenden Anwendung zu verwenden." Es reduziert letztendlich konsistente Lesevorgänge „um eine Größenordnung von einstelligen Millisekunden auf Mikrosekunden". Bei ElastiCache schreibst und verantwortest du die Cache-Aside-Logik selbst, einschließlich der Invalidierung.

Vier dokumentierte Gründe, warum DAX nicht passen könnte. AWS listet die Fälle auf, in denen DAX nicht ideal ist, und jeder davon entspricht einem realen Workload:

• Stark konsistente Lesevorgänge. DAX liefert letztendlich konsistente Daten aus. Wenn ein Lesepfad ConsistentRead verlangt, kommt DAX dafür nicht infrage.
• Schreibintensive Workloads. „Ein hohes Schreibvolumen führt zu verstärkter Replikation zwischen den DAX-Nodes eines Clusters", was Ressourcenverbrauch und Verfügbarkeitsrisiko erhöht.
• Niedrige Wiederhol-Leserate. „DAX arbeitet am besten, wenn die Cache-Trefferquote 90 % übersteigt." Darunter kosten dich Misses Ressourcen, ohne viel Latenz einzukaufen.
• Sprachunterstützung. „DAX unterstützt Anwendungen, die in Go, Java, Node.js, Python und .NET geschrieben sind, unter Verwendung der von AWS bereitgestellten Clients." Wenn dein Service in Rust, Ruby, PHP oder Elixir läuft, ist DAX für dich faktisch verschlossen, und ElastiCache — erreichbar von jedem Valkey-, Redis-OSS- oder Memcached-Client aus — ist die praktische Wahl. Diese eine Zeile entscheidet die Frage häufiger als jeder Latenz-Benchmark, und sie wird leicht übersehen.

DAX ist außerdem „nur für die EC2-VPC-Plattform verfügbar".

Die DAX-Falle, die du vor dem Modellieren kennen solltest. AWS dokumentiert eine Einschränkung, die mit einer verbreiteten DynamoDB-Modellierungsgewohnheit kollidiert:

DAX-Cluster halten Metadaten über die Attributnamen der Items vor, die sie speichern. Diese Metadaten werden unbegrenzt vorgehalten (selbst nachdem das Item abgelaufen ist oder aus dem Cache verdrängt wurde). Anwendungen, die eine unbegrenzte Anzahl von Attributnamen verwenden, können mit der Zeit eine Speichererschöpfung im DAX-Cluster verursachen. Diese Einschränkung gilt nur für Attributnamen auf oberster Ebene, nicht für verschachtelte Attributnamen.

Lies das im Licht dessen, wie Leute dünn besetzte oder heterogene Items bauen. Ein Item, dessen Werte Zeitstempel und UUIDs sind, ist unproblematisch. Ein Item, das einen Zeitstempel, eine Session-ID oder eine Tenant-ID als Attributnamen auf oberster Ebene verwendet — eine Form, die auftaucht, wenn eine Map auf das Item heruntergeklappt wird, um es abfragbar zu halten —, lässt DAX' Metadaten für immer wachsen. Der Cache gibt den Platz nicht wieder frei, wenn das Item verdrängt wird.

Die Abhilfe liegt in der Modellierung, nicht in der Konfiguration: Halte die Bezeichner in Attributwerten und verschachtele variable Keys eine Ebene tiefer in einer Map, wo die Einschränkung ausdrücklich nicht gilt. ElastiCache hat keine entsprechende Beschränkung, weil es dein Item-Schema überhaupt nicht verfolgt.

Dauerhaftigkeit ist keine saubere Trennlinie mehr. Die vertraute Behauptung, ElastiCache könne nicht dauerhaft sein, ist inzwischen überholt. AWS dokumentiert, dass du „für node-basierte Valkey-Cluster Dauerhaftigkeit aktivieren kannst, um deine Daten in einem verteilten transaktionalen Multi-AZ-Log zu persistieren", und dass „bei aktivierter Dauerhaftigkeit deine Daten selbst dann geschützt sind, wenn alle Cache-Nodes ausfallen". Das macht ElastiCache nicht zu einem System of Record — es bedeutet aber, dass „der Cache verliert bei einem Neustart alles" kein Argument mehr ist, das du vorbringen kannst, ohne vorher Engine und Cluster-Typ zu prüfen.

Arbeiten mit DynamoDB

Welchen Cache du auch davorsetzt: DynoTable ist ein nativer Desktop-Client zum Durchsuchen, Bearbeiten und Abfragen der darunterliegenden DynamoDB-Tabellen unter macOS, Windows und Linux. Er liest deine standardmäßige AWS-Credential-Chain, sodass es nichts zu migrieren gibt. Sein Grid dekodiert zusammengesetzte Keys wie USER#123 und markiert TTL-Attribute, was es unkompliziert macht zu sehen, welche Item-Formen — und welche Attributnamen auf oberster Ebene — ein Cache vor der Tabelle vorhalten müsste.

Für den Aufbau der Key Conditions und Filter, die dein Code zum Befüllen des Caches braucht, generiert der kostenlose DynamoDB Expression Builder fertig einfügbare SDK-, CLI- und PartiQL-Ausgaben ohne Installation. DynoTable ist eine Closed-Source-Kommerz-App; diese Seite beschreibt, was sie tut, nicht wie sie gebaut ist.

FAQ

Kann ElastiCache DynamoDB ersetzen?

Nicht als System of Record. ElastiCache ist ein In-Memory-Speicher; selbst mit aktivierter Dauerhaftigkeit auf einem node-basierten Valkey-Cluster ist es als Caching-Schicht konzipiert, nicht als die Datenbank, in der deine Daten leben. DynamoDB persistiert und repliziert standardmäßig jeden Schreibvorgang über Availability Zones.

Ist DAX oder ElastiCache besser für DynamoDB?

DAX, wenn deine Anwendung in Go, Java, Node.js, Python oder .NET geschrieben ist, deine Lesevorgänge letztendlich konsistent sind und deine Cache-Trefferquote 90 % übersteigen wird — es ist API-kompatibel, du änderst also kaum Code. ElastiCache, wenn du eine andere Sprache brauchst, mehr als nur DynamoDB cachen musst oder In-Memory-Datenstrukturen willst, die DAX nicht bietet.

Verliert ElastiCache Daten, wenn ein Node neu startet?

Standardmäßig ist es In-Memory, behandle es also als flüchtig. AWS dokumentiert inzwischen optionale Dauerhaftigkeit für node-basierte Valkey-Cluster, die in ein verteiltes transaktionales Multi-AZ-Log persistiert, sodass Daten selbst dann überleben, wenn alle Cache-Nodes ausfallen. Ob dein Cache flüchtig ist, hängt von der Engine und dem Cluster-Typ ab, den du gewählt hast.

Verwandt

• Lerne, wann man DynamoDB verwendet und wie DynamoDB TTL cache-artige Items verfallen lässt.
• Vergleiche DynamoDB und Redis für die Speicher-gegen-Cache-Frage in allgemeiner Form.
• Modelliere dauerhafte Zugriffsmuster mit Single-Table-Design.
• DynoTable herunterladen, um deine DynamoDB-Tabellen zu durchsuchen, abzufragen und zu bearbeiten.

Referenzen

• Was ist Amazon ElastiCache?
• In-Memory-Beschleunigung mit DynamoDB Accelerator (DAX)
• Was ist Amazon DynamoDB?
• DynamoDB-Lesekonsistenz

Zuletzt verifiziert am 2026-08-02 anhand des offiziellen AWS ElastiCache User Guide und des DynamoDB Developer Guide. Valkey, Redis OSS und Memcached sind Marken der jeweiligen Inhaber; hier nur zur Identifikation genannt.