DynamoDB: Table already exists

TL;DR — A operação quer criar sua tabela de destino, e o nome já está em uso nesta conta + region. Restaurações (RestoreTableFromBackup / RestoreTableToPointInTime) lançam TableAlreadyExistsException; CreateTable e ImportTable reportam a mesma situação como um ResourceInUseException. Escolha um novo nome de destino — restaurações e importações nunca podem escrever em uma tabela existente.

O que significa

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

Operações de restauração e importação sempre criam uma tabela totalmente nova — elas não podem mesclar ou sobrescrever uma ao vivo. Se o nome de destino resolve para qualquer tabela existente (seja qual for seu estado) na mesma conta e region, a requisição falha de imediato. Qual exceção você vê depende da API: a família de restauração tem seu próprio TableAlreadyExistsException, enquanto CreateTable e ImportTable apresentam o ResourceInUseException genérico.

Por que acontece

Restaurar um backup sobre o nome original — o instinto natural ("colocar minha tabela de volta") colide com a tabela ainda existente.
Reexecutar uma importação ou deploy de IaC — um ImportTable repetido, ou uma stack CloudFormation/Terraform/CDK que tenta criar uma tabela que já existe fora do estado da stack.
Uma corrida de criar-depois-repetir — o primeiro CreateTable foi bem-sucedido (ou ainda está CREATING) e o retry encontra o nome em uso.
Colisão de ambiente — dois stages/ambientes compartilham uma conta e ambos querem o nome sem prefixo.

Como corrigir

Restaure para um novo nome, depois faça o cutover — restaure como my-table-restored, verifique os dados, reaponte a aplicação (ou exclua a tabela antiga e restaure novamente sob o nome original quando ela sumir):
```
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 até a exclusão completar — o nome permanece em uso enquanto a tabela está no estado DELETING (uma restauração tentada então 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.

Verificar uma tabela restaurada antes do cutover é o passo seguro que as pessoas pulam — o app desktop DynoTable coloca a tabela restaurada e a original lado a lado para que você possa comparar o schema e conferir itens primeiro. E se você está estimando quanto a tabela restaurada custará para rodar, a calculadora de preços do DynamoDB cobre ambos os modos de capacidade.

Erros relacionados

ResourceInUseException — a variante do CreateTable da mesma colisão.
Backup not found
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.