DynamoDB: La tabla ya existe

TL;DR: la operación quiere crear su tabla de destino y el nombre ya está en esta cuenta + región. Restaura (RestoreTableFromBackup / RestoreTableToPointInTime) lanza TableAlreadyExistsException; CreateTable y ImportTable informan la misma situación que un ResourceInUseException. Elija un nuevo nombre de destino: las restauraciones e importaciones nunca se pueden escribir en una tabla existente.

Qué 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

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.
Añade un sello de fecha a las tablas restauradas (orders-20260812-restore) para que la transición y la limpieza no den lugar a dudas.

Mídelo en DynoTable

Antes de la transición, abre en DynoTable tanto la tabla original como la restaurada — cambia con ⌘K y compara Items lado a lado. El modo de preparación (⌘S) te deja probar escrituras contra la copia restaurada sin tocar el tráfico de producción.

Dimensiona la tabla restaurada con la calculadora de precios. Cambia de cuenta/Región con ⌘P; Test Connection en Ajustes → Perfiles. Consulta Conectar a AWS e Instalar.

Fuentes

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

Errores relacionados

ResourceInUseException — la variante de CreateTable de la misma colisión.
Copia de seguridad no encontrada
Export requires PITR
Aprende: Backups & point-in-time recovery

Referencias

Verificado por última vez el 2026-07-13 contra la documentación oficial de AWS enlazada arriba.