Salin tabel DynamoDB ke akun/region lain

DynamoDB tidak punya perintah "copy table" sekali klik — tidak di AWS CLI, tidak di konsol. Setiap salinan benar-benar dua bagian: keluarkan data dari sumber, dan muat ke tabel tujuan. Bagian pertama adalah tempat GUI pantas dipekerjakan — ekspor lossless, berfilter, terverifikasi — sementara bagian kedua selalu berjalan di tooling AWS. Panduan ini mencakup keduanya, dan gotcha operasional yang menggigit di produksi.

Bagaimana saya menyalin tabel DynamoDB ke akun atau region lain?

Tidak ada perintah copy-table native. Untuk bagian out, tarik ekspor DynamoDB-JSON lossless dari tabel (satu klik di DynoTable, tanpa skrip) atau snapshot dengan managed S3 export. Untuk bagian in, pilih pendekatan sisi AWS yang cocok: skrip Scan + BatchWriteItem untuk salinan sekali kecil, export-then-import S3 untuk tabel besar, AWS Backup copy + restore untuk perpindahan cross-account dengan fidelitas penuh, atau global tables untuk replikasi live berkelanjutan. Setiap restore atau import membuat tabel baru.

Tidak ada pendekatan yang secara universal "benar" — bergantung pada ukuran tabel, apakah Anda butuh snapshot point-in-time atau data live, dan apakah tujuan adalah tabel baru atau yang sudah ada.

Bagian ekspor: tarik data dengan DynoTable

Sebelum restore mana pun bisa terjadi, data harus keluar dari sumber — dan loop scan buatan tangan adalah bagian paling rawan error dari migrasi kecil (halaman terjatuh, presisi angka rusak, type tag dilucuti terlalu dini). DynoTable melakukan bagian itu dalam satu klik:

• Lossless by design: ekspor seluruh match filter sebagai DynamoDB-JSON marshalled — bentuk wire ber-type-wrap, yang menjaga angka besar (> 2⁵³) yang JSON polos rusak — atau sebagai NDJSON/CSV saat target bukan DynamoDB sama sekali. Lihat export to CSV untuk detail format.
• Scoped, bukan all-or-nothing: managed S3 export men-snapshot seluruh tabel; DynoTable mengekspor setiap item yang cocok dengan query Anda, di-stream langsung dari DynamoDB — jadi "salin hanya item TENANT#42 ke staging" adalah filter, bukan skrip.
• Tabel besar diterima: ekspor detach dan berjalan di latar, streaming ke disk baris demi baris — pull multi-gigabyte bertahan dari tab switch dan reload app.
• Verifikasi setelah load: setelah tabel tujuan naik, jelajahi sumber dan target berdampingan, bandingkan jumlah item (ukuran tabel & jumlah item), dan spot-check sampel record — tanpa menulis skrip verifikasi.

Batas jujurnya: DynoTable menarik data keluar dan memverifikasi hasil — load ke tabel tujuan berjalan di tooling AWS (skrip write, S3 import, atau Backup restore), dibahas berikutnya.

Pendekatan 1: Scan + BatchWriteItem (skrip)

Jalur terendah-tech — baca setiap item dari sumber dengan Scan, tulis ke tujuan dengan BatchWriteItem. Bekerja cross-account dan cross-region selama skrip Anda memegang kredensial untuk kedua sisi (atau assume role di akun 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

Gotcha-nya nyata dan mudah dilewatkan:

• BatchWriteItem dibatasi 25 item atau 16MB per panggilan — Anda harus chunk, dan satu panggilan bisa mengembalikan unprocessed items yang harus di-retry dengan exponential backoff (referensi API).
• Write mengonsumsi kapasitas tulis. Pada target provisioned Anda akan menabrak ProvisionedThroughputExceededException cepat; on-demand menyerap lebih banyak tetapi tetap membatasi tiap partisi pada hard limit 1.000 WCU / 3.000 RCU. Ukuran beban tulis terhadap kapasitas tujuan sebelum Anda mulai.
• Scan membaca seluruh tabel dan mengukur setiap item — biaya klasik Query-vs-Scan. Tabel besar juga berarti memaginasi lewat LastEvaluatedKey; lihat pagination.
• Tidak atomik: Item yang ditulis sementara scan berjalan bisa terlewat — Anda hanya mendapat snapshot konsisten jika sumber diam.

Terbaik untuk tabel kecil atau saat Anda perlu transform/filter selama salinan — dan jika bagian baca sudah ada sebagai ekspor DynoTable marshalled, skrip menyusut hanya ke loop chunk-and-write.

Pendekatan 2: Export ke S3, lalu import ke tabel baru

Untuk tabel besar, export to S3 managed DynamoDB plus import from S3 menghindari menghantam kapasitas Anda sama sekali.

Export men-snapshot tabel ke bucket S3 (cara kerjanya):

• Memerlukan point-in-time recovery (PITR) diaktifkan pada tabel sumber.
• Tidak mengonsumsi kapasitas baca dan tidak berdampak pada performa tabel — ia membaca dari continuous backup, bukan tabel live.
• Output format DynamoDB JSON atau Amazon Ion. (Format wire DynamoDB-JSON yang mendarat di S3, type tag dan semuanya.)
• Bisa menulis ke bucket S3 milik akun lain dan di region berbeda.
• Mendukung export penuh dan incremental (incremental export GA, Sept 2023).

Import lalu membangun tabel baru dari data S3 itu (cara kerjanya):

• Import ke tabel brand-new saja — Anda tidak bisa import ke tabel yang sudah ada.
• Tidak mengonsumsi kapasitas tulis pada tabel baru.
• Menerima CSV, DynamoDB JSON, atau Amazon Ion (opsional dikompresi GZIP/ZSTD).
• Bucket S3 sumber boleh di akun lain atau region lain.
• Anda bisa mendefinisikan secondary index saat import, bisa di-Query segera setelah import selesai.

Ini jalur paling bersih untuk migrasi cross-account/cross-region besar di mana snapshot point-in-time (bukan data live) dapat diterima.

Pendekatan 3: AWS Backup copy + restore

Jika Anda sudah memakai AWS Backup, ia menyalin recovery point lintas akun dan region (panduan migrasi cross-account):

1. Backup tabel sumber ke backup vault.
2. Copy backup ke vault di akun/region target.
3. Restore ke tabel baru di target.

Constraint kunci:

• Copy cross-account memerlukan kedua akun di AWS Organization yang sama.
• Restore selalu membuat tabel baru — Anda tidak bisa restore di atas yang sudah ada.
• Global secondary index dipreservasi by default (kecualikan sebagian atau semua untuk menghemat waktu/biaya restore); Anda tidak bisa menambah indeks baru saat restore.
• Gotcha enkripsi: untuk menjaga KMS key yang sama pada restore cross-region Anda butuh multi-region key; untuk cross-account Anda harus berbagi key dengan akun target. Key milik AWS dan managed AWS tidak bisa dibagikan atau dibuat multi-region (catatan enkripsi restore).

Pendekatan 4: Global tables (replikasi live, bukan salinan sekali)

Global tables mereplikasi tabel lintas region — dan sekarang opsional lintas akun (multi-account GA, Feb 2026) — secara kontinu. Replica mana pun melayani baca dan tulis (multi-active), dengan replikasi asinkron last-writer-wins (dokumen global tables).

Ini bukan alat "salin dan pergi" — ini replikasi berkelanjutan. Pakai saat Anda ingin region tujuan tetap sinkron tanpa batas (DR, baca lokal latensi rendah), bukan untuk migrasi sekali yang bersih. Tambah region ke tabel yang sudah ada dan DynamoDB backfill data yang ada ke replica baru.

Gotcha operasional (semua pendekatan)

• GSI tidak gratis untuk dibuat ulang. Salinan scan+write tidak membawa indeks — Anda mendefinisikannya di target dan mereka backfill (serta biaya) terpisah. Rencanakan layout GSI vs LSI di tujuan di depan; LSI hanya bisa dibuat saat pembuatan tabel (dokumen LSI).
• Mode kapasitas tidak mentransfer. Tabel baru mulai dengan mode apa pun yang Anda set, bukan milik sumber. Perkirakan beban tulis sebelum salinan scan+write — ukur item representatif dengan kalkulator ukuran item dan kalikan dengan jumlah item untuk memperkirakan WCU.
• TTL, streams, auto-scaling, dan tags adalah pengaturan tabel, bukan data — tidak ada metode salinan yang membawa semuanya. Terapkan ulang di target.
• DynamoDB JSON ≠ JSON polos. Ekspor dan scan mengeluarkan DynamoDB-JSON ber-type-tag; jika Anda mentransform di jalan, konverter DynamoDB JSON menangani marshalling.
• Verifikasi sebelum cutover. Bandingkan jumlah item dan spot-check record di kedua sisi — ingat bahwa count DescribeTable basi hingga enam jam, jadi target segar bisa sah melaporkan nol.

FAQ

Apakah ada perintah AWS CLI untuk menyalin tabel DynamoDB? Tidak. Tidak ada perintah copy-table native. Anda menggabungkan scan + batch-write-item, atau memakai fitur managed export/import atau AWS Backup.

Bagaimana saya menyalin tabel DynamoDB ke akun lain? Tiga opsi: skrip scan+write dengan kredensial untuk kedua akun, S3 export/import (bucket bisa cross-account), atau AWS Backup copy+restore (kedua akun harus di AWS Organization yang sama).

Bagaimana saya menyalin tabel DynamoDB ke region lain? S3 export/import dan AWS Backup keduanya mendukung cross-region. Untuk sync cross-region berkelanjutan alih-alih salinan sekali, tambah replica global-table di region target.

Apakah menyalin tabel menyalin indeksnya? S3 import dan AWS Backup restore membiarkan Anda menjaga/mendefinisikan secondary index; skrip scan+write tidak — Anda membuat indeks di target sendiri, dan mereka backfill terpisah.

Bisakah saya import ke tabel DynamoDB yang sudah ada? Tidak. S3 import DynamoDB dan AWS Backup restore keduanya membuat tabel baru. Untuk merge ke tabel yang sudah ada, pakai skrip scan+write.

Bisakah saya menyalin hanya sebagian tabel? Jalur managed export/import dan Backup hanya full-table. Untuk subset, ekspor match filter dari DynoTable (DynamoDB-JSON marshalled lossless) atau skrip scan berfilter, lalu tulis subset ke target.

GUI membuat cutover masuk akal: tarik ekspor lossless tepat item yang Anda pindahkan, lalu jelajahi sumber dan target berdampingan, verifikasi jumlah item dan beberapa sampel record setelah salinan, dan jalankan cek ad-hoc tanpa menulis skrip scan. Unduh DynoTable untuk menjalankan bagian export-and-verify dari migrasi lintas akun dan region.