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

DynamoDB n'a aucune commande « copier la table » en un clic — ni dans la CLI AWS, ni dans la console. Copier ou migrer une table entre comptes ou régions signifie choisir l'une de quatre approches, chacune avec des compromis différents de coût, d'interruption et de fidélité. Ce guide couvre les quatre, plus les pièges opérationnels qui mordent en production.

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

Il n'existe aucune commande native pour copier une table. Choisis l'une de quatre approches : un script Scan + BatchWriteItem pour les petites copies ponctuelles, un export vers S3 puis import pour les grosses tables, une copie + restauration AWS Backup pour les déplacements inter-comptes avec fidélité totale, ou les global tables pour une réplication en direct continue. Chaque restauration ou import crée une table neuve.

Situation	Meilleure approche
Petite table, ponctuel, contrôle total	Script Scan + BatchWriteItem
Grosse table, snapshot tolérable	Export S3 → import (crée une table neuve)
Inter-comptes / inter-régions avec restauration	AWS Backup copie + restauration
Réplication en direct continue (pas une copie unique)	Global tables

Aucune approche n'est universellement « la bonne » — cela dépend de la taille de la table, de si tu as besoin d'un snapshot point-in-time ou de données en direct, et de si la destination est une table neuve ou existante.

Approche 1 : Scan + BatchWriteItem (le script)

L'option la moins technologique : lire chaque item de la source avec Scan, l'écrire vers la destination avec BatchWriteItem. Fonctionne en inter-comptes et inter-régions tant que ton script détient les identifiants des deux côtés (ou assume un rôle dans le compte cible).

# Esquisse — lire la source, écrire la cible (pseudo ; utilise le SDK en vrai)
aws dynamodb scan --table-name SourceTable --region us-east-1 \
  > items.json
# transformer Items[] en RequestItems BatchWriteItem, puis :
aws dynamodb batch-write-item --request-items file://batch.json \
  --region eu-west-1

Les pièges sont réels et faciles à manquer :

BatchWriteItem plafonne à 25 items ou 16 Mo par appel — tu dois découper, et un seul appel peut renvoyer des items non traités que tu dois réessayer avec un backoff exponentiel (référence API).
Les écritures consomment de la capacité d'écriture. Sur une cible provisionnée, tu heurteras vite ProvisionedThroughputExceededException ; l'on-demand en absorbe plus mais a quand même des limites souples par partition. Dimensionne la charge d'écriture contre la capacité de la destination avant de commencer.
Scan lit la table entière et mètre chaque item — le coût classique Query-vs-Scan. Une grosse table signifie aussi paginer à travers LastEvaluatedKey ; voir pagination.
Ce n'est pas atomique. Les items écrits pendant que le scan est en cours peuvent être manqués — tu n'obtiens un snapshot cohérent que si la source est au repos.

Le mieux pour les petites tables ou quand tu dois transformer/filtrer pendant la copie.

Approche 2 : Exporter vers S3, puis importer dans une table neuve

Pour les grosses tables, l'export vers S3 managé de DynamoDB plus l'import depuis S3 évitent de marteler ta capacité du tout.

L'export snapshote la table vers un bucket S3 (fonctionnement) :

Nécessite la point-in-time recovery (PITR) activée sur la table source.
Ne consomme pas de capacité de lecture et n'a aucun impact sur les performances de la table — il lit depuis les sauvegardes continues, pas la table en direct.
Produit le format DynamoDB JSON ou Amazon Ion. (Le format de transport DynamoDB-JSON est ce qui atterrit dans S3, balises de type comprises.)
Peut écrire vers un bucket S3 détenu par un autre compte et dans une région différente.
Supporte les exports complets et incrémentaux (export incrémental GA, sept. 2023).

L'import construit ensuite une table fraîche à partir de ces données S3 (fonctionnement) :

Importe dans une table flambant neuve uniquement — tu ne peux pas importer dans une table existante.
Ne consomme pas de capacité d'écriture sur la nouvelle table.
Accepte CSV, DynamoDB JSON ou Amazon Ion (optionnellement compressés GZIP/ZSTD).
Le bucket S3 source peut être dans un autre compte ou une autre région.
Tu peux définir des index secondaires au moment de l'import, interrogeables dès que l'import est terminé.

C'est le chemin le plus propre pour une grosse migration inter-comptes/inter-régions où un snapshot point-in-time (pas des données en direct) est acceptable.

Approche 3 : Copie + restauration AWS Backup

Si tu utilises déjà AWS Backup, il copie les points de récupération entre comptes et régions (guide de migration inter-comptes) :

Sauvegarde la table source dans un coffre de sauvegarde.
Copie la sauvegarde vers un coffre dans le compte/région cible.
Restaure-la vers une nouvelle table dans la cible.

Contraintes clés :

La copie inter-comptes exige que les deux comptes soient dans la même AWS Organization.
La restauration crée toujours une nouvelle table — tu ne peux pas restaurer par-dessus une existante.
Les index secondaires globaux sont préservés par défaut (en exclure certains ou tous pour économiser sur le temps/coût de restauration) ; tu ne peux pas ajouter de nouveaux index à la restauration.
Piège de chiffrement : pour garder la même clé KMS sur une restauration inter-régions, il te faut une clé multi-régions ; pour l'inter-comptes, tu dois partager la clé avec le compte cible. Les clés détenues par AWS et gérées par AWS ne peuvent pas être partagées ni rendues multi-régions (notes de chiffrement de restauration).

Approche 4 : Global tables (réplication en direct, pas une copie unique)

Les global tables répliquent une table entre régions — et désormais optionnellement entre comptes (multi-compte GA, fév. 2026) — en continu. Chaque réplica sert les lectures et écritures (multi-actif), avec une réplication asynchrone last-writer-wins (docs global tables).

Ce n'est pas un outil « copier et oublier » — c'est de la réplication continue. Utilise-le quand tu veux que la région de destination reste synchronisée indéfiniment (DR, lectures locales à faible latence), pas pour une migration unique et propre. Ajoute une région à une table existante et DynamoDB rétro-remplit les données existantes dans le nouveau réplica.

Pièges opérationnels (toutes approches)

Recréer les GSI n'est pas gratuit. Une copie scan+write ne transporte pas les index — tu les définis sur la cible et ils se rétro-remplissent (et coûtent) séparément. Planifie ton agencement GSI vs LSI sur la destination dès le départ ; les LSI ne peuvent être créés qu'au moment de la création de la table (docs LSI).
Le mode de capacité ne se transfère pas. La nouvelle table démarre avec le mode que tu définis, 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 nombre d'items pour estimer les WCU.
TTL, streams, auto-scaling et tags sont des paramètres de table, pas des données — aucune des méthodes de copie ne les transporte toutes. Réapplique-les sur la cible.
DynamoDB JSON ≠ JSON ordinaire. Les exports et scans émettent du DynamoDB-JSON à balises de type ; si tu transformes en route, le convertisseur DynamoDB JSON gère le marshalling.

FAQ

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

Comment copier une table DynamoDB vers un autre compte ? Trois options : un script scan+write avec les identifiants des deux comptes, un export/import S3 (le bucket peut être inter-comptes), ou une copie+restauration AWS Backup (les deux comptes doivent être dans la même AWS Organization).

Comment copier une table DynamoDB vers une autre région ? L'export/import S3 et AWS Backup supportent tous deux l'inter-régions. Pour une synchro inter-régions continue plutôt qu'une copie unique, ajoute un réplica de global table dans la région cible.

Copier une table copie-t-il ses index ? L'import S3 et la restauration AWS Backup te laissent conserver/définir des index secondaires ; un script scan+write non — tu crées les index sur la cible toi-même, et ils se rétro-remplissent séparément.

Puis-je importer dans une table DynamoDB existante ? Non. L'import S3 et la restauration AWS Backup de DynamoDB créent tous deux une nouvelle table. Pour fusionner dans une table existante, utilise un script scan+write.

Un GUI rend la bascule saine : parcours la source et la cible côte à côte, vérifie les comptes d'items et quelques enregistrements d'exemple après la copie, et lance des vérifications ad hoc sans écrire un script de scan. Télécharge DynoTable pour inspecter les tables entre comptes et régions pendant une migration.