So kopierst du eine DynamoDB-Tabelle in ein anderes Konto oder eine andere Region

DynamoDB hat keinen Ein-Klick-„Tabelle-kopieren"-Befehl — nicht in der AWS CLI, nicht in der Console. Eine Tabelle über Konten oder Regionen zu kopieren oder zu migrieren bedeutet, einen von vier Ansätzen zu wählen, jeder mit unterschiedlichen Kompromissen bei Kosten, Ausfallzeit und Genauigkeit. Dieser Leitfaden behandelt alle vier, plus die operativen Stolperfallen, die in der Produktion zubeißen.

Wie kopiere ich eine DynamoDB-Tabelle in ein anderes Konto oder eine andere Region?

Es gibt keinen nativen „Tabelle-kopieren"-Befehl. Wähle einen von vier Ansätzen: ein Scan-+-BatchWriteItem-Skript für kleine, einmalige Kopien, einen S3-Export mit anschließendem Import für große Tabellen, AWS Backup Copy + Restore für konten-übergreifende Umzüge mit voller Genauigkeit oder Global Tables für laufende Live-Replikation. Jeder Restore oder Import erstellt eine neue Tabelle.

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

Ansatz 1: Scan + BatchWriteItem (das Skript)

Die Low-Tech-Option: Lies jedes Item aus der Quelle mit Scan, schreibe es ins Ziel mit BatchWriteItem. Funktioniert konten- und regionsübergreifend, solange dein Skript Credentials für beide Seiten hält (oder eine Rolle im Zielkonto annimmt).

# Skizze — Quelle lesen, Ziel schreiben (Pseudo; im echten Leben das SDK nutzen)
aws dynamodb scan --table-name SourceTable --region us-east-1 \
  > items.json
# Items[] in BatchWriteItem RequestItems transformieren, dann:
aws dynamodb batch-write-item --request-items file://batch.json \
  --region eu-west-1

Die Stolperfallen sind real und leicht zu übersehen:

• BatchWriteItem ist auf 25 Items oder 16 MB pro Aufruf begrenzt — du musst chunken, und ein einzelner Aufruf kann unverarbeitete Items zurückgeben, die du mit exponentiellem Backoff erneut versuchen musst (API-Referenz).
• Writes verbrauchen Write-Kapazität. Auf einem Provisioned-Ziel triffst du schnell auf ProvisionedThroughputExceededException; On-Demand absorbiert mehr, hat aber dennoch Soft-Limits pro Partition. Dimensioniere die Schreiblast gegen die Kapazität des Ziels, bevor du startest.
• Scan liest die ganze Tabelle und meter't jedes Item — die klassischen Query-vs-Scan-Kosten. Eine große Tabelle bedeutet außerdem Paginieren durch LastEvaluatedKey; siehe Paginierung.
• Es ist nicht atomar. Items, die geschrieben werden, während der Scan läuft, können verpasst werden — du bekommst nur einen konsistenten Snapshot, wenn die Quelle ruht.

Am besten für kleine Tabellen oder wenn du während des Kopierens transformieren/filtern musst.

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

Für große Tabellen vermeidet DynamoDBs verwalteter Export nach S3 plus Import aus S3, deine Kapazität überhaupt zu strapazieren.

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

• Erfordert Point-in-Time Recovery (PITR) aktiviert auf der Quelltabelle.
• Verbraucht keine Lesekapazität und hat keine Auswirkung auf die Tabellen-Performance — es liest aus kontinuierlichen Backups, nicht aus der Live-Tabelle.
• Gibt DynamoDB JSON oder Amazon Ion aus. (Das DynamoDB-JSON-Wire-Format ist das, was in S3 landet, mit Type-Tags und allem.)
• Kann in einen S3-Bucket schreiben, der einem anderen Konto gehört und in einer anderen Region liegt.
• Unterstützt vollständige und inkrementelle Exporte (inkrementeller Export GA, Sept 2023).

Import baut dann eine frische Tabelle aus diesen S3-Daten (wie es funktioniert):

• Importiert nur in eine brandneue Tabelle — du kannst nicht in eine bestehende Tabelle importieren.
• Verbraucht keine Write-Kapazität auf der neuen Tabelle.
• Akzeptiert CSV, DynamoDB JSON oder Amazon Ion (optional GZIP/ZSTD-komprimiert).
• Der Quell-S3-Bucket kann in einem anderen Konto oder einer anderen Region liegen.
• Du kannst Secondary Indexes zur Import-Zeit definieren, abfragbar, sobald der Import abgeschlossen ist.

Das ist der sauberste Weg für eine große konten-/regionsübergreifende Migration, bei der ein Point-in-Time-Snapshot (keine Live-Daten) akzeptabel ist.

Ansatz 3: AWS-Backup-Copy + Restore

Wenn du bereits AWS Backup verwendest, kopiert es Recovery-Points über Konten und Regionen (Konten-übergreifender Migrationsleitfaden):

1. Sichere die Quelltabelle in einen Backup-Vault.
2. Kopiere das Backup in einen Vault im Zielkonto/-region.
3. Stelle es in eine neue Tabelle im Ziel wieder her.

Wesentliche Einschränkungen:

• Konten-übergreifendes Copy erfordert, dass beide Konten in derselben AWS Organization sind.
• Restore erstellt immer eine neue Tabelle — du kannst nicht über eine bestehende restoren.
• Global Secondary Indexes werden standardmäßig erhalten (schließe einige oder alle aus, um bei Restore-Zeit/-Kosten zu sparen); du kannst beim Restore keine neuen Indizes hinzufügen.
• Verschlüsselungs-Stolperfalle: Um denselben KMS-Schlüssel bei einem regionsübergreifenden Restore zu behalten, brauchst du einen Multi-Region-Schlüssel; für konten-übergreifend musst du den Schlüssel mit dem Zielkonto teilen. AWS-owned- und AWS-managed-Schlüssel können nicht geteilt oder multi-region gemacht werden (Restore-Verschlüsselungs-Hinweise).

Ansatz 4: Global Tables (Live-Replikation, kein einmaliges Kopieren)

Global Tables replizieren eine Tabelle über Regionen — und nun optional über Konten (Multi-Account GA, Feb 2026) — kontinuierlich. Jedes Replikat bedient Reads und Writes (multi-active), mit asynchroner, last-writer-wins-Replikation (Global-Tables-Docs).

Das ist kein „Kopieren-und-Weggehen"-Tool — es ist laufende Replikation. Verwende es, wenn du willst, dass die Zielregion unbegrenzt synchron bleibt (DR, latenzarme lokale Reads), nicht für eine saubere einmalige Migration. Füge einer bestehenden Tabelle eine Region hinzu, und DynamoDB befüllt die bestehenden Daten ins neue Replikat nach.

Operative Stolperfallen (alle Ansätze)

• GSIs sind nicht kostenlos neu zu erstellen. Ein Scan+Write-Copy trägt keine Indizes mit — du definierst sie auf dem Ziel und sie werden nachbefüllt (und kosten) separat. Plane dein GSI-vs-LSI-Layout auf dem Ziel im Voraus; LSIs können nur zur Tabellen-Erstellungszeit erstellt werden (LSI-Docs).
• Der Kapazitätsmodus überträgt sich nicht. Die neue Tabelle startet mit dem Modus, den du setzt, nicht dem der Quelle. Schätze die Schreiblast vor einem Scan+Write-Copy — dimensioniere ein repräsentatives Item mit dem Item-Size-Rechner und multipliziere mit der Item-Anzahl, um WCUs grob einzuschätzen.
• TTL, Streams, Auto-Scaling und Tags sind Tabellen-Einstellungen, keine Daten — keine der Kopiermethoden trägt sie alle mit. Wende sie auf dem Ziel neu an.
• DynamoDB JSON ≠ reines JSON. Exporte und Scans geben Type-getaggtes DynamoDB-JSON aus; wenn du unterwegs transformierst, übernimmt der DynamoDB-JSON-Konverter das Marshalling.

FAQ

Gibt es einen AWS-CLI-Befehl, um eine DynamoDB-Tabelle zu kopieren? Nein. Es gibt keinen nativen copy-table-Befehl. Du kombinierst scan + batch-write-item oder verwendest die verwalteten Export/Import- oder AWS-Backup-Features.

Wie kopiere ich eine DynamoDB-Tabelle in ein anderes Konto? Drei Optionen: ein Scan+Write-Skript mit Credentials für beide Konten, ein S3- Export/Import (der Bucket kann konten-übergreifend sein) oder AWS-Backup-Copy+Restore (beide Konten müssen in derselben AWS Organization sein).

Wie kopiere ich eine DynamoDB-Tabelle in eine andere Region? S3-Export/Import und AWS Backup unterstützen beide regionsübergreifend. Für laufende regionsübergreifende Synchronisation statt eines einmaligen Kopierens füge ein Global-Table-Replikat in der Zielregion hinzu.

Kopiert das Kopieren einer Tabelle ihre Indizes? S3-Import und AWS-Backup-Restore lassen dich Secondary Indexes behalten/definieren; ein Scan+Write- Skript nicht — du erstellst Indizes auf dem Ziel selbst, und sie befüllen sich separat nach.

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

Eine GUI macht den Umschwung handhabbar: durchsuche Quelle und Ziel nebeneinander, verifiziere Item- Zahlen und ein paar Beispieldatensätze nach dem Kopieren und führe Ad-hoc-Prüfungen aus, ohne ein Scan-Skript zu schreiben. DynoTable herunterladen, um Tabellen über Konten und Regionen hinweg während einer Migration zu inspizieren.