Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Praktik terbaik untuk peralihan Wilayah di ARC Kami merekomendasikan praktik terbaik berikut untuk kesiapsiagaan pemulihan dan failover dengan sakelar Wilayah di Amazon Application Recovery Controller (ARC). **Topik** + [Jaga agar kre AWS denSIAL yang dibuat khusus dan berumur panjang tetap aman dan selalu dapat diakses ](#RSBestPracticeCredentials) + [Pilih nilai TTL yang lebih rendah untuk catatan DNS yang terlibat dalam failover ](#RSBestPracticeLowerTTL) + [Cadangkan kapasitas yang diperlukan untuk aplikasi kritis ](#RSBestPracticeCapacity) + [Gunakan operasi API bidang data yang sangat andal untuk membuat daftar dan mendapatkan informasi tentang rencana pengalihan Wilayah ](#RSBestPracticeUseDataPlane) + [Uji failover dengan ARC ](#RSBestPracticeTestFailover) **Jaga agar kre AWS denSIAL yang dibuat khusus dan berumur panjang tetap aman dan selalu dapat diakses** Dalam skenario pemulihan bencana (DR), pertahankan ketergantungan sistem seminimal mungkin dengan menggunakan pendekatan sederhana untuk mengakses AWS dan melakukan tugas pemulihan. Buat kreden [ tif jangka panjang IAM ](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html) khusus untuk tugas DR, dan simpan kredensialnya dengan aman di brankas fisik lokal atau brankas virtual, untuk diakses bila diperlukan. Dengan IAM, Anda dapat mengelola kredenSIAL keamanan secara terpusat, seperti kunci akses, dan izin untuk akses ke AWS sumber daya. Untuk tugas non-DR, sebaiknya Anda terus menggunakan akses federasi, menggunakan AWS layanan seperti [AWS Single. Sign-On ](https://aws.amazon.com/single-sign-on/) **Pilih nilai TTL yang lebih rendah untuk catatan DNS yang terlibat dalam failover** Untuk catatan DNS yang mungkin perlu Anda ubah sebagai bagian dari mekanisme failover, terutama catatan yang diperiksa kesehatan, menggunakan nilai TTL yang lebih rendah adalah tepat. Mengatur TTL 60 atau 120 detik adalah pilihan umum untuk skenario ini. Pengaturan DNS TTL (time to live) memberi tahu resolver DNS berapa lama untuk menyimpan catatan sebelum meminta yang baru. Ketika Anda memilih TTL, Anda membuat pertukaran antara latensi dan keandalan, dan daya tanggap terhadap perubahan. Dengan TTL yang lebih pendek pada catatan, resolver DNS melihat pembaruan pada catatan lebih cepat karena TTL menentukan bahwa mereka harus melakukan query lebih sering. Untuk informasi selengkapnya, lihat * Memilih nilai TTL untuk catatan DNS * di [ Praktik terbaik untuk DNS ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-dns.html) Amazon Route 53. **Cadangkan kapasitas yang diperlukan untuk aplikasi kritis** Sakelar wilayah mencakup jenis blok eksekusi yang membantu menskalakan sumber daya komputasi sebagai bagian dari pemulihan. Jika Anda menggunakan blok eksekusi ini dalam rencana, sakelar Wilayah tidak menjamin bahwa kapasitas komputasi yang diinginkan akan tercapai. Jika Anda memiliki aplikasi penting dan perlu menjamin akses ke kapasitas, kami sarankan Anda memesan kapasitas. Ada strategi yang dapat Anda ikuti untuk mencadangkan kapasitas komputasi di Wilayah sekunder sementara juga membatasi biaya. Untuk mempelajari lebih lanjut, lihat [ Lampu pilot dengan kapasitas cadangan: Cara mengoptimalkan biaya DR menggunakan Reservasi On-Demand Kapasitas](https://aws.amazon.com/blogs/architecture/pilot-light-with-reserved-capacity-how-to-optimize-dr-cost-using-on-demand-capacity-reservations/). **Gunakan operasi API bidang data yang sangat andal untuk membuat daftar dan mendapatkan informasi tentang rencana pengalihan Wilayah** Gunakan operasi API bidang data untuk bekerja dengan dan menjalankan rencana peralihan Wilayah Anda selama acara. Untuk daftar operasi bidang data switch Wilayah, lihat[Operasi API pengalihan wilayah](actions.region-switch.md). Konsol sakelar Wilayah di setiap Wilayah menggunakan operasi bidang data untuk mengeksekusi rencana peralihan Wilayah. Anda juga dapat memanggil operasi API bidang data dengan menggunakan AWS CLI atau dengan menjalankan kode yang Anda tulis menggunakan salah satu AWS SDK. ARC menawarkan keandalan ekstrim dengan API di bidang data. **Uji pemulihan aplikasi dengan ARC** Uji pemulihan aplikasi secara teratur dengan sakelar Wilayah ARC, untuk mengaktifkan tumpukan aplikasi sekunder di yang lain Wilayah AWS, atau untuk mengalihkan konfigurasi aktif-aktif dengan menjalankan rencana sakelar Wilayah untuk menonaktifkan salah satu Wilayah. Penting untuk memastikan bahwa rencana peralihan Wilayah yang telah Anda buat selaras dengan sumber daya yang benar di tumpukan Anda, dan semuanya berfungsi seperti yang Anda harapkan. Anda harus menguji ini setelah Anda mengatur sakelar Wilayah untuk lingkungan Anda, dan terus menguji secara berkala, sehingga Anda memvalidasi bahwa proses pemulihan Anda bekerja dengan benar. Lakukan pengujian ini secara teratur, sebelum Anda mengalami situasi kegagalan, untuk membantu menghindari downtime bagi pengguna Anda. **Pengalihan Wilayah ARC Failover DNS versus Route 53 Pemulihan yang dipercepat** Pemulihan yang dipercepat menyediakan RTO target 60 menit untuk API yang digunakan untuk memperbarui catatan zona yang dihosting publik yang diaktifkan untuk kemampuan ini. Jika Anda perlu mempertahankan kontrol atas RTO Anda dan tidak menunggu AWS untuk menyelesaikan pemulihan API yang diperlukan, Anda harus menggunakan kontrol ARC Routing atau blok eksekusi pemeriksaan kesehatan sakelar Wilayah ARC Route 53.