DynamoDB Global Tables

Eine Global Table ist eine einzelne DynamoDB-Tabelle, die über mehrere AWS-Regionen repliziert wird, wobei jedes Replikat beschreibbar ist. DynamoDB hält sie automatisch synchron — du bekommst latenzarme lokale Reads und Writes in jeder Region plus regionsübergreifende Disaster Recovery, ohne deine eigene Replikation zu betreiben.

Im Audit-Log-Szenario verlangt ein EU-Kunde, dass seine Daten in eu-west-1 liegen, während der Rest in us-east-1 läuft. Und als compliance-kritisches Log muss es einen vollständigen Regionsausfall überstehen. Eine Global Table beantwortet beides mit einem einzigen Feature.

Was sind DynamoDB Global Tables?

DynamoDB Global Tables sind eine einzelne Tabelle, die über mehrere AWS-Regionen repliziert wird, wobei jedes Replikat lesbar und beschreibbar ist. DynamoDB hält sie automatisch synchron über asynchrone Replikation mit letztendlicher Konsistenz und löst Konflikte per Last-Writer-Wins auf. Du bekommst latenzarme lokale Reads und Writes pro Region plus regionsübergreifende Disaster Recovery, was DynamoDBs 99,999%-Verfügbarkeits-SLA untermauert.

• Multi-Region, active-active. Jedes Replikat ist voll lesbar und beschreibbar; Writes in einer beliebigen Region propagieren zu den anderen.
• Replikation ist asynchron und regionsübergreifend letztendlich konsistent — typischerweise innerhalb einer Sekunde, aber nicht sofort.
• Konflikte werden per Last-Writer-Wins aufgelöst. Gleichzeitige Writes auf dasselbe Item in zwei Regionen werden auf den jüngsten abgeglichen.
• Es untermauert das 99,999%-Verfügbarkeits-SLA — eine Multi-Region Global Table ist DynamoDBs Konfiguration mit der höchsten Verfügbarkeit.

Das Problem: eine Region reicht nicht

Eine Single-Region-Tabelle hat zwei Grenzen, die das Audit-Log nicht akzeptieren kann. Erstens Data Residency: Die Events eines EU-Kunden müssen in der EU gespeichert werden, aber deine App läuft in den USA. Zweitens Disaster Recovery: Wenn us-east-1 einen Ausfall hat, ist ein Single-Region-Audit-Log für die Dauer weder lesbar noch beschreibbar — genau dann, wenn du den Nachweis darüber, was passiert ist, am dringendsten brauchst.

Eines davon selbst zu bauen — regionsübergreifende Replikation, Failover, Konfliktbehandlung — ist ein großes, fehleranfälliges Projekt. Global Tables machen daraus eine Konfigurationsentscheidung.

Wie Global Tables funktionieren

Du fügst der Tabelle eine Replikat-Region hinzu; DynamoDB erstellt dort eine Kopie und hält alle Replikate synchron. Laut den AWS-DynamoDB-FAQs bieten Global Tables Multi-Region-Replikation mit bis zu 99,999% Verfügbarkeit, und das Replikat jeder Region bedient lokale Reads und Writes.

Zwei Konsistenzregeln definieren das Verhalten:

• Regionsübergreifende Replikation ist asynchron. Ein Write in us-east-1 wird lokal bestätigt und dann nach eu-west-1 propagiert — meist innerhalb einer Sekunde, aber ein Read in der anderen Region direkt nach einem Write sieht ihn möglicherweise noch nicht. (Stark konsistente Reads funktionieren weiterhin, aber nur innerhalb einer einzelnen Region.)
• Konflikte sind Last-Writer-Wins. Wird dasselbe Item in zwei Regionen nahezu gleichzeitig geschrieben, behält DynamoDB den Write mit dem jüngsten Timestamp und verwirft den anderen.

Ein durchgespieltes Beispiel: ein EU-Replikat, das zugleich DR ist

Du fügst eu-west-1 als Replikat der audit-log-Tabelle hinzu. Jetzt:

Die App des EU-Kunden schreibt in das lokale eu-west-1-Replikat und liest daraus — niedrige Latenz und Daten, die in der Region liegen. Dieselbe Replikation, die die Residency erfüllt, fungiert zugleich als Disaster Recovery: Wenn us-east-1 ausfällt, hält das eu-west-1-Replikat weiterhin das vollständige Log und bedient Traffic; du machst ein Failover darauf.

Weil das Audit-Log append-only und pro Tenant partitioniert ist, ist Last-Writer-Wins hier im Grunde kein Thema — die Events eines bestimmten Tenants werden aus einer Region geschrieben und Event-Keys sind eindeutig, sodass zwei Regionen selten um dasselbe Item konkurrieren. Das ist kein Glück; es ist der Grund, warum ein append-only-Log einer der saubersten Anwendungsfälle für Global Tables ist. Ein veränderlicher Zähler hingegen bräuchte unter gleichzeitigen regionsübergreifenden Writes besondere Sorgfalt.

In DynoTable umsetzen

Nachdem du ein Replikat hinzugefügt hast, willst du bestätigen, dass die Daten tatsächlich in der neuen Region gelandet sind und mit der Quelle übereinstimmen — dass das EU-Replikat wirklich die Events von acme hält, mit den richtigen Attributen, und nicht hinterherhinkt.

DynoTable verbindet sich mit jeder Region über deren eigene Credentials, sodass du ein Fenster auf us-east-1 und ein anderes auf eu-west-1 richten und die Items desselben Tenants nebeneinander vergleichen kannst, um die Replikation zu verifizieren.

Du kannst die Queries pro Region, die du gegen jedes Replikat ausführen wirst, im DynamoDB Expression Builder prototypisieren.

Fallstricke und nächste Schritte

• Lies nicht regionsübergreifend deinen eigenen Write. Replikations-Lag bedeutet, dass ein Write in einer Region in einer anderen vielleicht ~eine Sekunde lang nicht erscheint. Schreibe nicht in die USA und lies dann sofort aus der EU und erwarte ihn dort; starke Konsistenz gibt es nur innerhalb einer Region.
• Last-Writer-Wins verwirft Daten stillschweigend. Bei veränderlichen Items, die gleichzeitig in zwei Regionen geschrieben werden, wird der Verlierer ohne Fehler verworfen. Append-only- oder Single-Writer-pro-Item-Designs (wie dieses Audit-Log) vermeiden das Problem; geteilter veränderlicher Zustand braucht ein konfliktbewusstes Design.
• Jedes Replikat kostet. Jede Region speichert eine vollständige Kopie und rechnet ihre eigene Kapazität und ihren eigenen Speicher ab — ein Replikat verdoppelt die Kosten grob. Füge Regionen für einen echten Residency- oder DR-Bedarf hinzu, nicht standardmäßig.
• Backups sind pro Replikat. Eine wiederhergestellte Global Table wird zu einer eigenständigen Tabelle — plane Recovery pro Region. Siehe Backup & Point-in-Time Recovery.

Global Tables schützen davor, eine Region zu verlieren. Die letzte betriebliche Sorge ist der Schutz davor, Daten zu verlieren — ein fehlerhafter Deploy oder ein versehentliches Delete — mit Backup & Point-in-Time Recovery.

DynoTable herunterladen, um dich mit mehreren Regionen zu verbinden und zu verifizieren, dass deine Global-Table-Replikate dieselben Daten halten.