DynamoDB-Tabelle in einen anderen Account/eine andere Region kopieren

DynamoDB hat kein „Tabelle kopieren" per Klick — weder in der AWS CLI noch in der Konsole. Jede Kopie besteht in Wahrheit aus zwei Hälften: die Daten herausholen und sie in eine Zieltabelle laden. Die erste Hälfte ist die, in der sich eine GUI bezahlt macht — ein verlustfreier, gefilterter, verifizierter Export — während die zweite Hälfte immer auf AWS-Tooling läuft. Dieser Guide deckt beide ab, plus die operativen Fallen, die in Production zubeißen.

Wie kopiere ich eine DynamoDB-Tabelle in einen anderen Account oder eine andere Region?

Es gibt kein natives Copy-Table-Kommando. Für die Raus-Hälfte ziehst du einen verlustfreien DynamoDB-JSON-Export der Tabelle (ein Klick in DynoTable, kein Skript) oder snapshottest sie mit dem managed S3-Export. Für die Rein-Hälfte wählst du den AWS-seitigen Weg, der passt: ein Scan-+-BatchWriteItem-Skript für kleine einmalige Kopien, ein S3-Export mit anschließendem Import für große Tabellen, AWS Backup copy + restore für Cross-Account-Umzüge mit voller Treue, oder Global Tables für laufende Live-Replikation. Jeder Restore und jeder Import erzeugt eine neue Tabelle.

Kein Weg ist pauschal „richtig" — es hängt an der Tabellengröße, daran, ob du einen Point-in-Time-Snapshot oder Live-Daten brauchst, und daran, ob das Ziel eine neue oder eine bestehende Tabelle ist.

Die Export-Hälfte: die Daten mit DynoTable herausziehen

Bevor irgendein Restore passieren kann, müssen die Daten die Quelle verlassen — und eine handgeschriebene Scan-Schleife ist der fehleranfälligste Teil einer kleinen Migration (verlorene Seiten, zerstörte Zahlengenauigkeit, zu früh entfernte Type-Tags). DynoTable erledigt diese Hälfte mit einem Klick:

• Verlustfrei by design: exportiere den kompletten Filter-Treffer als marshalltes DynamoDB-JSON — die typgewrappte Wire-Form, die große Zahlen (> 2⁵³) erhält, die plain JSON korrumpiert — oder als NDJSON/CSV, wenn das Ziel gar kein DynamoDB ist. Siehe nach CSV exportieren für die Formatdetails.
• Gezielt statt alles-oder-nichts: der managed S3-Export snapshottet die ganze Tabelle; DynoTable exportiert jedes Item, das deine Query trifft, direkt aus DynamoDB gestreamt — „nur die TENANT#42-Items nach Staging kopieren" ist damit ein Filter, kein Skript.
• Große Tabellen willkommen: Exporte lösen sich ab und laufen im Hintergrund, Zeile für Zeile auf die Platte gestreamt — ein Multi-Gigabyte-Pull übersteht Tab-Wechsel und App-Reloads.
• Verifikation nach dem Laden: sobald die Zieltabelle steht, browst du Quelle und Ziel nebeneinander, vergleichst Item-Counts (Tabellengröße & Item-Count) und prüfst Stichproben — ohne ein Verifikationsskript zu schreiben.

Die ehrliche Grenze: DynoTable zieht Daten heraus und verifiziert das Ergebnis — das Laden in die Zieltabelle läuft auf AWS-Tooling (ein Write-Skript, S3-Import oder Backup-Restore), das gleich folgt.

Weg 1: Scan + BatchWriteItem (das Skript)

Der Low-Tech-Pfad — jedes Item mit Scan aus der Quelle lesen und mit BatchWriteItem ins Ziel schreiben. Funktioniert cross-Account und cross-Region, solange dein Skript Credentials für beide Seiten hält (oder eine Rolle im Ziel-Account annimmt).

# Sketch — read source, write target (pseudo; use the SDK in real life)
aws dynamodb scan --table-name SourceTable --region us-east-1 \
  > items.json
# transform Items[] into BatchWriteItem RequestItems, then:
aws dynamodb batch-write-item --request-items file://batch.json \
  --region eu-west-1

Die Fallen sind real und leicht zu übersehen:

• BatchWriteItem deckelt bei 25 Items oder 16 MB pro Call — du musst chunken, und ein einzelner Call kann unprocessed items zurückgeben, die du mit exponentiellem Backoff erneut senden musst (API-Referenz).
• Writes verbrauchen Schreibkapazität. Auf einem provisioned Ziel läufst du schnell in ProvisionedThroughputExceededException; on-demand federt mehr ab, deckelt aber jede Partition weiterhin hart bei 1.000 WCU / 3.000 RCU. Dimensioniere die Schreiblast gegen die Kapazität des Ziels, bevor du startest.
• Scan liest die ganze Tabelle und meters jedes Item — die klassischen Query-vs-Scan-Kosten. Eine große Tabelle heißt außerdem Paginierung über LastEvaluatedKey; siehe Pagination.
• Nicht atomar: Items, die während des laufenden Scans geschrieben werden, können verloren gehen — einen konsistenten Snapshot bekommst du nur, wenn die Quelle ruhig liegt.

Am besten für kleine Tabellen oder wenn du während der Kopie transformieren/filtern willst — und wenn die Lese-Hälfte bereits als marshallter DynoTable-Export vorliegt, schrumpft das Skript auf die Chunk-und-Write-Schleife.

Weg 2: Export nach S3, dann Import in eine neue Tabelle

Für große Tabellen vermeiden DynamoDBs managed Export nach S3 plus Import aus S3 es komplett, deine Kapazität zu hämmern.

Export snapshottet die Tabelle in einen S3-Bucket (wie es funktioniert):

• Erfordert aktiviertes Point-in-Time Recovery (PITR) auf der Quelltabelle.
• Verbraucht keine Lesekapazität und hat keinen Einfluss auf die Tabellenperformance — er liest aus den kontinuierlichen Backups, nicht aus der Live-Tabelle.
• Gibt DynamoDB JSON oder Amazon Ion aus. (Das DynamoDB-JSON-Wire-Format landet in S3, Type-Tags inklusive.)
• Kann in einen S3-Bucket schreiben, der einem anderen Account gehört und in einer anderen Region liegt.
• Unterstützt volle und inkrementelle Exporte (inkrementeller Export GA, Sept. 2023).

Import baut daraus eine frische Tabelle (wie es funktioniert):

• Importiert nur in eine brandneue Tabelle — in eine bestehende geht es nicht.
• Verbraucht keine Schreibkapazität auf der neuen Tabelle.
• Akzeptiert CSV, DynamoDB JSON oder Amazon Ion (optional GZIP/ZSTD-komprimiert).
• Der Quell-S3-Bucket darf in einem anderen Account oder einer anderen Region liegen.
• Du kannst Secondary Indexes zur Import-Zeit definieren; sie sind abfragbar, sobald der Import durch ist.

Das ist der sauberste Pfad für eine große Cross-Account-/Cross-Region-Migration, bei der ein Point-in-Time-Snapshot (statt Live-Daten) akzeptabel ist.

Weg 3: AWS Backup copy + restore

Wenn du ohnehin AWS Backup nutzt: es kopiert Recovery Points über Accounts und Regionen hinweg (Cross-Account-Migrationsguide):

1. Sichere die Quelltabelle in einen Backup-Vault.
2. Kopiere das Backup in einen Vault im Ziel-Account/der Ziel-Region.
3. Restore es in eine neue Tabelle im Ziel.

Die wichtigsten Einschränkungen:

• Cross-Account-Copy verlangt, dass beide Accounts in derselben AWS Organization liegen.
• Ein Restore erzeugt immer eine neue Tabelle — über eine bestehende geht es nicht.
• Global Secondary Indexes bleiben standardmäßig erhalten (du kannst einzelne oder alle ausschließen, um Restore-Zeit und -Kosten zu sparen); neue Indexes kannst du beim Restore nicht hinzufügen.
• Encryption-Falle: um bei einem Cross-Region-Restore denselben KMS-Key zu behalten, brauchst du einen Multi-Region-Key; cross-Account musst du den Key teilen. AWS-owned und AWS-managed Keys lassen sich weder teilen noch multi-region machen (Restore-Encryption-Hinweise).

Weg 4: Global Tables (Live-Replikation, keine einmalige Kopie)

Global Tables replizieren eine Tabelle über Regionen hinweg — inzwischen optional auch über Accounts (Multi-Account GA, Feb. 2026) — und zwar kontinuierlich. Jede Replica bedient Reads und Writes (multi-active), mit asynchroner Last-Writer-wins-Replikation (Global-Tables-Docs).

Das ist kein „einmal kopieren und vergessen"-Werkzeug, sondern laufende Replikation. Nimm es, wenn die Zielregion dauerhaft synchron bleiben soll (DR, latenzarme lokale Reads), nicht für eine saubere einmalige Migration. Fügst du einer bestehenden Tabelle eine Region hinzu, backfillt DynamoDB die vorhandenen Daten in die neue Replica.

Operative Fallen (alle Wege)

• GSIs neu anzulegen ist nicht gratis. Eine Scan-+-Write-Kopie trägt keine Indexes — du definierst sie auf dem Ziel, und sie backfillen (und kosten) separat. Plane dein GSI-vs-LSI-Layout auf dem Ziel vorab; LSIs lassen sich nur zur Tabellenerstellung anlegen (LSI-Docs).
• Der Capacity-Modus wandert nicht mit. Die neue Tabelle startet mit dem Modus, den du setzt, nicht mit dem der Quelle. Schätze die Schreiblast vor einer Scan-+-Write-Kopie ab — dimensioniere ein repräsentatives Item im Item-Size-Rechner und multipliziere mit dem Item-Count, um WCUs zu überschlagen.
• TTL, Streams, Auto-Scaling und Tags sind Tabelleneinstellungen, keine Daten — keine der Kopiermethoden trägt sie alle mit. Setze sie auf dem Ziel neu.
• DynamoDB JSON ≠ plain JSON. Exporte und Scans geben typgetaggtes DynamoDB-JSON aus; transformierst du unterwegs, übernimmt der DynamoDB-JSON-Konverter das Marshalling.
• Vor dem Cutover verifizieren. Vergleiche Item-Counts und prüfe Stichproben auf beiden Seiten — und denk daran, dass der Count aus DescribeTable bis zu sechs Stunden alt sein kann, ein frisches Ziel also legitim null melden darf.

FAQ

Gibt es ein AWS-CLI-Kommando, um eine DynamoDB-Tabelle zu kopieren? Nein. Es gibt kein natives copy-table. Du kombinierst scan + batch-write-item oder nutzt den managed Export/Import bzw. AWS Backup.

Wie kopiere ich eine DynamoDB-Tabelle in einen anderen Account? Drei Optionen: ein Scan-+-Write-Skript mit Credentials für beide Accounts, ein S3-Export/Import (der Bucket darf cross-Account sein), oder AWS Backup copy+restore (beide Accounts müssen in derselben AWS Organization liegen).

Wie kopiere ich eine DynamoDB-Tabelle in eine andere Region? S3-Export/Import und AWS Backup unterstützen beide cross-Region. Für laufenden Cross-Region-Sync statt einer einmaligen Kopie fügst du eine Global-Table-Replica in der Zielregion hinzu.

Kopiert das Kopieren einer Tabelle auch ihre Indexes? S3-Import und AWS-Backup-Restore lassen dich Secondary Indexes behalten bzw. definieren; ein Scan-+-Write-Skript nicht — die Indexes legst du auf dem Ziel selbst an, und sie backfillen separat.

Kann ich in eine bestehende DynamoDB-Tabelle importieren? Nein. DynamoDBs S3-Import und der AWS-Backup-Restore erzeugen beide eine neue Tabelle. Um in eine bestehende Tabelle zu mergen, nimmst du ein Scan-+-Write-Skript.

Kann ich nur einen Teil einer Tabelle kopieren? Der managed Export/Import und der Backup-Pfad sind nur ganztabellig. Für eine Teilmenge exportierst du den Filter-Treffer aus DynoTable (verlustfreies marshalltes DynamoDB-JSON) oder skriptest einen gefilterten Scan und schreibst die Teilmenge ins Ziel.

Eine GUI macht den Cutover erträglich: zieh einen verlustfreien Export genau der Items, die du umziehst, browse dann Quelle und Ziel nebeneinander, verifiziere Item-Counts und ein paar Stichproben nach der Kopie und fahr Ad-hoc-Checks, ohne ein Scan-Skript zu schreiben. Lade DynoTable herunter, um die Export-und-Verifizieren-Hälfte einer Migration über Accounts und Regionen hinweg zu fahren.