DynamoDB : Table already exists

TL;DR — L'opération veut créer sa table cible, et le nom est déjà pris dans ce compte + cette région. Les restaurations (RestoreTableFromBackup / RestoreTableToPointInTime) lèvent TableAlreadyExistsException ; CreateTable et ImportTable signalent la même situation sous forme de ResourceInUseException. Choisis un nouveau nom cible — les restaurations et les imports ne peuvent jamais écrire dans une table existante.

Ce que ça signifie

TableAlreadyExistsException: A target table with the specified name already exists
ResourceInUseException: Table already exists: my-table

Les opérations de restauration et d'import créent toujours une table entièrement nouvelle — elles ne peuvent pas fusionner avec une table active ni l'écraser. Si le nom cible correspond à une table existante (quel que soit son état) dans le même compte et la même région, la requête échoue d'emblée. L'exception que tu vois dépend de l'API : la famille des restaurations a sa propre TableAlreadyExistsException, tandis que CreateTable et ImportTable remontent la ResourceInUseException générique.

Pourquoi ça arrive

Restaurer une sauvegarde sous le nom d'origine — l'instinct naturel (« remettre ma table en place ») entre en collision avec la table encore existante.
Relancer un import ou un déploiement IaC — un ImportTable réessayé, ou une pile CloudFormation/Terraform/CDK qui tente de créer une table existant déjà en dehors de l'état de la pile.
Une course create-then-retry — le premier CreateTable a réussi (ou est toujours en CREATING) et le retry trouve le nom déjà pris.
Collision d'environnements — deux stages/environnements partagent un compte et veulent tous deux le nom sans préfixe.

Comment le corriger

Restaure sous un nouveau nom, puis bascule — restaure en my-table-restored, vérifie les données, redirige l'application (ou supprime l'ancienne table et restaure à nouveau sous le nom d'origine une fois qu'elle a disparu) :
```
aws dynamodb restore-table-from-backup \
  --target-table-name my-table-restored \
  --backup-arn arn:aws:dynamodb:...:table/my-table/backup/...
```
Si tu comptes remplacer la table, supprime d'abord l'existante et attends que la suppression se termine — le nom reste pris tant que la table est en état DELETING (une restauration tentée à ce moment échoue alors avec TableInUseException ; voir ResourceInUseException pour le côté CreateTable).
Pour les imports, choisis un nom cible inutilisé — ImportTable ne crée que des tables nouvelles. Pour charger des données dans une table existante, écris-les plutôt avec BatchWriteItem/PutItem.
Pour les retries IaC, importe la table existante dans l'état de la pile (ou renomme), plutôt que de te battre contre la création.
Vérifie ce qui existe réellement — aws dynamodb list-tables dans la même région/le même compte tranche la question de savoir si le nom est vraiment libre.

Vérifier une table restaurée avant la bascule est l'étape sûre que les gens sautent — l'application de bureau DynoTable place la table restaurée et la table d'origine côte à côte pour que tu puisses comparer le schéma et contrôler des éléments d'abord. Et si tu estimes ce que la table restaurée coûtera à faire tourner, le calculateur de prix DynamoDB couvre les deux modes de capacité.

Erreurs liées

ResourceInUseException — la variante CreateTable de la même collision.
Backup not found
Export requires PITR
En savoir plus : Sauvegardes et point-in-time recovery

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.