Copier un table DynamoDB vers un autre compte/région

DynamoDB n'a pas de commande « copy table » en un clic — ni dans l'AWS CLI, ni dans la console. Chaque copie est vraiment deux moitiés : sortir les données de la source, et les charger dans un table destination. La première moitié est là où un GUI gagne sa place — un export lossless, filtré, vérifié — tandis que la seconde moitié tourne toujours sur le tooling AWS. Ce guide couvre les deux, et les gotchas opérationnels qui mordent en production.

Comment copier un table DynamoDB vers un autre compte ou une autre région ?

Il n'y a pas de commande native copy-table. Pour la moitié out, tire un export DynamoDB-JSON lossless du table (un clic dans DynoTable, pas de script) ou snapshot-le avec l'export S3 managé. Pour la moitié in, choisis l'approche côté AWS qui fit : un script Scan + BatchWriteItem pour les petites copies one-off, un export-puis-import S3 pour les grands tables, AWS Backup copy

• restore pour les moves cross-account avec full fidelity, ou global tables pour la réplication live ongoing. Chaque restore ou import crée un nouveau table.

Aucune approche n'est universellement « juste » — ça dépend de la taille du table, si tu as besoin d'un snapshot point-in-time ou de données live, et si la destination est un table nouveau ou existant.

La moitié export : tire les données avec DynoTable

Avant qu'un restore puisse arriver, les données doivent quitter la source — et une boucle scan hand-rolled est la partie la plus error-prone d'une petite migration (pages droppées, précision des nombres mangled, type tags strippés trop tôt). DynoTable fait cette moitié en un clic :

• Lossless by design : exporte le full filter match comme DynamoDB-JSON marshallé — la forme wire type-wrapped, qui préserve les grands nombres (> 2⁵³) que le JSON plain corrompt — ou comme NDJSON/CSV quand la cible n'est pas DynamoDB du tout. Vois export to CSV pour les détails de format.
• Scopé, pas all-or-nothing : l'export S3 managé snapshot le table entier ; DynoTable exporte chaque item que ta query matche, streamé directement depuis DynamoDB — donc « copier seulement les items TENANT#42 vers staging » est un filter, pas un script.
• Grands tables bienvenus : les exports se détachent et tournent en background, streamant vers le disque ligne par ligne — un pull multi-gigaoctet survit aux tab switches et reloads d'app.
• Vérification après le load : une fois le table destination up, browse source et target côte à côte, compare les comptes d'items (taille de table & compte d'items), et spot-check des sample records — sans écrire un script de vérification.

La frontière honnête : DynoTable tire les données out et vérifie le résultat — le load dans le table destination tourne sur le tooling AWS (un script d'écriture, import S3, ou Backup restore), couvert ensuite.

Approche 1 : Scan + BatchWriteItem (le script)

Chemin lowest-tech — lis chaque item de la source avec Scan, écris-le vers la destination avec BatchWriteItem. Marche cross-account et cross-region tant que ton script tient des credentials pour les deux côtés (ou assume un rôle dans le compte cible).

# 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

Les gotchas sont réels et faciles à rater :

• BatchWriteItem plafonne à 25 items ou 16 MB par appel — tu dois chunker, et un seul appel peut renvoyer des unprocessed items que tu dois retry avec exponential backoff (API reference).
• Les écritures consomment de la write capacity. Sur une cible provisioned tu frapperas ProvisionedThroughputExceededException vite ; on-demand absorbe plus mais plafonne encore chaque partition à une limite dure de 1 000 WCU / 3 000 RCU. Dimensionne la charge d'écriture contre la capacité de la destination avant de commencer.
• Scan lit tout le table et mesure chaque item — le coût classique Query-vs-Scan. Un grand table veut aussi dire paginer via LastEvaluatedKey ; vois pagination.
• Pas atomique : les items écrits pendant que le scan est in flight peuvent être manqués — tu n'obtiens un snapshot consistent que si la source est quiescent.

Meilleur pour les petits tables ou quand tu as besoin de transformer/filtrer pendant la copie — et si la moitié lecture existe déjà comme export marshallé DynoTable, le script se réduit juste à la boucle chunk-and-write.

Approche 2 : Export vers S3, puis import vers un nouveau table

Pour les grands tables, l'export vers S3 managé de DynamoDB plus l'import depuis S3 évite complètement de marteler ta capacité.

Export snapshot le table vers un bucket S3 (how it works) :

• Requiert point-in-time recovery (PITR) enabled sur le table source.
• Ne consomme pas de read capacity et n'a aucun impact sur la performance du table — il lit depuis les continuous backups, pas le table live.
• Sortie au format DynamoDB JSON ou Amazon Ion. (Le format wire DynamoDB-JSON est ce qui atterrit dans S3, type tags et tout.)
• Peut écrire vers un bucket S3 owned par un autre compte et dans une autre région.
• Supporte les exports full et incremental (incremental export GA, Sept 2023).

Import construit ensuite un table frais depuis ces données S3 (how it works) :

• Importe dans un brand-new table seulement — tu ne peux pas importer dans un table existant.
• Ne consomme pas de write capacity sur le nouveau table.
• Accepte CSV, DynamoDB JSON, ou Amazon Ion (optionnellement compressé GZIP/ZSTD).
• Le bucket S3 source peut être dans un autre compte ou une autre région.
• Tu peux définir des secondary indexes à l'import, queryable dès que l'import complete.

C'est le chemin le plus propre pour une grande migration cross-account/cross-region où un snapshot point-in-time (pas des données live) est acceptable.

Approche 3 : AWS Backup copy + restore

Si tu utilises déjà AWS Backup, il copie les recovery points entre comptes et régions (cross-account migration guide) :

1. Back up le table source dans un backup vault.
2. Copy le backup vers un vault dans le compte/région cible.
3. Restore vers un nouveau table dans la cible.

Contraintes clés :

• La copy cross-account requiert que les deux comptes soient dans la même AWS Organization.
• Restore crée toujours un nouveau table — tu ne peux pas restore par-dessus un existant.
• Les Global secondary indexes sont préservés par défaut (exclus certains ou tous pour économiser sur le temps/coût de restore) ; tu ne peux pas ajouter de nouveaux indexes au restore.
• Gotcha encryption : pour garder la même KMS key sur un restore cross-region tu as besoin d'une multi-region key ; pour cross-account tu dois share la key avec le compte cible. Les keys AWS-owned et AWS-managed ne peuvent pas être shared ni made multi-region (notes sur le chiffrement des restaurations).

Approche 4 : Global tables (réplication live, pas une copie one-time)

Les global tables répliquent un table entre régions — et maintenant optionnellement entre comptes (GA multi-comptes, février 2026) — en continu. N'importe quel replica sert lectures et écritures (multi-active), avec une réplication asynchrone last-writer-wins (documentation des global tables).

Ce n'est pas un outil « copy and walk away » — c'est de la réplication ongoing. Utilise-le quand tu veux que la région destination reste en sync indéfiniment (DR, lectures locales low-latency), pas pour une migration one-time propre. Ajoute une région à un table existant et DynamoDB backfill les données existantes dans le nouveau replica.

Gotchas opérationnels (toutes approches)

• Les GSIs ne sont pas free à recreer. Une copie scan+write ne porte pas les indexes — tu les définis sur la cible et ils backfill (et coûtent) séparément. Planifie ton layout GSI vs LSI sur la destination d'emblée ; les LSIs ne peuvent être créés qu'à la création du table (LSI docs).
• Le capacity mode ne transfer pas. Le nouveau table démarre avec le mode que tu settes, pas celui de la source. Estime la charge d'écriture avant une copie scan+write — dimensionne un item représentatif avec le calculateur de taille d'item et multiplie par le compte d'items pour ballpark les WCUs.
• TTL, streams, auto-scaling et tags sont des table settings, pas des données — aucune des méthodes de copie ne porte tous. Re- applique-les sur la cible.
• DynamoDB JSON ≠ plain JSON. Les exports et scans émettent du DynamoDB-JSON type-tagged ; si tu transformes en route, le convertisseur JSON DynamoDB gère le marshalling.
• Vérifie avant cutover. Compare les comptes d'items et spot-check des records des deux côtés — en te rappelant que le compte de DescribeTable est périmé jusqu'à six heures, donc une cible fraîche peut légitimement reporter zéro.

FAQ

Y a-t-il une commande AWS CLI pour copier un table DynamoDB ? Non. Il n'y a pas de commande native copy-table. Tu combines scan + batch-write-item, ou tu utilises les features managées export/import ou AWS Backup.

Comment copier un table DynamoDB vers un autre compte ? Trois options : un script scan+write avec credentials pour les deux comptes, un export/import S3 (le bucket peut être cross-account), ou AWS Backup copy+restore (les deux comptes doivent être dans la même AWS Organization).

Comment copier un table DynamoDB vers une autre région ? Export/import S3 et AWS Backup supportent tous les deux cross-region. Pour une sync cross-region ongoing plutôt qu'une copie one-time, ajoute un replica global-table dans la région cible.

Est-ce que copier un table copie ses indexes ? L'import S3 et le restore AWS Backup te laissent garder/définir des secondary indexes ; un script scan+write non — tu crées les indexes sur la cible toi-même, et ils backfill séparément.

Puis-je importer dans un table DynamoDB existant ? Non. L'import S3 de DynamoDB et le restore AWS Backup créent tous les deux un nouveau table. Pour merge dans un table existant, utilise un script scan+write.

Puis-je copier seulement une partie d'un table ? Les chemins export/import managés et Backup sont full-table only. Pour un subset, exporte le filter match depuis DynoTable (DynamoDB-JSON marshallé lossless) ou scripte un scan filtré, puis écris le subset vers la cible.

Un GUI rend le cutover sain : tire un export lossless des items exacts que tu bouges, puis browse source et target côte à côte, vérifie les comptes d'items et quelques sample records après la copie, et lance des checks ad hoc sans écrire un script scan. Télécharge DynoTable pour lancer la moitié export-and-verify d'une migration entre comptes et régions.