Come copiare una tabella DynamoDB su un altro account o region

DynamoDB non ha nessun comando "copia tabella" in un clic — né nella AWS CLI né nella console. Copiare o migrare una tabella tra account o region significa scegliere uno di quattro approcci, ciascuno con compromessi diversi su costo, downtime e fedeltà. Questa guida copre tutti e quattro, più le insidie operative che mordono in produzione.

Come copio una tabella DynamoDB su un altro account o region?

Non esiste un comando nativo di copia tabella. Scegli uno di quattro approcci: uno script Scan + BatchWriteItem per piccole copie una tantum, un export su S3 con successivo import per tabelle grandi, copia + ripristino con AWS Backup per spostamenti cross-account con fedeltà completa, oppure le global table per una replica live continua. Ogni ripristino o import crea una nuova tabella.

Nessun approccio è universalmente "giusto" — dipende dalle dimensioni della tabella, dal fatto che ti serva uno snapshot point-in-time o dati live, e dal fatto che la destinazione sia una tabella nuova o esistente.

Approccio 1: Scan + BatchWriteItem (lo script)

L'opzione meno tecnologica: leggi ogni item dalla sorgente con Scan, scrivilo nella destinazione con BatchWriteItem. Funziona cross-account e cross-region purché il tuo script detenga le credenziali per entrambi i lati (o assuma un ruolo nell'account di destinazione).

# Bozza — leggi dalla sorgente, scrivi nel target (pseudo; usa l'SDK nella vita reale)
aws dynamodb scan --table-name SourceTable --region us-east-1 \
  > items.json
# trasforma Items[] in RequestItems di BatchWriteItem, poi:
aws dynamodb batch-write-item --request-items file://batch.json \
  --region eu-west-1

Le insidie sono reali e facili da non vedere:

• BatchWriteItem ha un tetto di 25 item o 16 MB per chiamata — devi suddividere in blocchi, e una singola chiamata può restituire item non processati che devi ritentare con backoff esponenziale (riferimento API).
• Le scritture consumano capacità di scrittura. Su un target provisioned colpirai in fretta ProvisionedThroughputExceededException; on-demand assorbe di più ma ha comunque soft limit per-partizione. Dimensiona il carico di scrittura sulla capacità della destinazione prima di iniziare.
• Scan legge l'intera tabella e mette a contatore ogni item — il classico costo Query-vs-Scan. Una tabella grande significa anche paginare attraverso LastEvaluatedKey; vedi paginazione.
• Non è atomico. Gli item scritti mentre lo scan è in corso possono essere persi — ottieni uno snapshot coerente solo se la sorgente è quiescente.

Ideale per tabelle piccole o quando devi trasformare/filtrare durante la copia.

Approccio 2: Export su S3, poi import in una nuova tabella

Per tabelle grandi, l'export su S3 gestito di DynamoDB più l'import da S3 evita di tartassare del tutto la tua capacità.

L'export crea uno snapshot della tabella su un bucket S3 (come funziona):

• Richiede il point-in-time recovery (PITR) abilitato sulla tabella sorgente.
• Non consuma capacità di lettura e non ha impatto sulle prestazioni della tabella — legge dai backup continui, non dalla tabella live.
• Produce formato DynamoDB JSON o Amazon Ion. (Il formato wire DynamoDB-JSON è ciò che atterra in S3, type tag inclusi.)
• Può scrivere su un bucket S3 di proprietà di un altro account e in una region diversa.
• Supporta export completi e incrementali (export incrementale GA, settembre 2023).

L'import costruisce poi una tabella nuova da quei dati S3 (come funziona):

• Importa solo in una tabella nuova di zecca — non puoi importare in una tabella esistente.
• Non consuma capacità di scrittura sulla nuova tabella.
• Accetta CSV, DynamoDB JSON o Amazon Ion (opzionalmente compressi GZIP/ZSTD).
• Il bucket S3 sorgente può essere in un altro account o un'altra region.
• Puoi definire indici secondari al momento dell'import, interrogabili non appena l'import si completa.

È il percorso più pulito per una migrazione cross-account/cross-region di grandi dimensioni in cui uno snapshot point-in-time (non dati live) è accettabile.

Approccio 3: copia + ripristino con AWS Backup

Se usi già AWS Backup, copia i recovery point tra account e region (guida alla migrazione cross-account):

1. Esegui il backup della tabella sorgente in un backup vault.
2. Copia il backup in un vault nell'account/region di destinazione.
3. Ripristina in una nuova tabella nella destinazione.

Vincoli chiave:

• La copia cross-account richiede che entrambi gli account siano nella stessa AWS Organization.
• Il ripristino crea sempre una nuova tabella — non puoi ripristinare su una esistente.
• I global secondary index sono preservati per impostazione predefinita (escludine alcuni o tutti per risparmiare tempo/costo di ripristino); non puoi aggiungere nuovi indici al ripristino.
• Insidia di crittografia: per mantenere la stessa chiave KMS su un ripristino cross-region ti serve una multi-region key; per il cross-account devi condividere la chiave con l'account di destinazione. Le chiavi AWS-owned e AWS-managed non possono essere condivise o rese multi-region (note sulla crittografia del ripristino).

Approccio 4: Global table (replica live, non una copia una tantum)

Le global table replicano una tabella tra region — e ora opzionalmente tra account (multi-account GA, febbraio 2026) — in modo continuo. Qualsiasi replica serve letture e scritture (multi-active), con replica asincrona last-writer-wins (documentazione global table).

Questo non è uno strumento "copia e dimentica" — è replica continua. Usalo quando vuoi che la region di destinazione resti in sync indefinitamente (DR, letture locali a bassa latenza), non per una migrazione pulita una tantum. Aggiungi una region a una tabella esistente e DynamoDB fa il backfill dei dati esistenti nella nuova replica.

Insidie operative (tutti gli approcci)

• Ricreare i GSI non è gratis. Una copia scan+write non porta con sé gli indici — li definisci sul target e fanno backfill (e costano) separatamente. Pianifica in anticipo il tuo layout GSI vs LSI sulla destinazione; gli LSI possono essere creati solo al momento della creazione della tabella (documentazione LSI).
• La modalità di capacità non si trasferisce. La nuova tabella parte con qualunque modalità tu imposti, non con quella della sorgente. Stima il carico di scrittura prima di una copia scan+write — dimensiona un item rappresentativo con il calcolatore delle dimensioni degli item e moltiplica per il numero di item per stimare le WCU.
• TTL, stream, auto-scaling e tag sono impostazioni della tabella, non dati — nessuno dei metodi di copia li porta tutti con sé. Riapplicali sul target.
• DynamoDB JSON ≠ JSON semplice. Export e scan emettono DynamoDB-JSON con type tag; se stai trasformando lungo il percorso, il convertitore DynamoDB JSON gestisce il marshalling.

FAQ

Esiste un comando AWS CLI per copiare una tabella DynamoDB? No. Non c'è un comando nativo copy-table. Combini scan + batch-write-item, oppure usi le funzioni gestite di export/import o AWS Backup.

Come copio una tabella DynamoDB su un altro account? Tre opzioni: uno script scan+write con credenziali per entrambi gli account, un export/import S3 (il bucket può essere cross-account), o copia+ripristino con AWS Backup (entrambi gli account devono essere nella stessa AWS Organization).

Come copio una tabella DynamoDB su un'altra region? Sia l'export/import S3 sia AWS Backup supportano il cross-region. Per la sincronizzazione cross-region continua anziché una copia una tantum, aggiungi una replica global-table nella region di destinazione.

Copiare una tabella copia i suoi indici? L'import S3 e il ripristino AWS Backup ti permettono di mantenere/definire indici secondari; uno script scan+write no — gli indici li crei tu sul target, e fanno backfill separatamente.

Posso importare in una tabella DynamoDB esistente? No. Sia l'import S3 sia il ripristino AWS Backup di DynamoDB creano una nuova tabella. Per fondere in una tabella esistente, usa uno script scan+write.

Una GUI rende il cutover gestibile: sfoglia sorgente e target fianco a fianco, verifica i conteggi degli item e qualche record di esempio dopo la copia, ed esegui controlli ad-hoc senza scrivere uno script di scan. Scarica DynoTable per ispezionare le tabelle tra account e region durante una migrazione.