DynamoDB: Tabela já existe

TL;DR — A operação deseja criar sua tabela de destino, e o nome já está em uso nesta conta + região. Restaura (RestoreTableFromBackup / RestoreTableToPointInTime) lança TableAlreadyExistsException; CreateTable e ImportTable relatam a mesma situação que um ResourceInUseException. Escolha um novo nome de destino – restaurações e importações nunca poderão ser gravadas em uma tabela existente.

O que significa

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

# what the engine actually returns, reproduced against DynamoDB Local:
ResourceInUseException: Cannot create preexisting table

As operações de restauração e importação sempre criam uma tabela totalmente nova — elas não podem mesclar ou substituir uma tabela ativa. Se o nome de destino for resolvido para qualquer tabela existente (seja qual for o seu estado) na mesma conta e região, a solicitação falhará antecipadamente. A exceção que você vê depende do API: a família de restauração tem seu próprio TableAlreadyExistsException, enquanto CreateTable e ImportTable apresentam o ResourceInUseException genérico.

Por que isso acontece

Restaurar um backup sobre o nome original — o instinto natural ("colocar minha tabela de volta") colide com a tabela ainda existente.
Executar novamente uma importação ou implantação IaC — uma nova tentativa de ImportTable ou uma pilha CloudFormation/Terraform/CDK que tenta criar uma tabela que já existe fora do estado da pilha.
Uma corrida de criação e nova tentativa — o primeiro CreateTable foi bem-sucedido (ou ainda é CREATING) e a nova tentativa encontra o nome escolhido.
Colisão de ambiente — dois estágios/environments compartilham uma conta e ambos desejam o nome sem prefixo.

Como corrigir

Restaure para um novo nome e, em seguida, corte — restaure como my-table-restored, verifique os dados, reposicione o aplicativo (ou exclua a tabela antiga e restaure novamente com o nome original quando ela desaparecer):
```
aws dynamodb restore-table-from-backup \
  --target-table-name my-table-restored \
  --backup-arn arn:aws:dynamodb:...:table/my-table/backup/...
```
Se você pretende substituir a tabela, exclua a existente primeiro e espere a exclusão terminar — o nome continua ocupado enquanto a tabela está em DELETING (uma restauração tentada nesse momento falha com TableInUseException; veja ResourceInUseException para o lado do CreateTable).
Para importações, escolha um nome de destino não usado — ImportTable só cria tabelas novas. Para carregar dados em uma tabela existente, escreva-os com BatchWriteItem/PutItem em vez disso.
Para retries de IaC, importe a tabela existente para o estado da stack (ou renomeie), em vez de brigar com a criação.
Verifique o que de fato existe — aws dynamodb list-tables na mesma region/conta resolve se o nome está realmente livre.
Sufixe tabelas restauradas com um carimbo de data (orders-20260812-restore) para que o cutover e a limpeza fiquem sem ambiguidade.

Meça no DynoTable

Antes do cutover, abra no DynoTable tanto a tabela original quanto a restaurada — troque com ⌘K e confira itens lado a lado por amostragem. O staging (⌘S) permite testar escritas contra a cópia restaurada sem tocar no tráfego de produção.

Dimensione a tabela restaurada com a calculadora de preços. Troque de conta/Region com ⌘P; Test Connection em Settings → Profiles. Veja Connect to AWS e Install.

Fontes

RestoreTableFromBackup — Amazon DynamoDB API Reference (verificado em 2026-07-13)
CreateTable — Amazon DynamoDB API Reference (verificado em 2026-07-13)

Erros relacionados

ResourceInUseException — a variante do CreateTable da mesma colisão.
Backup não encontrado
Export requires PITR
Aprenda: Backups & point-in-time recovery

Referências

Verificado pela última vez em 2026-07-13 contra a documentação oficial da AWS vinculada acima.