Copiar una tabla de DynamoDB a otra cuenta/región

DynamoDB no tiene un comando "copy table" de un click — ni en la AWS CLI, ni en la consola. Cada copia son en realidad dos mitades: sacar los datos de la fuente, y cargarlos en una tabla de destino. La primera mitad es donde una GUI se gana el puesto — un export lossless, filtrado y verificado — mientras la segunda mitad siempre corre en tooling de AWS. Esta guía cubre ambas, y los gotchas operativos que muerden en producción.

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

No hay un comando nativo de copy-table. Para la mitad out, saca un export DynamoDB-JSON lossless de la tabla (un click en DynoTable, sin script) o haz snapshot con el export S3 managed. Para la mitad in, elige el enfoque del lado AWS que encaje: un script Scan + BatchWriteItem para copias one-off pequeñas, un export-then-import S3 para tablas grandes, AWS Backup copy + restore para movimientos cross-account con fidelidad completa, o global tables para replicación live continua. Cada restore o import crea una tabla nueva.

Ningún enfoque es universalmente "el correcto" — depende del tamaño de la tabla, de si necesitas un snapshot point-in-time o datos live, y de si el destino es una tabla nueva o existente.

La mitad export: saca los datos con DynoTable

Antes de que pueda haber un restore, los datos tienen que salir de la fuente — y un loop de scan a mano es la parte más propensa a errores de una migración pequeña (páginas caídas, precisión de números destrozada, type tags quitados demasiado pronto). DynoTable hace esa mitad en un click:

• Lossless by design: exporta el match completo del filtro como DynamoDB-JSON marshalled — la forma wire con type wrap, que preserva números grandes (> 2⁵³) que el JSON plano corrompe — o como NDJSON/CSV cuando el target no es DynamoDB en absoluto. Mira export to CSV para los detalles de formato.
• Con scope, no all-or-nothing: el export S3 managed hace snapshot de la tabla entera; DynoTable exporta cada item que tu query matchea, streameado directo desde DynamoDB — así que "copiar solo los items TENANT#42 a staging" es un filtro, no un script.
• Tablas grandes bienvenidas: los exports se despegan y corren en background, streameando a disco fila a fila — un pull de varios GB sobrevive a cambios de tab y reloads de la app.
• Verificación tras la carga: una vez la tabla de destino está up, explora source y target lado a lado, compara conteos de items (tamaño de tabla y conteo de items), y spot-check records de muestra — sin escribir un script de verificación.

El límite honesto: DynoTable saca datos out y verifica el resultado — la carga en la tabla de destino corre en tooling AWS (un script de escritura, import S3, o Backup restore), cubierto a continuación.

Enfoque 1: Scan + BatchWriteItem (el script)

El camino más low-tech — lee cada item de la fuente con Scan, escríbelo al destino con BatchWriteItem. Funciona cross-account y cross-region mientras tu script tenga credenciales para ambos lados (o asuma un role en la cuenta target).

# Sketch — read source, write target (pseudo; use the SDK in real life)
aws dynamodb scan --table-name SourceTable --region us-east-1 \
  > items.json
# transform Items[] into BatchWriteItem RequestItems, then:
aws dynamodb batch-write-item --request-items file://batch.json \
  --region eu-west-1

Los gotchas son reales y fáciles de pasar por alto:

• BatchWriteItem topea en 25 items o 16MB por llamada — tienes que trocear, y una sola llamada puede devolver unprocessed items que debes reintentar con exponential backoff (referencia de la API).
• Las escrituras consumen write capacity. En un target provisioned chocarás ProvisionedThroughputExceededException rápido; on-demand absorbe más pero aún topea cada partición en un límite duro de 1.000 WCU / 3.000 RCU. Dimensiona la carga de escritura contra la capacidad del destino antes de empezar.
• Scan lee toda la tabla y mide cada item — el clásico coste Query-vs-Scan. Una tabla grande también significa paginar por LastEvaluatedKey; mira paginación.
• No es atómico: los items escritos mientras el scan está en vuelo pueden perderse — solo obtienes un snapshot consistente si la fuente está quieta.

Mejor para tablas pequeñas o cuando necesitas transformar/filtrar durante la copia — y si la mitad de lectura ya existe como un export marshalled de DynoTable, el script se encoge a solo el loop de chunk-and-write.

Enfoque 2: Export a S3, luego import a una tabla nueva

Para tablas grandes, el export a S3 managed de DynamoDB más el import from S3 evita machacar tu capacidad por completo.

Export hace snapshot de la tabla a un bucket S3 (cómo funciona):

• Requiere point-in-time recovery (PITR) enabled en la tabla fuente.
• No consume read capacity y no tiene impacto en el rendimiento de la tabla — lee de continuous backups, no de la tabla live.
• Emite formato DynamoDB JSON o Amazon Ion. (El formato wire DynamoDB-JSON es lo que aterriza en S3, type tags y todo.)
• Puede escribir a un bucket S3 propiedad de otra cuenta y en otra región.
• Soporta exports full e incremental (incremental export GA, sept 2023).

Import luego construye una tabla fresca desde esos datos S3 (cómo funciona):

• Importa solo a una tabla brand-new — no puedes importar a una tabla existente.
• No consume write capacity en la tabla nueva.
• Acepta CSV, DynamoDB JSON o Amazon Ion (opcionalmente comprimido GZIP/ZSTD).
• El bucket S3 fuente puede estar en otra cuenta u otra región.
• Puedes definir índices secundarios en el momento del import, consultables en cuanto el import termina.

Este es el camino más limpio para una migración cross-account/cross-region grande donde un snapshot point-in-time (no datos live) es aceptable.

Enfoque 3: AWS Backup copy + restore

Si ya usas AWS Backup, copia recovery points a través de cuentas y regiones (guía de migración cross-account):

1. Haz backup de la tabla fuente a un backup vault.
2. Copia el backup a un vault en la cuenta/región target.
3. Restaura a una tabla nueva en el target.

Constraints clave:

• El copy cross-account requiere que ambas cuentas estén en la misma AWS Organization.
• El restore siempre crea una tabla nueva — no puedes restaurar encima de una existente.
• Los índices secundarios globales se preservan por defecto (excluye algunos o todos para ahorrar tiempo/coste de restore); no puedes añadir índices nuevos en el restore.
• Gotcha de encryption: para mantener la misma KMS key en un restore cross-region necesitas una multi-region key; para cross-account debes compartir la key con la cuenta target. Las keys AWS-owned y AWS-managed no se pueden compartir ni hacer multi-region (notas de encryption del restore).

Enfoque 4: Global tables (replicación live, no una copia one-time)

Las global tables replican una tabla a través de regiones — y ahora opcionalmente a través de cuentas (multi-account GA, feb 2026) — de forma continua. Cualquier réplica sirve lecturas y escrituras (multi-active), con replicación asíncrona last-writer-wins (docs de global tables).

Esto no es una tool de "copiar y marcharte" — es replicación continua. Úsalo cuando quieres que la región de destino se quede en sync indefinidamente (DR, lecturas locales de baja latencia), no para una migración one-time limpia. Añade una región a una tabla existente y DynamoDB hace backfill de los datos existentes a la réplica nueva.

Gotchas operativos (todos los enfoques)

• Los GSI no son gratis de recrear. Una copia scan+write no lleva índices — los defines en el target y hacen backfill (y cuestan) por separado. Planifica tu layout GSI vs LSI en el destino de antemano; los LSI solo se pueden crear en el momento de creación de la tabla (docs LSI).
• El capacity mode no se transfiere. La tabla nueva arranca con el modo que pongas, 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 conteo de items para ballparkear WCUs.
• TTL, streams, auto-scaling y tags son settings de tabla, no datos — ninguno de los métodos de copia los lleva todos. Reaplicaálos en el target.
• DynamoDB JSON ≠ JSON plano. Exports y scans emiten DynamoDB-JSON con type tags; si transformas en ruta, el convertidor DynamoDB JSON maneja el marshalling.
• Verifica antes del cutover. Compara conteos de items y spot-check records en ambos lados — recordando que el conteo de DescribeTable puede estar hasta seis horas stale, así que un target fresco puede reportar cero de forma legítima.

FAQ

¿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 features managed de export/import o AWS Backup.

¿Cómo copio una tabla de DynamoDB a otra cuenta? Tres opciones: un script scan+write con credenciales para ambas cuentas, un export/import S3 (el bucket puede ser cross-account), o AWS Backup copy+restore (ambas cuentas deben estar en la misma AWS Organization).

¿Cómo copio una tabla de DynamoDB a otra región? Export/import S3 y AWS Backup ambos soportan cross-region. Para sync cross-region continuo en vez de una copia one-time, añade una réplica de global table en la región target.

¿Copiar una tabla copia sus índices? Import S3 y restore de AWS Backup te dejan mantener/definir índices secundarios; un script scan+write no — creas los índices en el target tú, y hacen backfill por separado.

¿Puedo importar a una tabla de DynamoDB existente? No. El import S3 de DynamoDB y el restore de AWS Backup ambos crean una tabla nueva. Para mergear en una tabla existente, usa un script scan+write.

¿Puedo copiar solo parte de una tabla? Los caminos managed de export/import y Backup son solo full-table. Para un subset, exporta el match del filtro desde DynoTable (DynamoDB-JSON marshalled lossless) o scriptea un scan filtrado, luego escribe el subset al target.

Una GUI hace el cutover sano: saca un export lossless de exactamente los items que estás moviendo, luego explora source y target lado a lado, verifica conteos de items y unos records de muestra tras la copia, y lanza checks ad-hoc sin escribir un script de scan. Descarga DynoTable para correr la mitad export-and-verify de una migración a través de cuentas y regiones.