# Rencanakan Pemulihan Bencana (DR)
Memiliki cadangan dan komponen beban kerja berlebih adalah permulaan dari strategi DR Anda. [RTO dan RPO adalah sasaran](disaster-recovery-dr-objectives.md) pemulihan beban kerja Anda. Tetapkan ini berdasarkan kebutuhan bisnis. Implementasikan sebuah strategi untuk memenuhi tujuan-tujuan ini, sambil mempertimbangkan lokasi dan fungsi data dan sumber daya beban kerja. Probabilitas gangguan dan biaya pemulihan juga merupakan faktor penting yang akan membantu menginformasikan nilai bisnis dari penyediaan pemulihan bencana untuk beban kerja.
Ketersediaan dan Pemulihan Bencana sama-sama mengandalkan praktik terbaik, seperti pemantauan kegagalan, deployment ke beberapa lokasi, dan failover otomatis. Namun demikian, Ketersediaan berfokus pada komponen beban kerja, sedangkan Pemulihan Bencana berfokus pada salinan terpisah (discrete) dari keseluruhan beban kerja. Pemulihan Bencana memiliki tujuan yang berbeda dari Ketersediaan, yang berfokus pada waktu pemulihan setelah terjadi sebuah bencana.
**Topics**
+ [REL13-BP01 Menetapkan sasaran pemulihan untuk waktu henti dan kehilangan data](rel_planning_for_recovery_objective_defined_recovery.md)
+ [REL13-BP02 Menggunakan strategi pemulihan untuk memenuhi sasaran pemulihan](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Menguji implementasi pemulihan bencana untuk memvalidasi implementasi](rel_planning_for_recovery_dr_tested.md)
+ [REL13-BP04 Mengelola penyimpangan konfigurasi di lokasi atau Wilayah Pemulihan Bencana (DR)](rel_planning_for_recovery_config_drift.md)
+ [REL13-BP05 Mengotomatiskan pemulihan](rel_planning_for_recovery_auto_recovery.md)
# REL13-BP01 Menetapkan sasaran pemulihan untuk waktu henti dan kehilangan data
Kegagalan dapat merugikan bisnis Anda dalam banyak hal. Pertama, kegagalan dapat menyebabkan gangguan layanan (waktu henti). Kedua, kegagalan dapat menyebabkan data hilang, tidak konsisten, atau usang. Untuk memandu cara Anda merespons dan memulihkan diri dari kegagalan, tentukan Sasaran Waktu Pemulihan (RTO) dan Sasaran Titik Pemulihan (RPO) untuk setiap beban kerja. *Sasaran Waktu Pemulihan (RTO)* adalah jeda waktu maksimum yang dapat diterima antara gangguan layanan dan pemulihan layanan. *Sasaran Titik Pemulihan (RPO)* adalah waktu maksimum yang dapat diterima sejak titik pemulihan data terakhir.
**Hasil yang diinginkan:** Setiap beban kerja memiliki RTO dan RPO yang ditentukan berdasarkan pertimbangan teknis dan dampak bisnis.
**Anti-pola umum:**
+ Anda belum menentukan sasaran pemulihan.
+ Anda memilih sasaran pemulihan tanpa pertimbangan matang.
+ Anda memilih sasaran pemulihan yang terlalu longgar dan tidak memenuhi sasaran bisnis.
+ Anda belum mengevaluasi dampak waktu henti dan kehilangan data.
+ Anda memilih sasaran pemulihan yang tidak realistis, seperti nol waktu pemulihan atau nol kehilangan data, yang mungkin tidak dapat dicapai untuk konfigurasi beban kerja Anda.
+ Anda memilih sasaran pemulihan yang lebih ketat daripada sasaran bisnis yang sesungguhnya. Hal ini memaksakan implementasi pemulihan yang lebih mahal dan lebih rumit dibandingkan yang dibutuhkan beban kerja.
+ Anda memilih sasaran pemulihan yang tidak kompatibel dengan sasaran beban kerja dependen.
+ Anda tidak mempertimbangkan persyaratan peraturan dan kepatuhan.
**Manfaat menjalankan praktik terbaik ini:** Ketika Anda menetapkan RTO dan RPO untuk beban kerja Anda, Anda menetapkan tujuan yang jelas dan terukur untuk pemulihan berdasarkan kebutuhan bisnis Anda. Setelah Anda menetapkan sasaran-sasaran tersebut, Anda dapat membuat rencana pemulihan bencana (DR) yang disesuaikan untuk memenuhinya.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
Buat matriks atau lembar kerja untuk membantu memandu perencanaan pemulihan bencana Anda. Dalam matriks Anda, buat kategori atau tingkatan beban kerja yang berbeda berdasarkan dampak bisnisnya (seperti kritis, tinggi, sedang, dan rendah) serta RTO dan RPO terkait yang ditargetkan untuk setiap kategori. Matriks berikut memberikan contoh (perhatikan bahwa nilai RTO dan RPO Anda mungkin berbeda) yang dapat Anda ikuti:
![\[Bagan yang memperlihatkan matriks pemulihan bencana\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/reliability-pillar/images/disaster-recovery-matrix.png)
Untuk setiap beban kerja, selidiki dan pahami dampak waktu henti serta kehilangan data pada bisnis Anda. Dampaknya biasanya meningkat seiring dengan waktu henti dan kehilangan data, tetapi bentuk dampaknya dapat berbeda berdasarkan jenis beban kerja. Misalnya, waktu henti hingga satu jam mungkin berdampak rendah, tetapi setelah itu, dampaknya bisa meningkat dengan cepat. Dampak dapat berupa banyak hal, termasuk dampak keuangan (seperti kehilangan pendapatan), dampak reputasi (termasuk hilangnya kepercayaan pelanggan), dampak operasional (seperti gaji yang terlambat atau penurunan produktivitas), dan risiko peraturan. Jika sudah, tetapkan beban kerja ke tingkatan yang sesuai.
Pertimbangkan pertanyaan-pertanyaan berikut ketika Anda menganalisis dampak kegagalan:
1. Berapa lama waktu maksimum beban kerja bisa tidak tersedia sebelum menimbulkan dampak yang signifikan pada bisnis?
1. Seberapa besar dampak, dan seperti apa bentuknya, yang akan ditimbulkan pada bisnis dari suatu gangguan beban kerja? Pertimbangkan semua jenis dampak, termasuk keuangan, reputasi, operasional, dan peraturan.
1. Berapakah jumlah data maksimum yang dapat hilang atau tidak dapat dipulihkan sebelum menimbulkan dampak yang signifikan pada bisnis?
1. Apakah data yang hilang bisa dibuat lagi dari sumber lain (juga dikenal sebagai data *turunan*)? Jika demikian, pertimbangkan juga RPO dari semua data sumber yang digunakan untuk membuat ulang data beban kerja.
1. Apa saja sasaran pemulihan dan ekspektasi ketersediaan beban kerja yang bergantung pada sasaran pemulihan ini (hilir)? Sasaran beban kerja Anda harus dapat dicapai mengingat kemampuan pemulihan dependensi hilirnya. Pertimbangkan kemungkinan solusi alternatif atau mitigasi untuk dependensi hilir yang dapat meningkatkan kemampuan pemulihan beban kerja ini.
1. Apa saja sasaran pemulihan dan ekspektasi ketersediaan beban kerja yang bergantung pada sasaran pemulihan ini (hulu)? Sasaran beban kerja hulu mungkin mengharuskan beban kerja ini memiliki kemampuan pemulihan yang lebih ketat daripada yang terlihat pada awalnya.
1. Apakah ada sasaran pemulihan yang berbeda berdasarkan jenis insiden? Misalnya, Anda mungkin memiliki RTO dan RPO yang berbeda, bergantung pada apakah insiden tersebut memengaruhi suatu Zona Ketersediaan atau seluruh Wilayah.
1. Apakah sasaran pemulihan Anda berubah selama peristiwa atau waktu tertentu dalam setahun? Misalnya, Anda mungkin memiliki RTO dan RPO yang berbeda di sekitar musim belanja liburan, acara olahraga, obral khusus, dan peluncuran produk baru.
1. Bagaimana sasaran pemulihan selaras dengan strategi pemulihan bencana lini bisnis dan organisasi yang mungkin Anda miliki?
1. Apakah ada konsekuensi hukum atau kontrak yang perlu dipertimbangkan? Misalnya, apakah Anda secara kontraktual berkewajiban untuk menyediakan layanan dengan RTO atau RPO tertentu? Konsekuensi apa yang mungkin Anda terima jika tidak memenuhi kewajiban tersebut?
1. Apakah Anda diwajibkan untuk menjaga integritas data untuk memenuhi persyaratan peraturan atau kepatuhan?
Lembar kerja berikut dapat membantu evaluasi Anda untuk setiap beban kerja. Anda dapat mengubah lembar kerja ini sesuai kebutuhan spesifik Anda, seperti memasukkan pertanyaan tambahan.
![\[Lembar kerja\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/reliability-pillar/images/worksheet.png)
### Langkah-langkah implementasi
1. Identifikasi pemangku kepentingan bisnis dan tim teknis yang bertanggung jawab atas setiap beban kerja, dan libatkan mereka.
1. Buat kategori atau tingkat kekritisan untuk dampak beban kerja di organisasi Anda. Contoh kategori meliputi kritis, tinggi, sedang, dan rendah. Untuk setiap kategori, pilih RTO dan RPO yang mencerminkan tujuan serta persyaratan bisnis Anda.
1. Tetapkan salah satu kategori dampak yang Anda buat di langkah sebelumnya ke setiap beban kerja. Untuk memutuskan bagaimana suatu beban kerja dipetakan ke suatu kategori, pertimbangkan pentingnya beban kerja bagi bisnis serta dampak gangguan atau kehilangan data, lalu gunakan pertanyaan di atas untuk memandu Anda. Hal ini menghasilkan RTO dan RPO untuk setiap beban kerja.
1. Pertimbangkan RTO dan RPO untuk setiap beban kerja yang ditentukan pada langkah sebelumnya. Libatkan tim bisnis dan teknis beban kerja untuk menentukan apakah sasaran harus disesuaikan. Misalnya, pemangku kepentingan bisnis dapat menentukan bahwa target yang lebih ketat diperlukan. Atau, tim teknis dapat menentukan bahwa target harus dimodifikasi untuk membuatnya dapat dicapai dengan sumber daya yang tersedia dan keterbatasan teknologi.
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [REL09-BP04 Melakukan pemulihan data secara berkala untuk memverifikasi integritas dan proses pencadangan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_periodic_recovery_testing_data.html)
+ [REL12-BP01 Menggunakan playbook untuk menyelidiki kegagalan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency.html)
+ [REL13-BP02 Menggunakan strategi pemulihan untuk memenuhi sasaran pemulihan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)
+ [REL13-BP03 Menguji implementasi pemulihan bencana untuk memvalidasi implementasi](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)
**Dokumen terkait:**
+ [AWS Blog Arsitektur : Seri Pemulihan Bencana](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Pemulihan Bencana Beban Kerja di AWS: Pemulihan di Cloud (Laporan Resmi AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Mengelola kebijakan ketangguhan dengan AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html)
+ [Partner APN: partner yang dapat membantu Anda melakukan pemulihan bencana](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: produk yang dapat digunakan untuk pemulihan bencana](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Video terkait:**
+ [AWS re:Invent 2018: Pola Arsitektur untuk Aplikasi Aktif-Aktif Multi-Wilayah](https://youtu.be/2e29I3dA8o4)
+ [Pemulihan Bencana Beban Kerja di AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
# REL13-BP02 Menggunakan strategi pemulihan untuk memenuhi sasaran pemulihan
Tentukan strategi pemulihan bencana (DR) yang memenuhi sasaran pemulihan beban kerja. Pilih strategi seperti pencadangan dan pemulihan, standby (aktif/pasif), atau aktif/aktif.
**Hasil yang diinginkan:** Strategi DR ditentukan dan diimplementasikan untuk setiap beban kerja agar beban kerja dapat mencapai sasaran DR. Strategi DR antara beban kerja menggunakan pola yang dapat digunakan kembali (seperti strategi yang telah dijelaskan sebelumnya),
**Anti-pola umum:**
+ Mengimplementasikan prosedur pemulihan yang tidak konsisten untuk beban kerja dengan sasaran DR yang serupa.
+ Membiarkan strategi DR diimplementasikan secara ad-hoc saat bencana terjadi.
+ Tidak memiliki rencana untuk pemulihan bencana.
+ Dependensi pada operasi bidang kontrol selama pemulihan.
**Manfaat menjalankan praktik terbaik ini:**
+ Dengan strategi pemulihan yang ditentukan, Anda dapat menggunakan prosedur tes dan peralatan umum.
+ Menggunakan strategi pemulihan yang ditentukan akan meningkatkan penyebaran pengetahuan antara tim dan implementasi DR pada beban kerja milik mereka.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi. Tanpa strategi DR yang direncanakan, diimplementasikan, dan diuji, Anda akan kesulitan mencapai sasaran pemulihan ketika bencana terjadi.
## Panduan implementasi
Strategi DR mengandalkan kemampuan untuk mempertahankan beban kerja di situs pemulihan jika lokasi utama tidak dapat menjalankan beban kerja. Sasaran pemulihan yang paling umum adalah RTO dan RPO, seperti yang didiskusikan dalam [REL13-BP01 Menetapkan sasaran pemulihan untuk waktu henti dan kehilangan data](rel_planning_for_recovery_objective_defined_recovery.md).
Strategi DR di beberapa Zona Ketersediaan (AZ) dalam Wilayah AWS tunggal, dapat menyediakan mitigasi bencana seperti kebakaran, banjir, dan pemadaman listrik besar-besaran. Anda dapat menggunakan strategi DR yang menggunakan beberapa Wilayah jika memang perlu mengimplementasikan perlindungan terhadap peristiwa yang membuat beban kerja tidak dapat dijalankan di Wilayah AWS.
Anda harus memilih salah satu dari strategi berikut saat merancang strategi DR di beberapa Wilayah. Mereka terdaftar dalam urutan peningkatan biaya dan kompleksitas, dan penurunan urutan RTO dan RPO. *Wilayah Pemulihan* mengacu pada Wilayah AWS selain dari yang utama yang digunakan untuk beban kerja Anda.
![\[Diagram menampilkan strategi DR\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/reliability-pillar/images/disaster-recovery-strategies.png)
+ **Cadangkan dan pulihkan** (RPO dalam hitungan jam, RTO dalam 24 jam atau kurang): Cadangkan data dan aplikasi Anda ke dalam Wilayah pemulihan. Menggunakan pencadangan otomatis atau berkelanjutan dapat mengaktifkan pemulihan titik waktu (PITR), yang dalam beberapa kasus dapat menurunkan RPO hingga 5 menit dalam beberapa kasus. Saat terjadi bencana, Anda akan melakukan deployment infrastruktur (menggunakan infrastruktur sebagai kode untuk mengurangi RTO), melakukan deploymennt kode, dan memulihkan data yang dicadangkan untuk memulihkan dari bencana di Wilayah pemulihan.
+ **Pilot light** (RPO dalam menit, RTO dalam kelipatan sepuluh menit): Sediakan salinan infrastruktur beban kerja inti di Wilayah pemulihan. Replikasikan data ke Wilayah pemulihan dan buat cadangan di sana. Sumber daya yang diperlukan untuk mendukung replikasi dan pencadangan data, misalnya basis data dan penyimpanan objek, selalu aktif. Elemen lainnya seperti server aplikasi atau komputasi nirserver tidak di-deploy, tetapi dapat dibuat saat dibutuhkan dengan kode aplikasi dan konfigurasi yang diperlukan.
+ **Warm standby** (RPO dalam hitungan detik, RTO dalam hitungan menit): Mengaktifkan versi yang diturunkan tetapi berfungsi sepenuhnya dari beban kerja yang selalu dijalankan di Wilayah pemulihan. Sistem yang vital untuk bisnis sepenuhnya digandakan dan selalu aktif, tetapi dengan armada yang diturunkan skalanya. Data direplikasi dan berada dalam Wilayah pemulihan. Ketika pemulihan diperlukan, sistem dinaikkan skalanya dengan cepat untuk menangani beban produksi. Semakin warm standby dinaikkan skalanya, akan semakin rendah pengandalan RTO dan bidang kontrol. Saat skala sesuai sepenuhnya, ini disebut sebagai *hot standby*.
+ **Multi-Wulayah (multi-lokasi) aktif-aktif** (RPO mendekati nol, RTO berpotensi nol): Beban kerja Anda di-deploy ke, dan aktif menangani lalu lintas dari, beberapa Wilayah AWS. Strategi ini perlu menyinkronkan data di seluruh Wilayah. Konflik potensial yang disebabkan oleh menulis catatan yang sama di dua replika wilayah yang berbeda harus dihindari atau ditangani, karena bisa menjadi kompleks. Replikasi data bermanfaat untuk sinkronisasi data dan akan melindungi Anda terhadap beberapa jenis bencana, tetapi tidak melindungi terhadap kerusakan atau kehilangan data kecuali solusi juga disertai opsi untuk pemulihan titik waktu.
**catatan**
Perbedaan antara pilot light dan warm standby terkadang sulit dimengerti. Keduanya menyertakan lingkungan di Wilayah pemulihan dengan salinan aset wilayah utama. Perbedaannya adalah pilot light tidak dapat memproses permintaan tanpa lebih dulu melakukan tindakan tambahan, sedangkan warm standby dapat menangani lalu lintas (pada kapasitas yang dikurangi) dengan cepat. Pilot light mengharuskan Anda mengaktifkan server, menaikkan skala, dan mungkin mengharuskan Anda melakukan deployment infrastruktur tambahan (bukan inti). Sementara itu, warm standby hanya meminta Anda untuk menaikkan skala (semuanya sudah di-deploy dan dijalankan). Pilih berdasarkan kebutuhan RTO dan RPO Anda.
Apabila ada kekhawatiran tentang biaya, dan Anda ingin mencapai sasaran RPO dan RTO yang serupa dengan yang ditetapkan dalam strategi warm standby, Anda dapat mempertimbangkan solusi cloud-native, seperti AWS Elastic Disaster Recovery, yang akan mengambil pendekatan pilot light dan menawarkan target RPO dan RTO lebih baik.
**Langkah-langkah implementasi**
1. **Tentukan strategi DR yang akan memenuhi persyaratan pemulihan untuk beban kerja ini.**
Saat memilih strategi DR, Anda harus memilih antara mengurangi waktu henti dan kehilangan data (RTO dan RPO) dan meningkatkan biaya dan kompleksitas untuk mengimplementasikan strategi, atau sebaliknya. Sebaiknya hindari strategi yang lebih sulit dari yang dibutuhkan, karena hal ini akan menambah biaya yang tidak perlu.
Misalnya, dalam diagram berikut, bisnis telah menentukan RTO maksimum yang diizinkan serta batas yang dapat digunakan pada strategi pemulihan layanan. Berdasarkan sasaran bisnis, strategi DR pilot light atau warm standby akan memenuhi kriteria biaya dan RTO.
![\[Grafik yang menampilkan pemilihan strategi DR berdasarkan RTO dan biaya\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/reliability-pillar/images/choosing-a-dr-strategy.png)
Untuk mempelajari lebih lanjut, lihat [Business Continuity Plan (BCP](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html)).
1. **Tinjau pola tentang bagaimana strategi DR yang dipilih dapat diimplementasikan.**
Langkah ini digunakan untuk memahami cara Anda mengimplementasikan strategi yang dipilih. Strategi dijelaskan menggunakan Wilayah AWS sebagai situs utama dan pemulihan. Namun, Anda juga dapat memilih untuk menggunakan Zona Ketersediaan dalam Wilayah tunggal sebagai strategi DR, yang menggunakan beberapa elemen dari berbagai strategi tersebut.
Dalam langkah berikut ini, Anda dapat menerapkan strategi pada beban kerja spesifik Anda.
**Pencadangan dan pemulihan**
*Cadangkan dan pulihkan* adalah strategi yang tidak terlalu kompleks untuk diimplementasikan, tetapi akan memerlukan waktu dan usaha lebih untuk mengembalikan beban kerja, sehingga RTO dan RPO menjadi lebih tinggi. Sebaiknya selalu buat cadangan data, dan salin cadangan tersebut ke situs lain (misalnya Wilayah AWS lain).
![\[Diagram menampilkan arsitektur cadangan dan pemulihan\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/reliability-pillar/images/backup-restore-architecture.png)
Untuk rincial lebih lanjut pada strategi ini lihat [Arsitektur Pemulihan Bencana (DR) di AWS, Bagian II: Pencadangan dan Pemulihan dengan Pemulihan Cepat](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
**Pilot light**
Dengan pendekatan *pilot light*, Anda mereplikasi data dari Wilayah utama ke Wilayah pemulihan. Sumber daya inti yang digunakan untuk infrastruktur beban kerja di-deploy di Wilayah pemulihan. Namun, sumber daya tambahan dan dependensi lainnya masih diperlukan untuk membuat tumpukan fungsional ini. Misalnya, dalam gambar 20, tidak ada instans komputasi yang di-deploy.
![\[Diagram menampilkan arsitektur pilot light\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/reliability-pillar/images/pilot-light-architecture.png)
Untuk detail lebih lanjut tentang strategi ini, lihat [Arsitektur Pemulihan Bencana (DR) di AWS, Bagian III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Warm standby**
Pendekatan *warm standby* melibatkan memastikan ada salinan lingkungan produksi yang skalanya diturunkan tetapi berfungsi sepenuhnya di Wilayah lainnya. Pendekatan ini memperpanjang konsep pilot light dan mempercepat waktu pemulihan karena beban kerja selalu aktif di Wilayah lainnya. Jika Wilayah pemulihan di-deploy pada kapasitas penuh, hal ini disebut dengan *hot standby*.
![\[Diagram menampilkan Gambar 21: Arsitektur warm standby\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/reliability-pillar/images/warm-standby-architecture.png)
Saat menggunakan warm standby atau pilot light, Anda perlu menaikkan skala sumber daya di Wilayah pemulihan. Untuk memverifikasi kapasitas yang tersedia bila diperlukan, pertimbangkan penggunaan untuk [reservasi kapasitas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) untuk instans EC2. Jika menggunakan AWS Lambda, [konkurensi yang disediakan](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) dapat menyediakan lingkungan runtime sehingga siap untuk segera merespons invokasi fungsi Anda.
Untuk detail lebih lanjut tentang strategi ini, lihat [Arsitektur Pemulihan Bencana (DR) di AWS, Bagian III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Multi-situs aktif/aktif**
Anda dapat menjalankan beban kerja secara berkelanjutan di beberapa Wilayah sebagai bagian dari strategi *multi-situs aktif/aktif*. Multi-situs aktif/aktif menjalankan lalu lintas dari semua wilayah ke wilayah tempatnya di-deploy. Konsumen dapat memilih strategi ini untuk alasan selain dari DR. Strategi ini dapat digunakan untuk meningkatkan ketersediaan, atau saat melakukan deployment beban kerja ke audiens global (untuk menempatkan titik akhir lebih dekat dengan pengguna dan/atau melakukan deployment tumpukan yang dilokalkan untuk audiens di wilayah tersebut). Sebagai strategi DR, jika beban kerja tidak dapat didukung di salah satu dari Wilayah AWS tempatnya di-deploy, Wilayah tersebut dievakuasi, dan Wilayah sisanya digunakan untuk mempertahankan ketersediaan. Multi-situs aktif/aktif adalah strategi DR yang paling sulit dioperasikan, dan sebaiknya hanya dipilih saat persyaratan bisnis mengharuskannya.
![\[Diagram menampilkan arsitektur multi-situs aktif/aktif\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/reliability-pillar/images/multi-site-active-active-architecture.png)
Untuk detail lebih lanjut tentang strategi ini, lihat [Arsitektur Pemulihan Bencana (DR) di AWS, Bagian IV: Multi-situs Aktif/Aktif](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/).
**AWS Elastic Disaster Recovery**
Jika Anda mempertimbangkan lampu pilot atau strategi siaga hangat untuk pemulihan bencana, AWS Elastic Disaster Recovery dapat memberikan pendekatan alternatif dengan manfaat yang lebih baik. Elastic Disaster Recovery dapat menawarkan target RPO dan RTO yang mirip dengan siaga hangat, tetapi mempertahankan pendekatan lampu pilot berbiaya rendah. Elastic Disaster Recovery mereplikasi data Anda dari wilayah utama Anda ke Wilayah pemulihan Anda, menggunakan perlindungan data berkelanjutan untuk mencapai RPO yang diukur dalam hitungan detik dan RTO yang dapat diukur dalam hitungan menit. Hanya sumber daya yang diperlukan untuk mereplikasi data yang di-deploy di wilayah pemulihan, sehingga menekan biaya tetap rendah, serupa dengan strategi pilot light. Ketika menggunakan Elastic Disaster Recovery, layanan mengoordinasi dan mengatur pemulihan sumber daya komputasi ketika dimulai sebagai bagian dari failover atau latihan.
![\[Diagram arsitektur yang menjelaskan cara AWS Elastic Disaster Recovery beroperasi.\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/reliability-pillar/images/drs-architecture.png)
**Praktik tambahan untuk melindungi data**
Dengan semua strategi, Anda juga harus melakukan mitigasi terhadap bencana data. Replikasi data berkelanjutan melindungi Anda terhadap beberapa jenis bencana, tetapi tidak melindungi terhadap kerusakan atau kehilangan data kecuali strategi juga disertai penentuan versi data yang disimpan atau opsi pemulihan titik waktu. Selain replika, Anda juga harus mencadangkan data yang direplikasi di situs pemulihan untuk membuat pencadangan titik waktu.
**Menggunakan beberapa Zona Ketersediaan (AZ) dalam Wilayah AWS tunggal**
Saat menggunakan beberapa AZ dalam Wilayah tunggal, implementasi DR Anda menggunakan beberapa elemen dari strategi di atas. Anda harus terlebih dahulu membuat arsitektur ketersediaan tinggi (HA) menggunakan beberapa AZ yang ditampilkan dalam Gambar 23. Arsitektur ini menggunakan pendekatan aktif/aktif multi-situs, karena [instans Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) dan [Penyeimbang Beban Elastis](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) memiliki sumber daya yang digunakan di beberapa AZ yang secara aktif memberikan permintaan. Arsitektur juga menunjukkan hot standby, di mana jika instans [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) utama gagal (atau AZ itu sendiri gagal), maka instans siaga dipromosikan ke primer.
![\[Diagram menampilkan Gambar 24: Arsitektur Multi-AZ\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/reliability-pillar/images/multi-az-architecture2.png)
Selain arsitektur HA ini, Anda perlu menambahkan cadangan data yang dibutuhkan untuk menjalankan beban kerja. Ini sangat penting untuk data yang dibatasi pada satu zona seperti [volume Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) atau [cluster Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html). Jika sebuah AZ gagal, Anda perlu memulihkan data ini ke AZ lainnya. Jika memungkinkan, Anda perlu menyalin cadangan data ke Wilayah AWS sebagai lapisan perlindungan tambahan.
Pendekatan alternatif yang kurang umum untuk DR Wilayah tunggal dan Multi-AZ diilustrasikan dalam postingan blog, [Membangun aplikasi yang sangat tangguh menggunakan Pengontrol Pemulihan Aplikasi Amazon, Bagian 1: tumpukan Wilayah Tunggal](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/). Strategi yang digunakan di sini adalah mempertahankan isolasi sebanyak mungkin di antara AZ, seperti bagaimana Wilayah dioperasikan. Dengan menggunakan strategi alternatif ini, Anda dapat memilih pendekatan aktif/aktif atau aktif/pasif.
**catatan**
Beberapa beban kerja memiliki persyaratan residensi data peraturan. Jika ini diterapkan untuk beban kerja di lokalitas yang saat ini hanya memiliki satu Wilayah AWS, maka multi-Wilayah tidak akan sesuai untuk kebutuhan bisnis. Strategi multi-AZ memberikan perlindungan yang baik terhadap sebagian besar bencana.
1. **Evaluasikan sumber daya beban kerja, dan seperti apa konfigurasinya di Wilayah pemulihan sebelum failover (selama operasi normal).**
Untuk infrastruktur dan sumber daya AWS, gunakan infrastruktur sebagai kode seperti [AWS CloudFormation](https://aws.amazon.com/cloudformation) atau alat pihak ketiga seperti Hashicorp Terraform. Untuk melakukan deployment di beberapa akun dan Wilayah dengan operasi tunggal, Anda dapat menggunakan [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html). Untuk strategi Multi-situs aktif/aktif dan Hot Standby, infrastruktur yang di-deploy di Wilayah pemulihan memiliki sumber daya yang sama seperti Wilayah utama. Untuk strategi Pilot Light dan Warm Standby, infrastruktur yang di-deploy memerlukan tindakan tambahan agar berubah menjadi siap produksi. Dengan menggunakan [parameter](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) dan [logika bersyarat](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html) CloudFormation, Anda dapat mengontrol apakah tumpukan yang diterapkan aktif atau siaga dengan [satu templat](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/). Ketika menggunakan Elastic Disaster Recovery, layanan akan mereplikasi dan mengatur pemulihan konfigurasi aplikasi dan sumber daya komputasi.
Semua strategi DR mengharuskan sumber data dicadangkan di dalam Wilayah AWS, dan kemudian cadangan tersebut disalin ke Wilayah pemulihan. [AWS Backup](https://aws.amazon.com/backup/) akan menyediakan tampilan tersentralisasi di mana Anda dapat mengonfigurasi, menjadwalkan, dan memantau cadangan untuk sumber daya ini. Untuk Pilot Light, Warm Standby, dan Multi-situs aktif/aktif, Anda juga harus mereplikasi data dari Wilayah utama ke sumber daya data di Wilayah pemulihan, seperti instans DB [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds) atau tabel [Amazon DynamoDB](https://aws.amazon.com/dynamodb). Dengan demikian, sumber data ini aktif dan siap menangani permintaan di Wilayah pemulihan.
Untuk mempelajari lebih lanjut tentang cara layanan-layanan AWS beroperasi di seluruh Wilayah, lihat seri blog ini tentang [Membuat Aplikasi Multi-Wilayah dengan Layanan AWS](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/).
1. **Tentukan dan implementasikan cara Anda mempersiapkan Wilayah untuk failover saat dibutuhkan (selama peristiwa bencana).**
Untuk multi-situs aktif/aktif, failover berarti mengevakuasi Wilayah dan mengandalkan Wilayah aktif yang tersisa. Secara umum, Wilayah tersebut siap menerima lalu lintas. Untuk strategi Pilot Light dan Warm Standby, tindakan pemulihan perlu mencakup deployment sumber daya yang hilang, seperti instans EC2 dalam Gambar 20, juga sumber daya yang hilang lainnya.
Untuk semua strategi di atas, Anda mungkin perlu mengubah instans hanya-baca basis data menjadi instans baca/tulis.
Untuk pencadangan dan pemulihan, pemulihan data dari cadangan menghasilkan sumber daya untuk data tersebut seperti volume EBS, instans RDS DB, dan tabel DynamoDB. Anda juga perlu memulihkan infrastruktur dan melakukan deployment kode. Anda dapat menggunakan AWS Backup untuk memulihkan data di Wilayah pemulihan. Lihat [REL09-BP01 Mengidentifikasi dan mencadangkan data yang perlu dicadangkan, atau melakukan reproduksi ulang data dari sumber](rel_backing_up_data_identified_backups_data.md) untuk detail selengkapnya. Membangun kembali infrastruktur termasuk membuat sumber daya seperti instans EC2 selain [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc), subnet, dan grup keamanan yang diperlukan. Anda dapat mengotomatiskan banyak proses pemulihan. Untuk mempelajari caranya, silakan lihat [posting blog ini](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
1. **Tentukan dan implementasikan cara Anda akan merutekan kembali lalu lintas ke failover saat dibutuhkan (selama peristiwa bencana).**
Operasi failover ini dapat dimulai secara otomatis dan manual. Failover yang dimulai secara otomatis berdasarkan pemeriksaan kondisi atau alarm harus digunakan dengan hati-hati karena failover yang tidak perlu (alarm palsu) dapat dikenakan biaya seperti ketidaktersediaan dan kehilangan data. Oleh karena itu, Failover yang dimulai secara manual sering digunakan. Dalam kasus ini, Anda masih harus mengotomatiskan langkah failover, sehingga inisiasi manual akan seperti menekan tombol.
Ada beberapa opsi manajemen lalu lintas yang perlu dipertimbangkan saat menggunakan layanan AWS. Salah satu opsinya adalah menggunakan [Amazon Route 53](https://aws.amazon.com/route53). Dengan menggunakan Amazon Route 53, Anda dapat mengaitkan beberapa titik akhir IP di satu Wilayah AWS atau lebih dengan nama domain Route 53. Untuk mengimplementasikan failover yang dimulai secara manual, Anda dapat menggunakan [Pengontrol Pemulihan Aplikasi Amazon](https://aws.amazon.com/application-recovery-controller/), yang menyediakan API bidang data dengan ketersediaan yang tinggi untuk mengalihkan lalu lintas ke Wilayah pemulihan. Saat mengimplementasikan failover, gunakan operasi bidang data dan hindari bidang kontrol yang dideskripsikan di [REL11-BP04 Mengandalkan bidang data dan bukan bidang kontrol selama pemulihan](rel_withstand_component_failures_avoid_control_plane.md).
Untuk mempelajari lebih lanjut tentang ini dan opsi lainnya, lihat [bagian ini dari Laporan Resmi Pemulihan Bencana.](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light)
1. **Rancang rencana terkait bagaimana beban kerja akan failback.**
Failback adalah saat Anda mengembalikan operasi beban kerja ke Wilayah utama, setelah bencana berakhir. Penyediaan infrastruktur dan kode untuk Wilayah utama umumnya mengikuti langkah yang sama yang digunakan saat memulai, dengan mengandalkan infrastruktur sebagai kode dan pipeline deployment kode. Tantangan failback adalah mengembalikan penyimpanan data, dan memastikan konsistensi dengan Wilayah pemulihan dalam operasi.
Dalam status failed over, basis data dalam Wilayah pemulihan bersifat waktu nyata dan memiliki data terbaru. Tujuannya adalah untuk menyinkronkan kembali dari Wilayah pemulihan ke Wilayah utama, memastikannya tetap terbaru.
Hal ini dilakukan secara otomatis untuk beberapa layanan AWS. Jika menggunakan [tabel global Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/), meskipun tabel di Wilayah utama menjadi tidak tersedia, saat kembali online, DynamoDB akan melanjutkan penulisan yang tertunda. Jika menggunakan [Basis Data Global Amazon Aurora](https://aws.amazon.com/rds/aurora/global-database/) dan menggunakan [failover terencana dan terkelola](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover), topologi replikasi Aurora basis data global yang ada dipertahankan. Dengan demikian, instans baca/tulis sebelumnya di Wilayah utama akan menjadi replika dan menerima pembaruan dari Wilayah pemulihan.
Dalam kasus saat ini tidak dibuat otomatis, Anda perlu menetapkan ulang basis data di Wilayah utama sebagai replika dari basis data di Wilayah pemulihan. Dalam banyak kasus, ini akan melibatkan penghapusan basis data utama yang lama dan membuat replika yang baru.
Setelah failover, jika Anda dapat tetap menjalankannya di Wilayah pemulihan, pertimbangkan membuat ini menjadi Wilayah utama yang baru. Anda masih harus melakukan semua langkah di atas untuk membuat Wilayah utama sebelumnya menjadi Wilayah pemulihan. Beberapa organisasi melakukan rotasi terjadwal, menukar Wilayah utama dan pemulihan secara berkala (misalnya setiap tiga bulan).
Semua langkah yang diperlukan untuk failover dan failback harus diperiksa di playbook yang tersedia untuk semua anggota tim dan ditinjau secara berkala.
Ketika menggunakan Elastic Disaster Recovery, layanan akan membantu mengatur dan mengotomatiskan proses failback. Untuk detail selengkapnya, lihat [Melakukan failback](https://docs.aws.amazon.com/drs/latest/userguide/failback-performing-main.html).
**Tingkat upaya untuk Rencana Implementasi:** Tinggi
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [REL09-BP01 Mengidentifikasi dan mencadangkan data yang perlu dicadangkan, atau melakukan reproduksi ulang data dari sumber](rel_backing_up_data_identified_backups_data.md)
+ [REL11-BP04 Mengandalkan bidang data dan bukan bidang kontrol selama pemulihan](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL13-BP01 Menetapkan sasaran pemulihan untuk waktu henti dan kehilangan data](rel_planning_for_recovery_objective_defined_recovery.md)
**Dokumen terkait:**
+ [Blog Arsitektur AWS: Seri Pemulihan Bencana](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Pemulihan Bencana Beban Kerja di AWS: Pemulihan di Cloud (Laporan Resmi AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Opsi pemulihan bencana di cloud](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)
+ [Bangun solusi backend aktif-aktif nirserver multi-wilayah dalam satu jam](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf)
+ [Backend nirserver multi-wilayah — dimuat ulang](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0)
+ [RDS: Mereplikasi Replika Baca di Seluruh Wilayah](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn)
+ [Route 53: Mengonfigurasi failover DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [S3: Replika Lintas-Wilayah](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html)
+ [Apa itu AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Apa itu Pengontrol Pemulihan Aplikasi Amazon?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [HashiCorp Terraform: Memulai - AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started)
+ [Partner APN: partner yang dapat membantu Anda mengatasi pemulihan bencana](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: produk yang dapat digunakan untuk pemulihan bencana](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Video terkait:**
+ [Pemulihan Bencana Beban Kerja di AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
+ [AWS re:Invent 2018: Pola Arsitektur untuk Aplikasi Aktif-Aktif Multi-Wilayah (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Memulai AWS Elastic Disaster Recovery \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as)
# REL13-BP03 Menguji implementasi pemulihan bencana untuk memvalidasi implementasi
Secara rutin uji failover ke situs pemulihan Anda untuk memastikan operasi yang baik dan RTO serta RPO terpenuhi.
**Anti-pola umum:**
+ Tidak pernah melakukan failover di lingkungan produksi.
**Manfaat menerapkan praktik terbaik ini:** Pengujian rencana pemulihan bencana secara rutin akan memverifikasi bahwa rencana tersebut akan berfungsi saat diperlukan, dan tim Anda tahu cara mengeksekusi strategi.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
Pola untuk dihindari adalah mengembangkan jalur pemulihan yang sangat jarang dilakukan. Misalnya, Anda mungkin memiliki penyimpanan data sekunder yang digunakan untuk kueri hanya-baca. Saat Anda menulis ke penyimpanan data dan penyimpanan primer gagal, Anda mungkin ingin melakukan failover ke penyimpanan data sekunder. Jika Anda tidak sering menguji failover ini, Anda mungkin akan mendapati bahwa asumsi Anda tentang kemampuan penyimpanan data sekunder ternyata salah. Kapasitas sekunder, yang selama ini mungkin mencukupi saat terakhir Anda uji, mungkin sudah tidak mampu mentoleransi beban di bawah skenario ini. Pengalaman kami menunjukkan bahwa satu-satunya pemulihan kesalahan yang dapat diterapkan adalah jalur yang sering Anda uji. Inilah alasan memiliki sedikit jalur pemulihan adalah yang terbaik. Anda dapat membuat pola pemulihan dan mengujinya secara rutin. Jika Anda memiliki jalur pemulihan yang kompleks atau kritis, Anda tetap perlu secara rutin melatih kegagalan tersebut dalam lingkungan produksi agar Anda yakin bahwa jalur pemulihan tersebut berfungsi. Pada contoh yang baru saja kita bahas, Anda harus melakukan failover ke penyimpanan siaga secara rutin, terlepas ada tidaknya kebutuhan.
**Langkah-langkah implementasi**
1. Rekayasa beban kerja Anda untuk pemulihan. Uji jalur pemulihan Anda secara rutin. Komputasi yang berorientasi pada pemulihan mengidentifikasi karakteristik dalam sistem yang meningkatkan pemulihan: isolasi dan redundansi, kemampuan di seluruh sistem untuk membatalkan perubahan, kemampuan untuk memantau dan menentukan kondisi, kemampuan untuk menyediakan diagnostik, pemulihan otomatis, desain modular, dan kemampuan untuk memulai ulang. Latih jalur pemulihan untuk memverifikasi bahwa Anda dapat menyelesaikan pemulihan dalam waktu yang ditentukan ke status yang ditentukan. Gunakan runbook selama pemulihan ini untuk mendokumentasikan masalah dan menemukan solusinya sebelum pengujian berikutnya.
1. Untuk beban kerja berbasis Amazon EC2, gunakan [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) untuk menerapkan dan meluncurkan instans latihan untuk strategi DR Anda. AWS Elastic Disaster Recovery menyediakan kemampuan untuk menjalankan latihan secara efisien, yang akan membantu Anda mempersiapkan peristiwa failover. Anda juga dapat sering-sering meluncurkan instans menggunakan Pemulihan Bencana Elastis untuk tujuan pengujian dan latihan tanpa mengarahkan ulang lalu lintas.
## Sumber daya
**Dokumen terkait:**
+ [Partner APN: partner yang dapat membantu Anda mengatasi pemulihan bencana](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Blog Arsitektur : Seri Pemulihan Bencana](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: produk yang dapat digunakan untuk pemulihan bencana](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)
+ [Pemulihan Bencana Beban Kerja di AWS: Pemulihan di Cloud (Laporan Resmi AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [AWS Elastic Disaster Recovery Mempersiapkan Failover](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html)
+ [Proyek komputasi Berkeley/Stanford berorientasi pemulihan](http://roc.cs.berkeley.edu/)
+ [Apa itu Simulator Injeksi Kesalahan AWS?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**Video terkait:**
+ [AWS re:Invent 2018: Pola Arsitektur untuk Aplikasi Aktif-Aktif Multi-Wilayah](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Pencadangan dan pemulihan serta solusi pemulihan bencana dengan AWS](https://youtu.be/7gNXfo5HZN8)
# REL13-BP04 Mengelola penyimpangan konfigurasi di lokasi atau Wilayah Pemulihan Bencana (DR)
Untuk melakukan prosedur pemulihan bencana (DR) yang berhasil, beban kerja Anda harus dapat kembali beroperasi normal dengan cepat tanpa kehilangan fungsionalitas atau data yang relevan setelah lingkungan DR aktif dan siap digunakan. Untuk mencapai tujuan ini, penting untuk menjaga konsistensi infrastruktur, data, dan konfigurasi antara lingkungan DR Anda dan lingkungan primer.
**Hasil yang diinginkan:** Konfigurasi dan data situs pemulihan bencana Anda setara dengan situs primer, sehingga memudahkan pemulihan yang cepat dan menyeluruh saat dibutuhkan.
**Anti-pola umum:**
+ Anda tidak memperbarui lokasi pemulihan ketika ada perubahan pada lokasi primer, sehingga menghasilkan konfigurasi usang yang dapat menghambat upaya pemulihan.
+ Anda tidak mempertimbangkan potensi keterbatasan seperti perbedaan layanan antara lokasi primer dan pemulihan, sehingga dapat menyebabkan kegagalan tak terduga selama failover.
+ Anda mengandalkan proses manual untuk memperbarui dan menyinkronkan lingkungan DR, sehingga meningkatkan risiko kesalahan manusia dan inkonsistensi.
+ Anda gagal mendeteksi penyimpangan konfigurasi, sehingga Anda keliru menganggap bahwa situs DR siap sebelum insiden.
**Manfaat menjalankan praktik terbaik ini:** Konsistensi antara lingkungan DR dan lingkungan primer secara signifikan meningkatkan kemungkinan keberhasilan pemulihan setelah insiden dan mengurangi risiko prosedur pemulihan yang gagal.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
Pendekatan komprehensif untuk manajemen konfigurasi dan kesiapan failover dapat membantu Anda memverifikasi bahwa situs DR secara konsisten diperbarui dan siap untuk mengambil alih jika terjadi kegagalan situs primer.
Untuk mencapai konsistensi antara lingkungan primer dan pemulihan bencana (DR) Anda, validasikan bahwa pipeline pengiriman Anda mendistribusikan aplikasi ke situs primer dan juga situs DR Anda. Terapkan perubahan ke situs DR setelah periode evaluasi yang sesuai (juga dikenal sebagai *deployment bertahap*) untuk mendeteksi masalah di situs primer dan menghentikan deployment sebelum masalah tersebut menyebar. Terapkan pemantauan untuk mendeteksi peyimpangan konfigurasi, dan lacak perubahan serta kepatuhan di berbagai lingkungan Anda. Lakukan remediasi otomatis di situs DR agar tetap konsisten dan siap untuk mengambil alih jika terjadi insiden.
### Langkah-langkah implementasi
1. Validasi bahwa wilayah DR berisi fitur dan layanan AWS yang diperlukan untuk keberhasilan pelaksanaan rencana DR Anda.
1. Gunakan infrastruktur sebagai kode (IaC). Jaga agar templat infrastruktur produksi dan konfigurasi aplikasi Anda tetap akurat, dan terapkan secara teratur ke lingkungan pemulihan bencana Anda. [AWS CloudFormation](https://aws.amazon.com/cloudformation/) dapat mendeteksi penyimpangan antara konfigurasi yang ditentukan dalam templat CloudFormation Anda dan apa yang sebenarnya di-deploy.
1. Konfigurasikan pipeline CI/CD untuk melakukan deployment pembaruan aplikasi dan infrastruktur ke semua lingkungan, termasuk situs primer dan DR. Solusi CI/CD seperti [AWS CodePipeline](https://aws.amazon.com/codepipeline/) dapat mengotomatiskan proses deployment, sehingga mengurangi risiko penyimpangan konfigurasi.
1. Lakukan deployment bertahap antara lingkungan primer dan DR. Pendekatan ini memungkinkan pembaruan di-deploy dan diuji terlebih dahulu di lingkungan primer, sehingga masalah di situs primer dapat diisolasi sebelum menyebar ke situs DR. Pendekatan ini mencegah kecacatan didorong ke situs produksi dan DR pada saat yang bersamaan dan menjaga integritas lingkungan DR.
1. Terus pantau konfigurasi sumber daya di lingkungan primer dan DR. Solusi seperti [AWS Config](https://aws.amazon.com/config/) dapat membantu menegakkan kepatuhan konfigurasi dan mendeteksi penyimpangan konfigurasi, sehingga membantu menjaga konsistensi konfigurasi di seluruh lingkungan.
1. Implementasikan mekanisme peringatan untuk melacak dan memberitahukan setiap penyimpangan konfigurasi atau gangguan atau keterlambatan replikasi data.
1. Otomatiskan perbaikan penyimpangan konfigurasi yang terdeteksi.
1. Jadwalkan audit dan pemeriksaan kepatuhan rutin untuk memverifikasi keselarasan yang berkelanjutan antara konfigurasi primer dan DR. Peninjauan berkala membantu Anda menjaga kepatuhan terhadap aturan yang ditetapkan dan mengidentifikasi ketidaksesuaian apa pun yang perlu ditangani.
1. Periksa ketidakcocokan dalam kapasitas yang disediakan AWS, kuota layanan, batas throttle, serta perbedaan konfigurasi dan versi.
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [REL01-BP01 Mengetahui kuota dan keterbatasan layanan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_aware_quotas_and_constraints.html)
+ [REL01-BP02 Mengelola kuota layanan di seluruh akun dan wilayah](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_limits_considered.html)
+ [REL01-BP04 Memantau dan mengelola kuota](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_monitor_manage_limits.html)
+ [REL13-BP03 Menguji implementasi pemulihan bencana untuk memvalidasi implementasi](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)
**Dokumen terkait:**
+ [Mengatasi Sumber Daya AWS yang Tidak Patuh oleh Aturan AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS CloudFormation: Mendeteksi perubahan konfigurasi tidak terkelola ke tumpukan dan sumber daya](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html)
+ [AWS CloudFormation: Mendeteksi Penyimpangan di Seluruh Tumpukan CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Pemulihan Bencana Beban Kerja di AWS: Pemulihan di Cloud (Laporan Resmi AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Bagaimana cara mengimplementasikan solusi Manajemen Konfigurasi Infrastruktur di AWS?](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/?ref=wellarchitected)
+ [Mengatasi Sumber Daya AWS yang Tidak Patuh oleh Aturan AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
**Video terkait:**
+ [AWS re:Invent 2018: Pola Arsitektur untuk Aplikasi Aktif-Aktif Multi-Wilayah (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
**Contoh terkait:**
+ [Registri CloudFormation](https://aws.amazon.com/blogs/devops/identify-regional-feature-parity-using-the-aws-cloudformation-registry/)
+ [Pemantau Kuota untuk AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [Mengimplementasikan perbaikan otomatis atas penyimpangan untuk AWS CloudFormation menggunakan Amazon CloudWatch dan AWS Lambda](https://aws.amazon.com/blogs/mt/implement-automatic-drift-remediation-for-aws-cloudformation-using-amazon-cloudwatch-and-aws-lambda/)
+ [AWS Blog Arsitektur : Seri Pemulihan Bencana](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: produk yang dapat digunakan untuk pemulihan bencana](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [Melakukan otomatisasi deployment secara aman dan otonom](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
# REL13-BP05 Mengotomatiskan pemulihan
Implementasikan mekanisme pemulihan teruji dan otomatis yang andal, dapat diamati, serta dapat direproduksi untuk mengurangi risiko dan dampak bisnis dari kegagalan.
**Hasil yang diinginkan:** Anda telah mengimplementasikan alur kerja otomatisasi untuk proses pemulihan yang terdokumentasi dengan baik, terstandardisasi, dan teruji secara menyeluruh. Otomatisasi pemulihan Anda secara otomatis memperbaiki masalah kecil yang menimbulkan risiko rendah kehilangan atau ketidaktersediaan data. Anda dapat dengan cepat menginvokasi proses pemulihan untuk insiden serius, mengamati perilaku perbaikan saat proses tersebut beroperasi, dan menghentikan proses jika Anda mengamati situasi berbahaya atau kegagalan.
**Anti-pola umum:**
+ Anda bergantung pada komponen atau mekanisme yang berada dalam keadaan gagal atau kinerjanya menurun sebagai bagian dari rencana pemulihan Anda.
+ Proses pemulihan Anda memerlukan intervensi manual, seperti akses konsol (juga dikenal sebagai *click ops*).
+ Anda secara otomatis memulai prosedur pemulihan dalam situasi yang menimbulkan risiko tinggi kehilangan atau ketidaktersediaan data.
+ Anda gagal menyertakan mekanisme untuk membatalkan prosedur pemulihan (seperti *kabel Andon* atau *tombol darurat besar warna merah*) yang tidak berfungsi atau yang menimbulkan risiko tambahan.
**Manfaat menjalankan praktik terbaik ini:**
+ Peningkatan keandalan, prediktabilitas, dan konsistensi operasi pemulihan.
+ Kemampuan untuk memenuhi sasaran pemulihan yang lebih ketat, termasuk Sasaran Waktu Pemulihan (RTO) dan Sasaran Titik Pemulihan (RPO).
+ Mengurangi kemungkinan pemulihan gagal selama suatu insiden.
+ Mengurangi risiko kegagalan yang terkait dengan proses pemulihan manual yang rentan terhadap kesalahan manusia.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
Untuk menerapkan pemulihan otomatis, Anda memerlukan pendekatan komprehensif yang menggunakan layanan dan praktik terbaik AWS. Untuk memulai, identifikasi komponen penting dan titik kegagalan potensial dalam beban kerja Anda. Kembangkan proses otomatis yang dapat memulihkan beban kerja dan data Anda dari kegagalan tanpa campur tangan manusia.
Kembangkan otomatisasi pemulihan Anda menggunakan prinsip infrastruktur sebagai kode (IaC). Hal ini membuat lingkungan pemulihan Anda konsisten dengan lingkungan sumber dan memungkinkan kontrol versi untuk proses pemulihan Anda. Untuk mengorkestrasi alur kerja pemulihan yang kompleks, pertimbangkan solusi seperti [Otomatisasi AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) atau [AWS Step Functions](https://aws.amazon.com/step-functions/).
Otomatisasi proses pemulihan memberikan manfaat yang signifikan dan dapat membantu Anda lebih mudah mencapai Sasaran Waktu Pemulihan (RTO) dan Sasaran Titik Pemulihan (RPO). Namun, otomatisasi tersebut dapat mengalami situasi tak terduga yang dapat membuatnya gagal atau menciptakan risiko baru seperti waktu henti tambahan dan kehilangan data. Untuk mengurangi risiko ini, berikan kemampuan yang dapat dengan cepat menghentikan otomatisasi pemulihan yang sedang berlangsung. Setelah dihentikan, Anda dapat menyelidiki dan mengambil langkah-langkah korektif.
Untuk beban kerja yang didukung, pertimbangkan solusi seperti AWS Elastic Disaster Recovery (AWS DRS) untuk menyediakan failover otomatis. AWS DRS secara terus-menerus mereplikasi mesin Anda (termasuk sistem operasi, konfigurasi status sistem, basis data, aplikasi, dan file) ke dalam area staging di akun Akun AWS target Anda dan Wilayah yang dipilih. Jika terjadi insiden, AWS DRS mengotomatiskan konversi server replika Anda menjadi beban kerja yang disediakan sepenuhnya di Wilayah pemulihan Anda di AWS.
Pemulihan otomatis adalah proses yang perlu dipelihara dan ditingkatkan secara berkelanjutan. Terus uji dan sempurnakan prosedur pemulihan Anda berdasarkan pelajaran yang dipetik, dan tetap ikuti informasi terbaru tentang fitur dan layanan AWS baru yang dapat meningkatkan kemampuan pemulihan Anda.
### Langkah-langkah implementasi
1. **Rencanakan pemulihan otomatis**
1. Lakukan tinjauan menyeluruh atas arsitektur beban kerja, komponen, dan dependensi Anda untuk mengidentifikasi dan merencanakan mekanisme pemulihan otomatis. Kategorikan dependensi beban kerja Anda ke dalam dependensi *mutlak* dan *relatif*. Dependensi mutlak adalah dependensi yang tanpanya beban kerja tidak dapat beroperasi dan tidak ada pengganti yang dapat disediakan. Dependensi relatif adalah dependensi yang biasanya digunakan oleh beban kerja tetapi dapat diganti dengan sistem atau proses pengganti sementara atau dapat ditangani dengan [penurunan terkendali](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation).
1. Tetapkan proses untuk mengidentifikasi dan memulihkan data yang hilang atau rusak.
1. Tentukan langkah-langkah untuk mengonfirmasi kondisi stabil dan pulih setelah tindakan pemulihan selesai.
1. Pertimbangkan tindakan apa pun yang diperlukan untuk membuat sistem yang pulih siap untuk layanan penuh, seperti pra-pemanasan dan pengisian cache.
1. Pikirkan berbagai masalah yang dapat muncul selama proses pemulihan dan cara mendeteksi dan memperbaikinya.
1. Pertimbangkan skenario ketika situs primer dan bidang kontrolnya tidak dapat diakses. Verifikasi bahwa tindakan pemulihan dapat dilakukan secara independen tanpa bergantung pada situs primer. Pertimbangkan solusi seperti [Pengontrol Pemulihan Aplikasi (ARC) Amazon](https://aws.amazon.com/application-recovery-controller/) untuk mengalihkan lalu lintas tanpa perlu mengubah catatan DNS secara manual.
1. **Kembangkan proses pemulihan otomatis**
1. Terapkan deteksi kesalahan otomatis dan mekanisme failover untuk pemulihan tanpa intervensi manual. Buat dasbor misalnya dengan [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) untuk melaporkan progres dan kondisi prosedur pemulihan otomatis. Sertakan prosedur untuk memvalidasi pemulihan yang berhasil. Sediakan mekanisme untuk membatalkan pemulihan yang sedang berlangsung.
1. Buat [playbook](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency) sebagai proses alternatif untuk kesalahan yang tidak dapat dipulihkan secara otomatis, dan pastikan keselarasannya dengan [rencana pemulihan bencana](https://aws.amazon.com/disaster-recovery/faqs/#Core_concepts) Anda.
1. Uji proses pemulihan sebagaimana dibahas di [REL13-BP03](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_dr_tested.html).
1. **Bersiap untuk pemulihan**
1. Evaluasi keadaan situs pemulihan Anda dan lakukan deployment komponen penting ke situs tersebut sebelumnya. Untuk detail lebih lanjut, lihat [REL13-BP04](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_config_drift.html).
1. Tentukan peran, tanggung jawab, dan proses pengambilan keputusan yang jelas untuk operasi pemulihan, yang melibatkan pemangku kepentingan dan tim yang relevan di keseluruhan organisasi.
1. Tentukan kondisi untuk memulai proses pemulihan Anda.
1. Buat rencana untuk mengembalikan proses pemulihan dan kembali ke situs primer Anda jika diperlukan atau setelah dianggap aman.
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [REL07-BP01 Menggunakan otomatisasi ketika mendapatkan atau menskalakan sumber daya](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_adapt_to_changes_autoscale_adapt.html)
+ [REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_withstand_component_failures_monitoring_health.html)
+ [REL13-BP02 Menggunakan strategi pemulihan untuk memenuhi sasaran pemulihan](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)
+ [REL13-BP03 Menguji implementasi pemulihan bencana untuk memvalidasi implementasi](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_dr_tested.html)
+ [REL13-BP04 Mengelola penyimpangan konfigurasi di lokasi atau Wilayah Pemulihan Bencana (DR)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_config_drift.html)
**Dokumen terkait:**
+ [Blog Arsitektur AWS: Seri Pemulihan Bencana](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Pemulihan Bencana Beban Kerja di AWS: Pemulihan di Cloud (Laporan Resmi AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Mengorkestrasi Otomatisasi Pemulihan Bencana menggunakan ARC Amazon Route 53 dan AWS Step Functions](https://aws.amazon.com/blogs/networking-and-content-delivery/orchestrate-disaster-recovery-automation-using-amazon-route-53-arc-and-aws-step-functions/)
+ [Membuat runbook Otomatisasi AWS Systems Manager menggunakan AWS CDK](https://aws.amazon.com/blogs/mtbuild-aws-systems-manager-automation-runbooks-using-aws-cdk/)
+ [AWS Marketplace: Produk yang Dapat Digunakan untuk Pemulihan Bencana](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)
+ [Menggunakan Elastic Disaster Recovery untuk Failover dan Failback](https://docs.aws.amazon.com/drs/latest/userguide/failback.html)
+ [Sumber Daya AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/resources/)
+ [Partner APN: Partner yang Dapat Membantu Anda Melakukan Pemulihan Bencana](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
**Video terkait:**
+ [AWS re:Invent 2018: Pola Arsitektur untuk Aplikasi Aktif-Aktif Multi-Wilayah (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2022: AWS On Air ft. AWS Failback untuk AWS Elastic Disaster Recovery](https://youtu.be/Ok-vpV8b1Hs)