DynamoDB: Table already exists

TL;DR — La operación quiere crear su tabla de destino, y el nombre ya está ocupado en esta cuenta + región. Las restauraciones (RestoreTableFromBackup / RestoreTableToPointInTime) lanzan TableAlreadyExistsException; CreateTable e ImportTable informan de la misma situación como un ResourceInUseException. Elige un nuevo nombre de destino — las restauraciones e importaciones nunca pueden escribir en una tabla existente.

Qué significa

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

Las operaciones de restauración e importación siempre crean una tabla completamente nueva — no pueden fusionarse con una tabla activa ni sobrescribirla. Si el nombre de destino se resuelve a cualquier tabla existente (sea cual sea su estado) en la misma cuenta y región, la petición falla de entrada. La excepción que veas depende de la API: la familia de restauración tiene su propio TableAlreadyExistsException, mientras que CreateTable e ImportTable muestran el genérico ResourceInUseException.

Por qué ocurre

Restaurar una copia de seguridad sobre el nombre original — el instinto natural ("recupera mi tabla") choca con la tabla que aún existe.
Volver a ejecutar una importación o un despliegue de IaC — un ImportTable reintentado, o un stack de CloudFormation/Terraform/CDK que intenta crear una tabla que ya existe fuera del estado del stack.
Una carrera de crear-y-reintentar — el primer CreateTable tuvo éxito (o sigue en CREATING) y el reintento encuentra el nombre ocupado.
Colisión de entornos — dos etapas/entornos comparten una cuenta y ambos quieren el nombre sin prefijo.

Cómo solucionarlo

Restaura a un nombre nuevo, luego haz la transición — restaura como my-table-restored, verifica los datos, vuelve a apuntar la aplicación (o borra la tabla antigua y restaura de nuevo con el nombre original una vez que haya desaparecido):
```
aws dynamodb restore-table-from-backup \
  --target-table-name my-table-restored \
  --backup-arn arn:aws:dynamodb:...:table/my-table/backup/...
```
Si tienes intención de reemplazar la tabla, borra primero la existente y espera a que la eliminación se complete — el nombre permanece ocupado mientras la tabla está en estado DELETING (una restauración intentada entonces falla con TableInUseException; consulta ResourceInUseException para el lado de CreateTable).
Para importaciones, elige un nombre de destino sin usar — ImportTable solo crea tablas nuevas. Para cargar datos en una tabla existente, escríbela con BatchWriteItem/PutItem en su lugar.
Para reintentos de IaC, importa la tabla existente al estado del stack (o renombra), en lugar de pelear con la creación.
Comprueba qué existe realmente — aws dynamodb list-tables en la misma región/cuenta resuelve si el nombre está realmente libre.

Verificar una tabla restaurada antes de la transición es el paso seguro que la gente se salta — la aplicación de escritorio DynoTable pone las tablas restaurada y original lado a lado para que compares el esquema y verifiques Items primero. Y si estás estimando cuánto costará ejecutar la tabla restaurada, la calculadora de precios de DynamoDB cubre ambos modos de capacidad.

Errores relacionados

ResourceInUseException — la variante de CreateTable de la misma colisión.
Backup not found
Export requires PITR
Aprende: Backups & point-in-time recovery

References

Última verificación el 2026-07-13 con la documentación oficial de AWS enlazada arriba.