Como Copiar uma Tabela do DynamoDB para Outra Conta ou Região

O DynamoDB não tem comando de "copiar tabela" em um clique — nem na AWS CLI, nem no console. Copiar ou migrar uma tabela entre contas ou regiões significa escolher uma de quatro abordagens, cada uma com trade-offs diferentes de custo, downtime e fidelidade. Este guia cobre as quatro, além das pegadinhas operacionais que mordem em produção.

Como copio uma tabela do DynamoDB para outra conta ou região?

Não existe um comando nativo de copiar tabela. Escolha uma de quatro abordagens: um script de Scan + BatchWriteItem para cópias pequenas e pontuais, um export para o S3 seguido de import para tabelas grandes, cópia + restore via AWS Backup para movimentações entre contas com fidelidade total, ou global tables para replicação ao vivo contínua. Cada restore ou import cria uma tabela nova.

Nenhuma abordagem é universalmente "certa" — depende do tamanho da tabela, de você precisar de um snapshot pontual ou de dados ao vivo, e de o destino ser uma tabela nova ou existente.

Abordagem 1: Scan + BatchWriteItem (o script)

A opção de menor tecnologia: ler todo item da origem com Scan, escrevê-lo no destino com BatchWriteItem. Funciona entre contas e entre regiões desde que seu script tenha credenciais para os dois lados (ou assuma uma role na conta de destino).

# Esboço — ler origem, escrever destino (pseudo; use o SDK na vida real)
aws dynamodb scan --table-name SourceTable --region us-east-1 \
  > items.json
# transforme Items[] em RequestItems de BatchWriteItem, depois:
aws dynamodb batch-write-item --request-items file://batch.json \
  --region eu-west-1

As pegadinhas são reais e fáceis de esquecer:

• O BatchWriteItem limita em 25 itens ou 16MB por chamada — você precisa fatiar, e uma única chamada pode retornar itens não processados que você tem que repetir com backoff exponencial (referência da API).
• As escritas consomem capacidade de escrita. Num destino provisionado você vai bater em ProvisionedThroughputExceededException rápido; o on-demand absorve mais, mas ainda tem limites flexíveis por partição. Dimensione a carga de escrita contra a capacidade do destino antes de começar.
• O Scan lê a tabela inteira e methe cada item — o clássico custo de Query-vs-Scan. Uma tabela grande também significa paginar por LastEvaluatedKey; veja paginação.
• Não é atômico. Itens escritos enquanto o scan está em andamento podem ser perdidos — você só obtém um snapshot consistente se a origem estiver parada.

Melhor para tabelas pequenas ou quando você precisa transformar/filtrar durante a cópia.

Abordagem 2: Exportar para o S3, depois importar para uma nova tabela

Para tabelas grandes, o export para o S3 gerenciado do DynamoDB mais o import a partir do S3 evitam martelar sua capacidade por completo.

O export tira um snapshot da tabela para um bucket S3 (como funciona):

• Requer point-in-time recovery (PITR) habilitado na tabela de origem.
• Não consome capacidade de leitura e não tem impacto no desempenho da tabela — ele lê dos backups contínuos, não da tabela ao vivo.
• Gera formato DynamoDB JSON ou Amazon Ion. (O formato de transporte DynamoDB-JSON é o que cai no S3, type tags e tudo.)
• Pode escrever em um bucket S3 de propriedade de outra conta e em uma região diferente.
• Suporta exports completos e incrementais (export incremental GA, set/2023).

O import então constrói uma tabela nova a partir desses dados no S3 (como funciona):

• Importa apenas para uma tabela nova em folha — você não pode importar para uma tabela existente.
• Não consome capacidade de escrita na nova tabela.
• Aceita CSV, DynamoDB JSON ou Amazon Ion (opcionalmente comprimido com GZIP/ZSTD).
• O bucket S3 de origem pode estar em outra conta ou outra região.
• Você pode definir índices secundários na hora do import, consultáveis assim que o import terminar.

Este é o caminho mais limpo para uma migração grande entre contas/regiões em que um snapshot pontual (não dados ao vivo) seja aceitável.

Abordagem 3: Cópia + restore via AWS Backup

Se você já usa o AWS Backup, ele copia recovery points entre contas e regiões (guia de migração entre contas):

1. Faça backup da tabela de origem em um backup vault.
2. Copie o backup para um vault na conta/região de destino.
3. Restaure-o para uma nova tabela no destino.

Restrições-chave:

• A cópia entre contas exige que ambas as contas estejam na mesma AWS Organization.
• O restore sempre cria uma nova tabela — você não pode restaurar sobre uma existente.
• Os índices secundários globais são preservados por padrão (exclua alguns ou todos para economizar tempo/custo de restore); você não pode adicionar novos índices no restore.
• Pegadinha de criptografia: para manter a mesma chave KMS num restore entre regiões você precisa de uma multi-region key; para entre contas você precisa compartilhar a chave com a conta de destino. Chaves de propriedade da AWS e gerenciadas pela AWS não podem ser compartilhadas nem tornadas multi-região (notas de criptografia do restore).

Abordagem 4: Global tables (replicação ao vivo, não uma cópia única)

As global tables replicam uma tabela entre regiões — e agora opcionalmente entre contas (multi-conta GA, fev/2026) — continuamente. Qualquer réplica serve leituras e escritas (multi-active), com replicação assíncrona, last-writer-wins (docs de global tables).

Isso não é uma ferramenta de "copiar e ir embora" — é replicação contínua. Use-a quando você quiser que a região de destino fique em sincronia indefinidamente (DR, leituras locais de baixa latência), não para uma migração única e limpa. Adicione uma região a uma tabela existente e o DynamoDB faz backfill dos dados existentes na nova réplica.

Pegadinhas operacionais (todas as abordagens)

• Recriar GSIs não é de graça. Uma cópia scan+write não carrega índices — você os define no destino e eles fazem backfill (e custam) separadamente. Planeje o layout de GSI vs LSI no destino de antemão; LSIs só podem ser criadas no momento da criação da tabela (docs de LSI).
• O modo de capacidade não é transferido. A nova tabela começa com o modo que você definir, não o da origem. Estime a carga de escrita antes de uma cópia scan+write — dimensione um item representativo com a calculadora de tamanho de item e multiplique pela contagem de itens para estimar as WCUs.
• TTL, streams, auto-scaling e tags são configurações de tabela, não dados — nenhum dos métodos de cópia carrega todos eles. Reaplique-os no destino.
• DynamoDB JSON ≠ JSON puro. Exports e scans emitem DynamoDB-JSON com type tags; se você estiver transformando no caminho, o conversor de DynamoDB JSON cuida do marshalling.

FAQ

Existe um comando da AWS CLI para copiar uma tabela do DynamoDB? Não. Não há comando nativo copy-table. Você combina scan + batch-write-item, ou usa os recursos gerenciados de export/import ou o AWS Backup.

Como copio uma tabela do DynamoDB para outra conta? Três opções: um script scan+write com credenciais para ambas as contas, um export/import via S3 (o bucket pode ser entre contas), ou cópia+restore via AWS Backup (ambas as contas precisam estar na mesma AWS Organization).

Como copio uma tabela do DynamoDB para outra região? Export/import via S3 e AWS Backup ambos suportam entre regiões. Para sincronia contínua entre regiões em vez de uma cópia única, adicione uma réplica de global table na região de destino.

Copiar uma tabela copia seus índices? O import via S3 e o restore do AWS Backup permitem manter/definir índices secundários; um script scan+write não — você cria os índices no destino você mesmo, e eles fazem backfill separadamente.

Posso importar para uma tabela existente do DynamoDB? Não. O import via S3 e o restore do AWS Backup do DynamoDB ambos criam uma tabela nova. Para mesclar em uma tabela existente, use um script scan+write.

Uma GUI deixa o cutover sensato: navegue por origem e destino lado a lado, verifique contagens de itens e alguns registros de amostra após a cópia, e rode checagens ad-hoc sem escrever um script de scan. Baixe o DynoTable para inspecionar tabelas entre contas e regiões durante uma migração.