DynamoDB: Table already exists

In breve — L'operazione vuole creare la sua tabella di destinazione, e il nome è già occupato in questo account + region. I ripristini (RestoreTableFromBackup / RestoreTableToPointInTime) generano TableAlreadyExistsException; CreateTable e ImportTable segnalano la stessa situazione come ResourceInUseException. Scegli un nuovo nome di destinazione — i ripristini e gli import non possono mai scrivere in una tabella esistente.

Cosa significa

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

Le operazioni di ripristino e import creano sempre una tabella nuova di zecca — non possono fondersi in o sovrascrivere una tabella attiva. Se il nome di destinazione si risolve in una qualsiasi tabella esistente (qualunque sia il suo stato) nello stesso account e region, la richiesta fallisce subito. Quale eccezione vedi dipende dall'API: la famiglia di ripristino ha la propria TableAlreadyExistsException, mentre CreateTable e ImportTable mostrano la generica ResourceInUseException.

Perché accade

• Ripristinare un backup sul nome originale — l'istinto naturale ("rimetti la mia tabella") collide con la tabella ancora esistente.
• Riesecuzione di un import o di un deployment IaC — un ImportTable riprovato, o uno stack CloudFormation/Terraform/CDK che tenta di creare una tabella che esiste già al di fuori dello stato dello stack.
• Una race crea-poi-riprova — il primo CreateTable è riuscito (o è ancora CREATING) e il retry trova il nome occupato.
• Collisione di ambiente — due stage/ambienti condividono un account ed entrambi vogliono il nome senza prefisso.

Come correggerlo

1. Ripristina su un nuovo nome, poi fai il cut-over — ripristina come my-table-restored, verifica i dati, ri-punta l'applicazione (o elimina la vecchia tabella e ripristina di nuovo con il nome originale una volta sparita):

   aws dynamodb restore-table-from-backup \
     --target-table-name my-table-restored \
     --backup-arn arn:aws:dynamodb:...:table/my-table/backup/...

2. Se intendi sostituire la tabella, elimina prima quella esistente e attendi che l'eliminazione si completi — il nome resta occupato mentre la tabella è nello stato DELETING (un ripristino tentato allora fallisce con TableInUseException; vedi ResourceInUseException per il lato CreateTable).

3. Per gli import, scegli un nome di destinazione inutilizzato — ImportTable crea solo tabelle nuove. Per caricare dati in una tabella esistente, scrivili con BatchWriteItem/PutItem.

4. Per i retry IaC, importa la tabella esistente nello stato dello stack (o rinomina), invece di combattere con la creazione.

5. Controlla cosa esiste effettivamente — aws dynamodb list-tables nella stessa region/account chiarisce se il nome è davvero libero.

Verificare una tabella ripristinata prima del cut-over è il passo sicuro che le persone saltano — l'app desktop DynoTable mette la tabella ripristinata e quella originale affiancate così puoi confrontare lo schema e controllare gli Item prima. E se stai stimando quanto costerà eseguire la tabella ripristinata, il calcolatore dei prezzi DynamoDB copre entrambe le modalità di capacità.

Errori correlati

• ResourceInUseException — la variante CreateTable della stessa collisione.
• Backup not found
• Export requires PITR
• Impara: Backups & point-in-time recovery

References

• RestoreTableFromBackup — Amazon DynamoDB API Reference
• RestoreTableToPointInTime — Amazon DynamoDB API Reference
• CreateTable — Amazon DynamoDB API Reference
• Amazon S3 import validation errors — Amazon DynamoDB Developer Guide

Ultima verifica 2026-07-13 rispetto alla documentazione ufficiale AWS collegata sopra.