Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Daftar periksa persiapan untuk tabel global DynamoDB Gunakan daftar periksa berikut untuk keputusan dan tugas saat Anda men-deploy tabel global. + Tentukan apakah kasus penggunaan Anda lebih diuntungkan dari mode konsistensi MRSC atau MREC. Apakah Anda memerlukan konsistensi yang kuat, bahkan dengan latensi yang lebih tinggi dan pengorbanan lainnya? + Tentukan jumlah dan Wilayah yang akan berpartisipasi dalam tabel global. Jika Anda berencana untuk menggunakan MRSC, putuskan apakah Anda ingin Wilayah ketiga menjadi replika atau saksi. + Tentukan mode tulis aplikasi Anda. Ini tidak sama dengan mode konsistensi. Untuk informasi selengkapnya, lihat [Tulis mode dengan tabel global DynamoDB](bp-global-table-design.prescriptive-guidance.writemodes.md). + Rencanakan strategi [Strategi perutean di DynamoDB](bp-global-table-design.prescriptive-guidance.request-routing.md), berdasarkan mode tulis Anda. + Tentukan [ Proses evakuasi Mengevakuasi Wilayah dengan tabel global Evakuasi suatu Daerah adalah proses migrasi aktivitas, biasanya aktivitas membaca dan menulis atau aktivitas membaca, jauh dari Wilayah tersebut. Mengevakuasi Wilayah aktifWilayah aktif Mengevakuasi Wilayah aktif Anda mungkin memutuskan untuk mengevakuasi Wilayah hidup karena sejumlah alasan: sebagai bagian dari aktivitas bisnis biasa (misalnya, jika Anda menggunakan mode, tulis ke satu Wilayah) follow-the-sun, karena keputusan bisnis untuk mengubah Wilayah yang saat ini aktif, sebagai tanggapan atas kegagalan dalam tumpukan perangkat lunak di luar DynamoDB, atau karena Anda menghadapi masalah umum seperti latensi yang lebih tinggi dari biasanya di dalam Wilayah. Dengan mode *tulis ke Wilayah mana pun*, mengevakuasi Wilayah aktif sangatlah mudah. Anda dapat merutekan lalu lintas ke Wilayah alternatif dengan menggunakan sistem perutean apa pun dan membiarkan operasi penulisan di Wilayah yang dievakuasi mereplikasi seperti biasa. Tulis ke satu Wilayah dan tulis ke mode Wilayah Anda biasanya digunakan dengan tabel MREC. Oleh karena itu, Anda harus memastikan bahwa semua operasi penulisan ke Wilayah aktif telah direkam sepenuhnya, diproses streaming, dan disebarkan secara global sebelum memulai operasi penulisan di Wilayah aktif baru, untuk memastikan bahwa operasi penulisan di masa depan diproses terhadap versi terbaru data. Katakanlah Wilayah A aktif dan Wilayah B pasif (baik untuk tabel lengkap atau untuk item yang ditempatkan di Wilayah A). Mekanisme umum untuk melakukan evakuasi adalah dengan menjeda operasi tulis ke A, menunggu cukup lama hingga operasi tersebut disebarkan sepenuhnya ke B, memperbarui tumpukan arsitektur untuk mengenali B sebagai aktif, lalu melanjutkan operasi tulis ke B. Tidak ada metrik yang menunjukkan kepastian mutlak bahwa Wilayah A telah sepenuhnya mereplikasi datanya ke Wilayah B. Jika Wilayah A sehat, menjeda operasi tulis ke Wilayah A dan menunggu 10 kali nilai maksimum terbaru metrik `ReplicationLatency` biasanya sudah cukup untuk menentukan bahwa replikasi tersebut selesai. Jika Wilayah A tidak sehat dan menunjukkan area lain mengalami peningkatan latensi, Anda dapat memilih kelipatan waktu tunggu yang lebih besar. Mengevakuasi Wilayah offlineWilayah offline Mengevakuasi Wilayah offline Ada kasus khusus yang perlu dipertimbangkan: Bagaimana jika Wilayah A sepenuhnya offline tanpa pemberitahuan? Ini sangat tidak mungkin tetapi harus dipertimbangkan. Mengevakuasi meja MRSC offline Jika ini terjadi dengan tabel MRSC, tidak ada yang istimewa yang perlu Anda lakukan. Tabel MRSC mendukung tujuan titik pemulihan (RPO) nol. Semua operasi penulisan yang berhasil dibuat ke tabel MRSC di Wilayah offline akan tersedia di semua tabel Wilayah lainnya, jadi tidak ada potensi kesenjangan dalam data bahkan jika Wilayah sepenuhnya offline tanpa pemberitahuan. Bisnis dapat terus menggunakan replika yang terletak di Wilayah lain. Mengevakuasi meja MREC offline Jika ini terjadi dengan tabel MREC, setiap operasi penulisan di Wilayah A yang belum disebarkan akan diadakan dan disebarkan setelah Wilayah A kembali online. Operasi tulis tidak hilang, tetapi penyebarannya tertunda tanpa batas waktu. Cara melanjutkan peristiwa ini merupakan keputusan aplikasi. Untuk kelangsungan bisnis, operasi tulis mungkin perlu diteruskan ke Wilayah B utama yang baru. Namun, jika item di Wilayah B menerima pembaruan sementara ada penyebaran operasi tulis yang tertunda untuk item tersebut dari Wilayah A, penyebaran tersebut akan disembunyikan di model *penulis terakhir menang*. Pembaruan apa pun di Wilayah B mungkin menyembunyikan permintaan tulis yang masuk. Dengan mode *tulis ke Wilayah mana pun*, operasi baca dan tulis dapat dilanjutkan di Wilayah B, percaya bahwa item di Wilayah A akan menyebar ke Wilayah B pada akhirnya dan mengenali potensi item yang hilang hingga Wilayah A kembali online. Jika memungkinkan, seperti dengan operasi penulisan idempoten, Anda harus mempertimbangkan untuk memutar ulang lalu lintas tulis terbaru (misalnya, dengan menggunakan sumber peristiwa hulu) untuk mengisi celah operasi penulisan yang berpotensi hilang dan membiarkan penulis terakhir memenangkan resolusi konflik menekan propagasi akhirnya dari operasi penulisan yang masuk. Dengan mode tulis lainnya, Anda harus mempertimbangkan sejauh mana pekerjaan dapat dilanjutkan dengan sedikit out-of-date pandangan dunia. Beberapa operasi tulis berdurasi pendek, seperti yang dilacak oleh `ReplicationLatency`, akan hilang hingga Wilayah A kembali online. Apakah bisnis bisa maju? Dalam beberapa kasus penggunaan, bisa, tetapi pada kasus lainnya mungkin tidak bisa, tanpa mekanisme mitigasi tambahan. Misalnya, bayangkan Anda harus mempertahankan saldo kredit yang tersedia tanpa gangguan bahkan setelah pemadaman penuh suatu Wilayah. Anda dapat membagi saldo menjadi dua item yang berbeda, satu homed di Wilayah A dan satu di Wilayah B, dan mulai masing-masing dengan setengah saldo yang tersedia. Ini akan menggunakan mode *tulis ke Wilayah Anda*. Pembaruan transaksional yang diproses di setiap Wilayah akan dituliskan pada salinan lokal saldo. Jika Wilayah A sepenuhnya offline, pekerjaan masih dapat dilanjutkan dengan pemrosesan transaksi di Wilayah B, dan operasi tulis akan terbatas pada bagian saldo yang disimpan di Wilayah B. Memisahkan saldo seperti ini menimbulkan kerumitan ketika saldo hampir habis atau kredit harus diseimbangkan kembali, tetapi hal ini memberikan satu contoh pemulihan bisnis yang aman bahkan dengan operasi tulis tertunda yang tidak pasti. Sebagai contoh lain, bayangkan Anda menangkap data formulir web. Anda dapat menggunakan [Optimistic Concurrency Control (OCC)](DynamoDBMapper.OptimisticLocking.md) (OCC) untuk menetapkan versi ke item data dan menyematkan versi terbaru ke formulir web sebagai bidang tersembunyi. Pada setiap pengiriman, operasi tulis berhasil hanya jika versi dalam basis data masih cocok dengan versi yang digunakan untuk membuat formulir. Jika versinya tidak cocok, formulir web bisa disegarkan (atau digabungkan secara hati-hati) berdasarkan versi saat ini dalam basis data, dan pengguna bisa melanjutkan lagi. Model OCC biasanya melindungi terhadap penimpaan klien lain dan pembuatan versi data yang baru, tetapi model ini juga dapat membantu selama failover ketika klien mungkin menemukan versi data yang lebih lama. Misalkan Anda menggunakan timestamp sebagai versinya. Formulir ini pertama kali dibangun terhadap Wilayah A pada pukul 12:00 tetapi (setelah failover) mencoba menulis ke Wilayah B dan pemberitahuan bahwa versi terbaru dalam database adalah 11:59. Dalam skenario ini, klien dapat menunggu versi 12.00 untuk disebarkan ke Wilayah B lalu menulis di atas versi tersebut, atau membangun pada 11.59 dan membuat versi 12.01 baru (yang, setelah ditulis, akan menyembunyikan versi yang masuk setelah Wilayah A pulih). Sebagai contoh ketiga, perusahaan jasa keuangan menyimpan data tentang akun pelanggan dan transaksi keuangan mereka dalam database DynamoDB. Jika terjadi pemadaman Wilayah A yang lengkap, mereka ingin memastikan bahwa aktivitas menulis apa pun yang terkait dengan akun mereka sepenuhnya tersedia di Wilayah B, atau mereka ingin mengkarantina akun mereka sebagaimana diketahui sebagian sampai Wilayah A kembali online. Alih-alih menghentikan semua bisnis, mereka memutuskan untuk menghentikan bisnis untuk sementara waktu, hanya pada sebagian kecil akun yang mereka anggap memiliki transaksi yang tidak disebarkan. Untuk mencapai hal ini, mereka menggunakan Wilayah ketiga, yang akan kita sebut Wilayah C. Sebelum memproses operasi tulis apa pun di Wilayah A, mereka menempatkan ringkasan singkat operasi yang tertunda tersebut (misalnya, jumlah transaksi baru untuk sebuah akun) di Wilayah C. Ringkasan ini cukup bagi Wilayah B untuk menentukan apakah pandangannya benar-benar mutakhir. Tindakan ini mengunci akun secara efektif sejak penulisan di Wilayah C hingga Wilayah A menerima operasi tulis dan Wilayah B menerimanya. Data di Wilayah C tidak digunakan kecuali sebagai bagian dari proses failover, setelah itu Wilayah B dapat memeriksa datanya dengan Wilayah C untuk mengetahui apakah ada akun yang kedaluwarsa. Akun-akun tersebut akan ditandai sebagai karantina sampai pemulihan Wilayah A menyebarkan sebagian data ke Wilayah B. Jika Wilayah C gagal, Wilayah D baru dapat diputar untuk digunakan sebagai gantinya. Data di Wilayah C sangat sementara, dan setelah beberapa menit Wilayah D akan memiliki up-to-date catatan yang cukup tentang operasi penulisan dalam penerbangan untuk sepenuhnya berguna. Jika Wilayah B gagal, Wilayah A dapat terus menerima permintaan tulis yang bekerja sama dengan Wilayah C. Perusahaan ini bersedia menerima penulisan dengan latensi yang lebih tinggi (ke dua Wilayah: C dan kemudian A) dan beruntung memiliki model data yang status akunnya dapat dirangkum secara ringkas. ](bp-global-table-design.prescriptive-guidance.evacuation.md#bp-global-table-design.prescriptive-guidance.evacuation.title)[Proses evakuasi](bp-global-table-design.prescriptive-guidance.evacuation.md), berdasarkan mode konsistensi, mode tulis, dan strategi perutean Anda. + Tangkap metrik tentang kesehatan, latensi, dan kesalahan di setiap Wilayah. Untuk daftar metrik DynamoDB, lihat AWS posting blog Memantau [Amazon DynamoDB untuk Kesadaran Operasional untuk](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/) daftar metrik yang harus diamati. Anda juga harus menggunakan [synthetic canary](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (permintaan buatan yang dirancang untuk mendeteksi kegagalan, dinamai menurut nama kenari di tambang batu bara), serta pengamatan langsung terhadap lalu lintas pelanggan. Tidak semua masalah akan muncul di metrik DynamoDB. + Jika Anda menggunakan MREC, atur alarm untuk setiap peningkatan berkelanjutan. `ReplicationLatency` Peningkatan mungkin menunjukkan kesalahan konfigurasi yang tidak disengaja, yaitu tabel global memiliki pengaturan tulis berbeda di Wilayah berbeda, yang menyebabkan kegagalan permintaan yang direplikasi dan peningkatan latensi. Hal ini juga dapat mengindikasikan adanya gangguan regional. [Contoh yang baik](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/) adalah menghasilkan peringatan jika rata-rata terkini melebihi 180.000 milidetik. Anda mungkin juga memperhatikan `ReplicationLatency` penurunan ke 0, yang menunjukkan replikasi terhenti. + Tetapkan pengaturan baca dan tulis maksimum yang memadai untuk setiap tabel global. + Identifikasi terlebih dahulu alasan untuk mengevakuasi suatu Wilayah. Jika keputusan melibatkan penilaian manusia, dokumentasikan semua pertimbangannya. Pekerjaan ini harus dilakukan dengan hati-hati sebelumnya, bukan di bawah tekanan. + Simpan runbook untuk setiap tindakan yang harus dilakukan saat Anda mengevakuasi suatu Wilayah. Biasanya pekerjaan yang dilakukan untuk tabel global sangat sedikit, tetapi memindahkan sisa tumpukan dapat menjadi pekerjaan yang rumit. **catatan** Dengan prosedur failover, praktik terbaik adalah hanya mengandalkan operasi pesawat data dan bukan pada operasi pesawat kontrol, karena beberapa operasi pesawat kontrol dapat terdegradasi selama kegagalan Wilayah. Untuk informasi selengkapnya, lihat posting AWS blog [Membangun aplikasi tangguh dengan tabel global Amazon DynamoDB](https://aws.amazon.com/blogs/database/part-4-build-resilient-applications-with-amazon-dynamodb-global-tables/): Bagian 4. + Uji semua aspek runbook secara berkala, termasuk evakuasi Wilayah. Runbook yang belum teruji adalah runbook yang tidak dapat diandalkan. + Pertimbangkan [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)untuk menggunakan untuk mengevaluasi ketahanan seluruh aplikasi Anda (termasuk tabel global). Resilience Hub memberikan pandangan komprehensif tentang status ketahanan portofolio aplikasi Anda secara keseluruhan melalui dasbornya. + Pertimbangkan untuk menggunakan pemeriksaan kesiapan ARC untuk mengevaluasi konfigurasi aplikasi Anda saat ini dan melacak penyimpangan dari praktik terbaik. + Saat Anda menulis pemeriksaan kesehatan untuk digunakan dengan Route 53 atau Global Accelerator, buat serangkaian panggilan yang mencakup alur database lengkap. Jika Anda membatasi pemeriksaan untuk mengonfirmasi hanya bahwa titik akhir DynamoDB sudah habis, Anda tidak akan dapat mencakup banyak mode kegagalan AWS Identity and Access Management seperti kesalahan konfigurasi (IAM), masalah penerapan kode, kegagalan dalam tumpukan di luar DynamoDB, latensi baca atau tulis yang lebih tinggi dari rata-rata, dan sebagainya. ## Pertanyaan yang Sering Diajukan (FAQ) untuk men-deploy tabel global **Berapa harga untuk tabel global?** + Operasi tulis dalam tabel DynamoDB tradisional diberi harga dalam unit kapasitas tulis WCUs (, untuk tabel yang disediakan) atau unit permintaan tulis () untuk tabel sesuai permintaan. WRUs Jika Anda menulis item 5 KB, itu dikenakan biaya 5 unit. Tulis ke tabel global diberi harga dalam unit kapasitas tulis yang direplikasi (rWCUs, untuk tabel yang disediakan) atau unit permintaan tulis yang direplikasi (rWRUs, untuk tabel sesuai permintaan). r WCUs dan r WRUs dihargai sama dengan dan. WGUs WRUs + Perubahan RWCu dan RwRU terjadi di setiap Wilayah di mana item ditulis secara langsung atau ditulis melalui replikasi. Biaya transfer data Lintas Wilayah berlaku. + Menulis ke indeks sekunder global (GSI) dianggap sebagai operasi penulisan lokal dan menggunakan unit tulis reguler. + Tidak ada kapasitas cadangan yang tersedia untuk r WCUs atau r WRUs saat ini. Membeli kapasitas cadangan untuk WCUs dapat bermanfaat untuk tabel di mana GSIs mengkonsumsi unit tulis. + Saat Anda menambahkan Wilayah baru ke tabel global, DynamoDB bootstrap Wilayah baru secara otomatis dan menagih Anda seolah-olah itu adalah pemulihan tabel, berdasarkan ukuran GB tabel. Ini juga membebankan biaya transfer data lintas wilayah. **Wilayah mana yang didukung tabel global?** [Tabel Global versi 2019.11.21 (Saat ini)](GlobalTables.md) mendukung semua Wilayah AWS untuk tabel MREC dan set Wilayah berikut untuk tabel MRSC: + Set Wilayah AS: AS Timur (Virginia Utara), AS Timur (Ohio), AS Barat (Oregon) + Set Wilayah UE: Eropa (Irlandia), Eropa (London), Eropa (Paris), Eropa (Frankfort) + Set Wilayah AP: Asia Pasifik (Tokyo), Asia Pasifik (Seoul), dan Asia Pasifik (Osaka) **Bagaimana GSIs ditangani dengan tabel global?** Di [Tabel Global versi 2019.11.21 (Saat Ini), saat](GlobalTables.md) Anda membuat GSI di satu Wilayah, GSI secara otomatis dibuat di Wilayah lain yang berpartisipasi dan diisi ulang secara otomatis. **Bagaimana cara menghentikan replikasi tabel global?** + Anda dapat menghapus tabel replika seperti Anda menghapus tabel lainnya. Menghapus tabel global akan menghentikan replikasi ke Wilayah tersebut dan menghapus salinan tabel yang disimpan di Wilayah tersebut. Namun, Anda tidak dapat menghentikan replikasi sambil menyimpan salinan tabel sebagai entitas independen, Anda juga tidak dapat menjeda replikasi. + Tabel MRSC harus ditempatkan tepat di tiga Wilayah. Untuk menghapus replika Anda harus menghapus semua replika dan saksi sehingga tabel MRSC menjadi tabel lokal. **Bagaimana DynamoDB Streams berinteraksi dengan tabel global?** + Setiap tabel global menghasilkan aliran independen berdasarkan semua operasi penulisannya, dari mana pun mereka memulai. Anda dapat menggunakan aliran DynamoDB di satu Wilayah atau di semua Wilayah (secara independen). Jika ingin memproses operasi tulis lokal tetapi tidak direplikasi, Anda dapat menambahkan atribut Wilayah Anda sendiri ke setiap item untuk mengidentifikasi Wilayah penulisan. Anda kemudian dapat menggunakan filter peristiwa Lambda untuk memanggil fungsi Lambda hanya untuk operasi tulis di Wilayah lokal. Ini membantu dengan menyisipkan dan memperbarui operasi, tetapi tidak menghapus operasi. + Tabel global yang dikonfigurasi untuk konsistensi akhir Multi-wilayah (tabel MREC) mereplikasi perubahan dengan membaca perubahan tersebut dari aliran DynamoDB pada tabel replika dan menerapkan perubahan itu ke semua tabel replika lainnya. Oleh karena itu, DynamoDB diaktifkan secara default pada semua replika dalam tabel global MREC dan tidak dapat dinonaktifkan pada replika tersebut. Proses replikasi MREC dapat menggabungkan beberapa perubahan dalam waktu singkat menjadi satu operasi tulis yang direplikasi. Akibatnya, setiap aliran replika mungkin berisi catatan yang sedikit berbeda. Catatan DynamoDB Streams pada replika MREC selalu diurutkan berdasarkan per item, tetapi urutan antar item mungkin berbeda antar replika. + Tabel global yang dikonfigurasi untuk konsistensi kuat Multi-wilayah (tabel MRSC) tidak menggunakan DynamoDB Streams untuk replikasi, jadi fitur ini tidak diaktifkan secara default pada replika MRSC. Anda dapat mengaktifkan DynamoDB Streams pada replika MRSC. Catatan DynamoDB Streams pada replika MRSC identik untuk setiap replika dan selalu diurutkan berdasarkan per item, tetapi urutan antar item mungkin berbeda antar replika. **Bagaimana tabel global menangani transaksi?** + Operasi transaksional pada tabel MRSC akan menghasilkan kesalahan. + Operasi transaksional pada tabel MREC memberikan jaminan atomisitas, konsistensi, isolasi, dan daya tahan (ACID) hanya di Wilayah tempat operasi penulisan awalnya terjadi. Transaksi tidak didukung di seluruh Wilayah dalam tabel global. Misalnya, jika Anda memiliki tabel global MREC dengan replika di Wilayah AS Timur (Ohio) dan AS Barat (Oregon) dan melakukan `TransactWriteItems` operasi di Wilayah Timur AS (Ohio), Anda mungkin mengamati transaksi yang diselesaikan sebagian di Wilayah Barat AS (Oregon) saat perubahan direplikasi. Perubahan direplikasi ke Wilayah lain hanya setelah diterapkan di Wilayah sumber. **Bagaimana tabel global berinteraksi dengan cache DynamoDB Accelerator (DAX)?** Tabel global melewati DAX dengan memperbarui DynamoDB secara langsung, sehingga DAX tidak mengetahui jika menyimpan data yang sudah usang. Cache DAX disegarkan hanya ketika TTL cache kedaluwarsa. **Apakah tanda pada tabel disebarkan?** Tidak, tanda tidak disebarkan secara otomatis. **Apakah saya harus mencadangkan tabel di semua Wilayah atau cukup satu Wilayah?** Jawabannya tergantung pada tujuan pencadangan. + Jika Anda ingin memastikan ketahanan data, DynamoDB sudah menyediakan perlindungan itu. Layanan ini memastikan ketahanan. + Jika Anda ingin menyimpan snapshot untuk catatan historis (misalnya, untuk memenuhi persyaratan peraturan), membuat cadangan di satu Wilayah sudah cukup. Anda dapat menyalin cadangan ke Wilayah tambahan dengan menggunakan AWS Backup. + Jika Anda ingin memulihkan data yang dihapus atau dimodifikasi secara keliru, gunakan [DynamoDB point-in-time recovery (PITR](PointInTimeRecovery_Howitworks.md)) di satu Wilayah. **Bagaimana cara saya menyebarkan tabel global menggunakan? CloudFormation** + CloudFormation merupakan tabel DynamoDB dan tabel global sebagai dua sumber daya terpisah: dan. `AWS::DynamoDB::Table` `AWS::DynamoDB::GlobalTable` Salah satu pendekatannya adalah membuat semua tabel yang berpotensi bersifat global dengan menggunakan `GlobalTable` konstruksi untuk menjaganya sebagai tabel mandiri pada awalnya, dan menambahkan Wilayah nanti jika perlu. + Dalam CloudFormation, setiap tabel global dikendalikan oleh satu tumpukan, dalam satu Wilayah, terlepas dari jumlah replika. Saat Anda menerapkan template Anda, CloudFormation membuat dan memperbarui semua replika sebagai bagian dari operasi tumpukan tunggal. Jangan men-deploy sumber daya [AWS::DynamoDB::GlobalTable](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-globaltable.html) yang sama di beberapa Wilayah. Tindakan tersebut tidak didukung dan akan mengakibatkan kesalahan. Jika men-deploy templat aplikasi di beberapa Wilayah, Anda dapat menggunakan ketentuan untuk membuat sumber daya `AWS::DynamoDB::GlobalTable` di satu Wilayah. Alternatifnya, Anda dapat memilih untuk menentukan sumber daya `AWS::DynamoDB::GlobalTable` Anda dalam tumpukan yang terpisah dari tumpukan aplikasi Anda, dan memastikan bahwa sumber daya tersebut disebarkan ke satu Wilayah. + Jika Anda memiliki tabel reguler dan Anda ingin mengonversinya menjadi tabel global sambil menjaganya agar tetap dikelola dengan CloudFormation kemudian mengatur kebijakan penghapusan ke`Retain`, menghapus tabel dari tumpukan, mengonversi tabel ke tabel global di konsol, dan kemudian impor tabel global sebagai sumber daya baru ke tumpukan. Untuk informasi lebih lanjut, lihat [AWS GitHub repositori](https://github.com/aws-samples/amazon-dynamodb-table-to-global-table-cdk). + Replikasi lintas akun tidak didukung saat ini.