Cara Menyalin Tabel DynamoDB ke Akun atau Region Lain

DynamoDB tidak punya perintah "copy table" satu-klik — tidak di AWS CLI, tidak di konsol. Menyalin atau memigrasikan tabel lintas akun atau region berarti memilih salah satu dari empat pendekatan, masing-masing dengan trade-off biaya, downtime, dan fidelitas yang berbeda. Panduan ini membahas keempatnya, plus jebakan operasional yang menggigit di produksi.

Bagaimana cara menyalin tabel DynamoDB ke akun atau region lain?

Tidak ada perintah copy-table native. Pilih salah satu dari empat pendekatan: skrip Scan + BatchWriteItem untuk penyalinan kecil sekali pakai, ekspor-lalu-impor S3 untuk tabel besar, AWS Backup copy + restore untuk perpindahan lintas-akun dengan fidelitas penuh, atau global tables untuk replikasi live berkelanjutan. Setiap restore atau impor membuat tabel baru.

Situasi	Pendekatan terbaik
Tabel kecil, sekali pakai, kontrol penuh	Skrip Scan + BatchWriteItem
Tabel besar, bisa menoleransi snapshot	Ekspor S3 → impor (membuat tabel baru)
Lintas-akun / lintas-region dengan restore	AWS Backup copy + restore
Replikasi live berkelanjutan (bukan sekali-salin)	Global tables

Tidak ada pendekatan yang universal "benar" — itu tergantung ukuran tabel, apakah Anda butuh snapshot point-in-time atau data live, dan apakah tujuannya tabel baru atau yang sudah ada.

Pendekatan 1: Scan + BatchWriteItem (skripnya)

Opsi paling sederhana secara teknis: baca setiap Item dari sumber dengan Scan, tulis ke tujuan dengan BatchWriteItem. Bekerja lintas-akun dan lintas-region selama skrip Anda memegang kredensial untuk kedua sisi (atau mengasumsikan role di akun target).

# Sketsa — baca sumber, tulis target (pseudo; pakai SDK di kehidupan nyata)
aws dynamodb scan --table-name SourceTable --region us-east-1 \
  > items.json
# transformasikan Items[] menjadi RequestItems BatchWriteItem, lalu:
aws dynamodb batch-write-item --request-items file://batch.json \
  --region eu-west-1

Jebakannya nyata dan mudah terlewat:

BatchWriteItem dibatasi 25 item atau 16MB per panggilan — Anda harus memecah, dan satu panggilan dapat mengembalikan item yang belum diproses yang harus Anda coba ulang dengan exponential backoff (referensi API).
Penulisan mengonsumsi kapasitas tulis. Pada target provisioned Anda akan cepat menabrak ProvisionedThroughputExceededException; on-demand menyerap lebih banyak tetapi tetap punya batas lunak per-partisi. Ukur beban tulis terhadap kapasitas tujuan sebelum Anda mulai.
Scan membaca seluruh tabel dan memeter setiap item — biaya Query-vs-Scan yang klasik. Tabel besar juga berarti paginasi melalui LastEvaluatedKey; lihat paginasi.
Ini tidak atomik. Item yang ditulis saat scan sedang berlangsung bisa terlewat — Anda hanya mendapat snapshot konsisten jika sumber dalam keadaan diam.

Terbaik untuk tabel kecil atau saat Anda perlu transformasi/filter selama penyalinan.

Pendekatan 2: Ekspor ke S3, lalu impor ke tabel baru

Untuk tabel besar, ekspor ke S3 terkelola DynamoDB plus impor dari S3 menghindari menghantam kapasitas Anda sama sekali.

Ekspor 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 backup berkelanjutan, bukan tabel live.
Mengeluarkan format DynamoDB JSON atau Amazon Ion. (Format wire DynamoDB-JSON adalah yang mendarat di S3, lengkap dengan type tag.)
Dapat menulis ke bucket S3 yang dimiliki akun lain dan di region berbeda.
Mendukung ekspor penuh dan inkremental (ekspor inkremental GA, Sep 2023).

Impor kemudian membangun tabel baru dari data S3 itu (cara kerjanya):

Mengimpor ke tabel baru saja — Anda tidak dapat mengimpor ke tabel yang sudah ada.
Tidak mengonsumsi kapasitas tulis pada tabel baru.
Menerima CSV, DynamoDB JSON, atau Amazon Ion (opsional terkompresi GZIP/ZSTD).
Bucket S3 sumber boleh berada di akun lain atau region lain.
Anda dapat mendefinisikan indeks sekunder saat impor, dapat di-query segera setelah impor selesai.

Ini jalur paling bersih untuk migrasi lintas-akun/lintas-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 lintas-akun):

Backup tabel sumber ke sebuah backup vault.
Copy backup ke vault di akun/region target.
Restore ke tabel baru di target.

Batasan utama:

Copy lintas-akun memerlukan kedua akun berada di AWS Organization yang sama.
Restore selalu membuat tabel baru — Anda tidak dapat me-restore menimpa tabel yang ada.
Global secondary index dipertahankan secara default (kecualikan sebagian atau semua untuk menghemat waktu/biaya restore); Anda tidak dapat menambah indeks baru saat restore.
Jebakan enkripsi: untuk mempertahankan KMS key yang sama pada restore lintas-region Anda memerlukan multi-region key; untuk lintas-akun Anda harus membagikan key ke akun target. Key milik-AWS dan terkelola-AWS tidak dapat dibagikan atau dijadikan multi-region (catatan enkripsi restore).

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

Global tables mereplikasi tabel lintas region — dan kini opsional lintas akun (multi-akun GA, Feb 2026) — secara berkelanjutan. Setiap replika melayani baca dan tulis (multi-active), dengan replikasi asinkron, last-writer-wins (dokumen global tables).

Ini bukan alat "salin dan tinggalkan" — ini replikasi berkelanjutan. Gunakan saat Anda ingin region tujuan tetap sinkron tanpa batas waktu (DR, baca lokal latensi rendah), bukan untuk migrasi sekali-pakai yang bersih. Tambahkan region ke tabel yang ada dan DynamoDB akan mengisi-balik data yang ada ke replika baru.

Jebakan operasional (semua pendekatan)

GSI tidak gratis untuk dibuat ulang. Penyalinan scan+write tidak membawa indeks — Anda mendefinisikannya di target dan indeks itu mengisi-balik (dan berbiaya) secara terpisah. Rencanakan tata letak GSI vs LSI Anda di tujuan sejak awal; LSI hanya dapat dibuat pada waktu pembuatan-tabel (dokumen LSI).
Mode kapasitas tidak ditransfer. Tabel baru dimulai dengan mode apa pun yang Anda tetapkan, bukan milik sumber. Estimasikan beban tulis sebelum penyalinan scan+write — ukur item representatif dengan kalkulator ukuran item dan kalikan dengan jumlah item untuk memperkirakan WCU.
TTL, stream, auto-scaling, dan tag adalah setelan tabel, bukan data — tidak satu pun metode penyalinan membawa semuanya. Terapkan ulang di target.
DynamoDB JSON ≠ JSON biasa. Ekspor dan scan mengeluarkan DynamoDB-JSON ber-type-tag; jika Anda bertransformasi di perjalanan, konverter DynamoDB JSON menangani marshalling-nya.

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 ekspor/impor terkelola atau AWS Backup.

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

Bagaimana saya menyalin tabel DynamoDB ke region lain? Ekspor/impor S3 dan AWS Backup keduanya mendukung lintas-region. Untuk sinkronisasi lintas-region berkelanjutan alih-alih penyalinan sekali-pakai, tambahkan replika global-table di region target.

Apakah menyalin tabel menyalin indeksnya? Impor S3 dan restore AWS Backup memungkinkan Anda mempertahankan/mendefinisikan indeks sekunder; skrip scan+write tidak — Anda membuat indeks di target sendiri, dan indeks itu mengisi-balik secara terpisah.

Bisakah saya mengimpor ke tabel DynamoDB yang sudah ada? Tidak. Impor S3 DynamoDB dan restore AWS Backup keduanya membuat tabel baru. Untuk menggabungkan ke tabel yang ada, gunakan skrip scan+write.

Sebuah GUI membuat cutover menjadi waras: jelajahi sumber dan target berdampingan, verifikasi jumlah item dan beberapa record sampel setelah penyalinan, dan jalankan pemeriksaan ad-hoc tanpa menulis skrip scan. Unduh DynoTable untuk memeriksa tabel lintas akun dan region selama migrasi.