Cómo copiar una tabla de DynamoDB a otra cuenta o región

DynamoDB no tiene un comando «copiar tabla» de un clic — ni en la AWS CLI, ni en la consola. Copiar o migrar una tabla entre cuentas o regiones significa elegir uno de cuatro enfoques, cada uno con distintos compromisos de coste, tiempo de inactividad y fidelidad. Esta guía cubre los cuatro, además de los detalles operativos que muerden en producción.

¿Cómo copio una tabla de DynamoDB a otra cuenta o región?

No existe un comando nativo para copiar tablas. Elige uno de cuatro enfoques: un script de Scan + BatchWriteItem para copias pequeñas y puntuales, una exportación a S3 seguida de importación para tablas grandes, copia + restauración de AWS Backup para migraciones entre cuentas con fidelidad total, o tablas globales para replicación en vivo continua. Cada restauración o importación crea una tabla nueva.

Ningún enfoque es universalmente «correcto» — depende del tamaño de la tabla, de si necesitas una instantánea puntual o datos en vivo, y de si el destino es una tabla nueva o existente.

Enfoque 1: Scan + BatchWriteItem (el script)

La opción de más baja tecnología: lee cada Item de la fuente con Scan, escríbelo en el destino con BatchWriteItem. Funciona entre cuentas y entre regiones siempre que tu script tenga credenciales para ambos lados (o asuma un rol en la cuenta de destino).

# Esquema — lee la fuente, escribe el destino (pseudo; usa el SDK en la vida real)
aws dynamodb scan --table-name SourceTable --region us-east-1 \
  > items.json
# transforma Items[] en RequestItems de BatchWriteItem, luego:
aws dynamodb batch-write-item --request-items file://batch.json \
  --region eu-west-1

Los detalles a tener en cuenta son reales y fáciles de pasar por alto:

• BatchWriteItem está limitado a 25 Items o 16MB por llamada — debes trocear, y una sola llamada puede devolver items no procesados que tienes que reintentar con backoff exponencial (referencia de la API).
• Las escrituras consumen capacidad de escritura. En un destino aprovisionado golpearás ProvisionedThroughputExceededException rápido; el modo on-demand absorbe más pero aún tiene límites suaves por partición. Dimensiona la carga de escritura contra la capacidad del destino antes de empezar.
• Scan lee la tabla entera y mide cada Item — el clásico coste de Query-frente-a-Scan. Una tabla grande también significa paginar a través de LastEvaluatedKey; mira paginación.
• No es atómico. Los Items escritos mientras el scan está en marcha pueden perderse — solo obtienes una instantánea consistente si la fuente está en reposo.

Mejor para tablas pequeñas o cuando necesitas transformar/filtrar durante la copia.

Enfoque 2: Exportar a S3, luego importar a una tabla nueva

Para tablas grandes, la exportación a S3 gestionada de DynamoDB más la importación desde S3 evita machacar tu capacidad en absoluto.

La exportación hace una instantánea de la tabla a un bucket de S3 (cómo funciona):

• Requiere recuperación punto en el tiempo (PITR) habilitada en la tabla fuente.
• No consume capacidad de lectura y no tiene impacto en el rendimiento de la tabla — lee de las copias de seguridad continuas, no de la tabla en vivo.
• Produce formato DynamoDB JSON o Amazon Ion. (El formato del cable DynamoDB-JSON es lo que aterriza en S3, con etiquetas de tipo y todo.)
• Puede escribir en un bucket de S3 propiedad de otra cuenta y en una región diferente.
• Soporta exportaciones completas e incrementales (exportación incremental GA, sept. 2023).

La importación construye luego una tabla nueva a partir de esos datos de S3 (cómo funciona):

• Importa solo a una tabla nueva — no puedes importar a una tabla existente.
• No consume capacidad de escritura en la tabla nueva.
• Acepta CSV, DynamoDB JSON o Amazon Ion (opcionalmente comprimidos con GZIP/ZSTD).
• El bucket de S3 fuente puede estar en otra cuenta u otra región.
• Puedes definir índices secundarios en el momento de la importación, consultables en cuanto la importación se completa.

Este es el camino más limpio para una migración grande entre cuentas/regiones donde una instantánea puntual (no datos en vivo) es aceptable.

Enfoque 3: Copia + restauración de AWS Backup

Si ya usas AWS Backup, copia puntos de recuperación entre cuentas y regiones (guía de migración entre cuentas):

1. Haz una copia de seguridad de la tabla fuente en un almacén de copias.
2. Copia la copia a un almacén en la cuenta/región de destino.
3. Restáurala a una tabla nueva en el destino.

Restricciones clave:

• La copia entre cuentas requiere que ambas cuentas estén en la misma AWS Organization.
• La restauración siempre crea una tabla nueva — no puedes restaurar sobre una existente.
• Los índices secundarios globales se preservan por defecto (excluye algunos o todos para ahorrar en tiempo/coste de restauración); no puedes añadir índices nuevos en la restauración.
• Detalle de cifrado: para mantener la misma clave KMS en una restauración entre regiones necesitas una clave multi-región; para entre cuentas debes compartir la clave con la cuenta de destino. Las claves propiedad de AWS y gestionadas por AWS no se pueden compartir ni hacer multi-región (notas de cifrado en restauración).

Enfoque 4: Tablas globales (replicación en vivo, no copia única)

Las tablas globales replican una tabla entre regiones — y ahora opcionalmente entre cuentas (multi-cuenta GA, feb. 2026) — de forma continua. Cualquier réplica sirve lecturas y escrituras (multi-activa), con replicación asíncrona de último-en-escribir-gana (documentación de tablas globales).

Esto no es una herramienta de «copia y olvídate» — es replicación continua. Úsala cuando quieras que la región de destino se mantenga sincronizada indefinidamente (DR, lecturas locales de baja latencia), no para una migración limpia de una sola vez. Añade una región a una tabla existente y DynamoDB rellena los datos existentes en la nueva réplica.

Detalles operativos a tener en cuenta (todos los enfoques)

• Los GSI no son gratis de recrear. Una copia scan+write no lleva índices — los defines en el destino y se rellenan (y cuestan) por separado. Planifica tu disposición de GSI frente a LSI en el destino por adelantado; los LSI solo se pueden crear en el momento de creación de la tabla (documentación de LSI).
• El modo de capacidad no se transfiere. La tabla nueva empieza con el modo que tú establezcas, no el de la fuente. Estima la carga de escritura antes de una copia scan+write — dimensiona un Item representativo con la calculadora de tamaño de Item y multiplica por el número de Items para estimar las WCU.
• TTL, streams, autoescalado y tags son configuraciones de tabla, no datos — ninguno de los métodos de copia lleva todos. Vuelve a aplicarlos en el destino.
• DynamoDB JSON ≠ JSON plano. Las exportaciones y los scans emiten DynamoDB-JSON etiquetado con tipos; si estás transformando por el camino, el conversor de DynamoDB JSON maneja el marshalling.

Preguntas frecuentes

¿Hay un comando de la AWS CLI para copiar una tabla de DynamoDB? No. No hay un comando nativo copy-table. Combinas scan + batch-write-item, o usas las funcionalidades gestionadas de exportación/importación o AWS Backup.

¿Cómo copio una tabla de DynamoDB a otra cuenta? Tres opciones: un script scan+write con credenciales para ambas cuentas, una exportación/importación de S3 (el bucket puede ser entre cuentas), o copia+restauración de AWS Backup (ambas cuentas deben estar en la misma AWS Organization).

¿Cómo copio una tabla de DynamoDB a otra región? La exportación/importación de S3 y AWS Backup soportan ambos entre regiones. Para sincronización continua entre regiones en lugar de una copia única, añade una réplica de tabla global en la región de destino.

¿Copiar una tabla copia sus índices? La importación de S3 y la restauración de AWS Backup te dejan mantener/definir índices secundarios; un script scan+write no — creas los índices en el destino tú mismo, y se rellenan por separado.

¿Puedo importar a una tabla de DynamoDB existente? No. Tanto la importación de S3 como la restauración de AWS Backup de DynamoDB crean una tabla nueva. Para fusionar en una tabla existente, usa un script scan+write.

Una GUI hace el cambio sensato: explora la fuente y el destino lado a lado, verifica los recuentos de items y unos pocos registros de muestra tras la copia, y ejecuta comprobaciones ad-hoc sin escribir un script de scan. Descarga DynoTable para inspeccionar tablas entre cuentas y regiones durante una migración.