Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Opsi pemulihan bencana di cloud

Strategi pemulihan bencana yang tersedia untuk Anda dalam AWS dapat dikategorikan secara luas menjadi empat pendekatan, mulai dari biaya rendah dan kompleksitas rendah dalam membuat cadangan hingga strategi yang lebih kompleks menggunakan beberapa Wilayah aktif. Strategi aktif/pasif menggunakan situs aktif (seperti Wilayah AWS) untuk menampung beban kerja dan melayani lalu lintas. Situs pasif (seperti Wilayah AWS yang berbeda) digunakan untuk pemulihan. Situs pasif tidak aktif melayani lalu lintas sampai peristiwa failover dipicu.

Sangat penting untuk secara teratur menilai dan menguji strategi pemulihan bencana Anda sehingga Anda memiliki kepercayaan diri dalam menerapkannya, jika diperlukan. Gunakan AWS Resilience Hub untuk terus memvalidasi dan melacak ketahanan AWS beban kerja Anda, termasuk apakah Anda mungkin memenuhi target RTO dan RPO Anda.

Gambar 6 - Strategi pemulihan bencana

Untuk peristiwa bencana berdasarkan gangguan atau hilangnya satu pusat data fisik untuk beban kerja yang dirancang dengan baik dan sangat tersedia, Anda mungkin hanya memerlukan pendekatan cadangan dan pemulihan untuk pemulihan bencana. Jika definisi Anda tentang bencana melampaui gangguan atau hilangnya pusat data fisik ke Wilayah atau jika Anda tunduk pada persyaratan peraturan yang memerlukannya, maka Anda harus mempertimbangkan Pilot Light, Warm Standby, atau Multi-Site Active/Active.

Saat memilih strategi Anda, dan sumber daya AWS untuk mengimplementasikannya, ingatlah bahwa dalam AWS, kami biasanya membagi layanan ke dalam bidang data dan bidang kontrol. Bidang data bertanggung jawab untuk menghadirkan layanan waktu nyata sedangkan bidang kontrol digunakan untuk mengonfigurasi lingkungan. Untuk ketahanan maksimum, Anda harus menggunakan hanya operasi pesawat data sebagai bagian dari operasi failover Anda. Ini karena pesawat data biasanya memiliki tujuan desain ketersediaan yang lebih tinggi daripada bidang kontrol.

Pencadangan dan pemulihan

Backup and restore adalah pendekatan yang cocok untuk mengurangi kehilangan data atau korupsi. Pendekatan ini juga dapat digunakan untuk mengurangi bencana regional dengan mereplikasi data ke Wilayah AWS lainnya, atau untuk mengurangi kurangnya redundansi untuk beban kerja yang diterapkan ke satu Availability Zone. Selain data, Anda harus menerapkan ulang infrastruktur, konfigurasi, dan kode aplikasi di Wilayah pemulihan. Agar infrastruktur dapat digunakan kembali dengan cepat tanpa kesalahan, Anda harus selalu menerapkan menggunakan infrastruktur sebagai kode (IAc) menggunakan layanan seperti atau. AWS CloudFormationAWS Cloud Development Kit (AWS CDK) Tanpa IAc, mungkin rumit untuk memulihkan beban kerja di Wilayah pemulihan, yang akan menyebabkan peningkatan waktu pemulihan dan mungkin melebihi RTO Anda. Selain data pengguna, pastikan juga mencadangkan kode dan konfigurasi, termasuk Amazon Machine Images (AMIs) yang Anda gunakan untuk membuat EC2 instance Amazon. Anda dapat menggunakan AWS CodePipelineuntuk mengotomatiskan redeployment kode aplikasi dan konfigurasi.

Gambar 7 - Backup dan Restore Arsitektur

Layanan AWS

Data beban kerja Anda akan memerlukan strategi cadangan yang berjalan secara berkala atau berkelanjutan. Seberapa sering Anda menjalankan cadangan Anda akan menentukan titik pemulihan yang dapat dicapai (yang harus selaras untuk memenuhi RPO Anda). Cadangan juga harus menawarkan cara untuk mengembalikannya ke titik waktu di mana ia diambil. Backup dengan point-in-time pemulihan tersedia melalui layanan dan sumber daya berikut:

Untuk Amazon Simple Storage Service (Amazon S3), Anda dapat menggunakan Amazon S3 Cross-Region Replication (CRR) untuk menyalin objek secara asinkron ke bucket S3 di wilayah DR secara terus menerus, sambil memberikan versi untuk objek yang disimpan sehingga Anda dapat memilih titik restorasi. Replikasi data yang berkelanjutan memiliki keuntungan menjadi waktu terpendek (mendekati nol) untuk mencadangkan data Anda, tetapi mungkin tidak melindungi terhadap peristiwa bencana seperti korupsi data atau serangan berbahaya (seperti penghapusan data yang tidak sah) serta pencadangan. point-in-time Replikasi berkelanjutan tercakup dalam bagian AWS Services for Pilot Light.

AWS Backupmenyediakan lokasi terpusat untuk mengonfigurasi, menjadwalkan, dan memantau kemampuan pencadangan AWS untuk layanan dan sumber daya berikut:

AWS Backup mendukung penyalinan cadangan di seluruh Wilayah, seperti ke Wilayah pemulihan bencana.

Sebagai strategi pemulihan bencana tambahan untuk data Amazon S3 Anda, aktifkan versi objek S3. Pembuatan versi objek melindungi data Anda di S3 dari konsekuensi tindakan penghapusan atau modifikasi dengan mempertahankan versi asli sebelum tindakan. Pembuatan versi objek dapat menjadi mitigasi yang berguna untuk bencana jenis kesalahan manusia. Jika Anda menggunakan replikasi S3 untuk mencadangkan data ke wilayah DR Anda, maka, secara default, saat objek dihapus di bucket sumber, Amazon S3 hanya menambahkan penanda hapus di bucket sumber. Pendekatan ini melindungi data di Wilayah DR dari penghapusan berbahaya di Wilayah sumber.

Selain data, Anda juga harus mencadangkan konfigurasi dan infrastruktur yang diperlukan untuk memindahkan beban kerja Anda dan memenuhi Tujuan Waktu Pemulihan (RTO) Anda. AWS CloudFormationmenyediakan Infrastructure as Code (IAc), dan memungkinkan Anda menentukan semua sumber daya AWS dalam beban kerja Anda sehingga Anda dapat menerapkan dan menerapkan ulang dengan andal ke beberapa akun AWS dan Wilayah AWS. Anda dapat mencadangkan EC2 instans Amazon yang digunakan oleh beban kerja Anda sebagai Amazon Machine Images ()AMIs. AMI dibuat dari snapshot volume root instans Anda dan volume EBS lainnya yang dilampirkan ke instans Anda. Anda dapat menggunakan AMI ini untuk meluncurkan versi EC2 instans yang dipulihkan. AMI dapat disalin di dalam atau di seluruh Wilayah. Atau, Anda dapat menggunakannya AWS Backupuntuk menyalin cadangan di seluruh akun dan ke Wilayah AWS lainnya. Kemampuan pencadangan lintas akun membantu melindungi dari peristiwa bencana yang mencakup ancaman orang dalam atau kompromi akun. AWS Backup juga menambahkan kemampuan tambahan untuk EC2 pencadangan — selain volume EBS individual instans, AWS Backup juga menyimpan dan melacak metadata berikut: jenis instans, cloud pribadi virtual (VPC) yang dikonfigurasi, grup keamanan, peran IAM, konfigurasi pemantauan, dan tag. Namun, metadata tambahan ini hanya digunakan saat memulihkan EC2 cadangan ke Wilayah AWS yang sama.

Setiap data yang disimpan di Wilayah pemulihan bencana sebagai cadangan harus dipulihkan pada saat failover. AWS Backup menawarkan kemampuan pemulihan, tetapi saat ini tidak mengaktifkan pemulihan terjadwal atau otomatis. Anda dapat menerapkan pemulihan otomatis ke wilayah DR menggunakan AWS SDK APIs untuk AWS Backup dipanggil. Anda dapat mengatur ini sebagai pekerjaan berulang secara teratur atau memicu pemulihan setiap kali cadangan selesai. Gambar berikut menunjukkan contoh pemulihan otomatis menggunakan Amazon Simple Notification Service (Amazon AWS LambdaSNS) dan. Menerapkan pemulihan data berkala terjadwal adalah ide yang bagus karena pemulihan data dari cadangan adalah operasi bidang kontrol. Jika operasi ini tidak tersedia selama bencana, Anda masih akan memiliki penyimpanan data yang dapat dioperasikan yang dibuat dari cadangan baru-baru ini.

Gambar 8 - Memulihkan dan menguji cadangan

Pilot light

Dengan pendekatan pilot light, Anda mereplikasi data Anda dari satu Wilayah ke Wilayah lain dan menyediakan salinan infrastruktur beban kerja inti Anda. Sumber daya yang diperlukan untuk mendukung replikasi dan pencadangan data, misalnya basis data dan penyimpanan objek, selalu aktif. Elemen lain, seperti server aplikasi, dimuat dengan kode aplikasi dan konfigurasi, tetapi “dimatikan” dan hanya digunakan selama pengujian atau ketika failover pemulihan bencana dipanggil. Di cloud, Anda memiliki fleksibilitas untuk mengurangi sumber daya saat Anda tidak membutuhkannya, dan menyediakannya saat Anda melakukannya. Praktik terbaik untuk “dimatikan” adalah tidak menyebarkan sumber daya, dan kemudian membuat konfigurasi dan kemampuan untuk menerapkannya (“aktifkan”) bila diperlukan. Berbeda dengan pendekatan pencadangan dan pemulihan, infrastruktur inti Anda selalu tersedia dan Anda selalu memiliki opsi untuk menyediakan lingkungan produksi skala penuh dengan mengaktifkan dan meningkatkan skala server aplikasi Anda.

Gambar 9 - Arsitektur cahaya pilot

Pendekatan pilot light meminimalkan biaya pemulihan bencana yang sedang berlangsung dengan meminimalkan sumber daya aktif, dan menyederhanakan pemulihan pada saat bencana karena persyaratan infrastruktur inti semuanya ada. Opsi pemulihan ini mengharuskan Anda untuk mengubah pendekatan penerapan Anda. Anda perlu membuat perubahan infrastruktur inti ke setiap Wilayah dan menerapkan perubahan beban kerja (konfigurasi, kode) secara bersamaan ke setiap Wilayah. Langkah ini dapat disederhanakan dengan mengotomatiskan penerapan Anda dan menggunakan infrastruktur sebagai kode (IAc) untuk menyebarkan infrastruktur di beberapa akun dan Wilayah (penyebaran infrastruktur penuh ke Wilayah utama dan penyebaran infrastruktur yang diperkecil/dimatikan ke wilayah DR). Disarankan Anda menggunakan akun yang berbeda per Wilayah untuk menyediakan isolasi sumber daya dan keamanan tingkat tertinggi (dalam hal kredensi yang dikompromikan juga merupakan bagian dari rencana pemulihan bencana Anda).

Dengan pendekatan ini, Anda juga harus mengurangi bencana data. Replikasi data berkelanjutan melindungi Anda dari beberapa jenis bencana, tetapi mungkin tidak melindungi Anda dari korupsi atau penghancuran data kecuali strategi Anda juga mencakup versi data yang disimpan atau opsi untuk pemulihan. point-in-time Anda dapat mencadangkan data yang direplikasi di Wilayah bencana untuk membuat point-in-time cadangan di Wilayah yang sama.

Layanan AWS

Selain menggunakan layanan AWS yang tercakup dalam bagian Backup dan Restore untuk membuat point-in-time cadangan, pertimbangkan juga layanan berikut untuk strategi pilot light Anda.

Untuk pilot light, replikasi data berkelanjutan ke database langsung dan penyimpanan data di wilayah DR adalah pendekatan terbaik untuk RPO rendah (bila digunakan selain point-in-time cadangan yang dibahas sebelumnya). AWS menyediakan replikasi data asinkron yang berkelanjutan, lintas wilayah, dan asinkron untuk data menggunakan layanan dan sumber daya berikut:

Dengan replikasi berkelanjutan, versi data Anda segera tersedia di Wilayah DR Anda. Waktu replikasi aktual dapat dipantau menggunakan fitur layanan seperti S3 Replication Time Control (S3 RTC) untuk objek S3 dan fitur manajemen database global Amazon Aurora.

Ketika gagal menjalankan beban kerja baca/tulis Anda dari Wilayah pemulihan bencana, Anda harus mempromosikan replika baca RDS untuk menjadi contoh utama. Untuk instans DB selain Aurora, prosesnya membutuhkan beberapa menit untuk diselesaikan dan reboot adalah bagian dari proses. Untuk Replikasi Lintas Wilayah (CRR) dan failover dengan RDS, menggunakan database global Amazon Aurora memberikan beberapa keuntungan. Database global menggunakan infrastruktur khusus yang membuat database Anda sepenuhnya tersedia untuk melayani aplikasi Anda, dan dapat mereplikasi ke Wilayah sekunder dengan latensi tipikal kurang dari satu detik (dan dalam Wilayah AWS kurang dari 100 milidetik). Dengan database global Amazon Aurora, jika Wilayah utama Anda mengalami penurunan kinerja atau pemadaman, Anda dapat mempromosikan salah satu wilayah sekunder untuk mengambil tanggung jawab baca/tulis dalam waktu kurang dari satu menit bahkan jika terjadi pemadaman regional total. Anda juga dapat mengonfigurasi Aurora untuk memantau jeda waktu RPO dari semua cluster sekunder untuk memastikan bahwa setidaknya satu cluster sekunder tetap berada dalam jendela RPO target Anda.

Versi infrastruktur beban kerja inti Anda yang diperkecil dengan sumber daya yang lebih sedikit atau lebih kecil harus diterapkan di Wilayah DR Anda. Dengan menggunakan AWS CloudFormation, Anda dapat menentukan infrastruktur dan menerapkannya secara konsisten di seluruh akun AWS dan di seluruh Wilayah AWS. AWS CloudFormation menggunakan parameter semu yang telah ditentukan sebelumnya untuk mengidentifikasi akun AWS dan Wilayah AWS tempat akun tersebut digunakan. Oleh karena itu, Anda dapat menerapkan logika kondisi di CloudFormation template Anda untuk menerapkan hanya versi infrastruktur yang diperkecil di Wilayah DR. EC2 Misalnya penerapan, Amazon Machine Image (AMI) menyediakan informasi seperti konfigurasi perangkat keras dan perangkat lunak yang diinstal. Anda dapat mengimplementasikan pipeline Image Builder yang membuat kebutuhan AMIs Anda dan menyalinnya ke Wilayah utama dan cadangan Anda. Ini membantu memastikan bahwa emas ini AMIs memiliki semua yang Anda butuhkan untuk menyebarkan kembali atau meningkatkan beban kerja Anda di wilayah baru, jika terjadi peristiwa bencana. EC2 Instans Amazon diterapkan dalam konfigurasi yang diperkecil (lebih sedikit instans daripada di Wilayah utama Anda). Untuk meningkatkan skala infrastruktur guna mendukung lalu lintas produksi, lihat Amazon Auto EC2 Scaling di bagian Warm Standby.

Untuk konfigurasi aktif/pasif seperti lampu pilot, semua lalu lintas awalnya pergi ke Wilayah utama dan beralih ke Wilayah pemulihan bencana jika Wilayah utama tidak lagi tersedia. Operasi failover ini dapat dimulai secara otomatis dan manual. Failover yang dimulai secara otomatis berdasarkan pemeriksaan kesehatan atau alarm harus digunakan dengan hati-hati. Bahkan menggunakan praktik terbaik yang dibahas di sini, waktu pemulihan dan titik pemulihan akan lebih besar dari nol, menimbulkan beberapa kehilangan ketersediaan dan data. Jika Anda gagal ketika Anda tidak perlu (alarm palsu), maka Anda mengalami kerugian tersebut. 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 AWS layanan.

Salah satu opsinya adalah menggunakan Amazon Route 53. Menggunakan Amazon Route 53, Anda dapat mengaitkan beberapa titik akhir IP di satu atau beberapa Wilayah AWS dengan nama domain Route 53. Kemudian, Anda dapat merutekan lalu lintas ke titik akhir yang sesuai di bawah nama domain tersebut. Pada failover Anda perlu mengalihkan lalu lintas ke titik akhir pemulihan, dan menjauh dari titik akhir utama. Pemeriksaan kesehatan Amazon Route 53 memantau titik akhir ini. Dengan menggunakan pemeriksaan kesehatan ini, Anda dapat mengonfigurasi failover DNS yang dimulai secara otomatis untuk memastikan lalu lintas dikirim hanya ke titik akhir yang sehat, yang merupakan operasi yang sangat andal yang dilakukan pada bidang data. Untuk menerapkan ini menggunakan failover yang dimulai secara manual, Anda dapat menggunakan Amazon Application Recovery Controller (ARC). Dengan ARC, Anda dapat membuat pemeriksaan kesehatan Route 53 yang tidak benar-benar memeriksa kesehatan, tetapi bertindak sebagai sakelar on/off yang memiliki kendali penuh. Menggunakan AWS CLI atau AWS SDK, Anda dapat membuat skrip failover menggunakan API bidang data yang sangat tersedia ini. Skrip Anda mengaktifkan sakelar ini (pemeriksaan kesehatan Route 53) yang memberi tahu Route 53 untuk mengirim lalu lintas ke Wilayah pemulihan alih-alih Wilayah utama. Pilihan lain untuk failover yang dimulai secara manual yang telah digunakan beberapa orang adalah dengan menggunakan kebijakan perutean tertimbang dan mengubah bobot Wilayah primer dan pemulihan sehingga semua lalu lintas masuk ke Wilayah pemulihan. Namun, ketahuilah bahwa ini adalah operasi bidang kontrol dan oleh karena itu tidak sekuat pendekatan bidang data menggunakan Amazon Application Recovery Controller (ARC).

Pilihan lain adalah menggunakan AWS Global Accelerator. Dengan menggunakan AnyCast IP, Anda dapat mengaitkan beberapa titik akhir di satu atau beberapa Wilayah AWS dengan alamat atau alamat IP publik statis yang sama. AWS Global Accelerator kemudian mengarahkan lalu lintas ke titik akhir yang sesuai yang terkait dengan alamat itu. Pemeriksaan kesehatan Global Accelerator memantau titik akhir. Dengan menggunakan pemeriksaan kesehatan ini, AWS Global Accelerator memeriksa kesehatan aplikasi Anda dan mengarahkan lalu lintas pengguna secara otomatis ke titik akhir aplikasi yang sehat. Untuk failover yang dimulai secara manual, Anda dapat menyesuaikan titik akhir mana yang menerima lalu lintas menggunakan tombol lalu lintas, tetapi perhatikan bahwa ini adalah operasi pesawat kontrol. Global Accelerator menawarkan latensi yang lebih rendah ke titik akhir aplikasi karena menggunakan jaringan AWS edge yang luas untuk menempatkan lalu lintas di tulang punggung jaringan AWS sesegera mungkin. Global Accelerator juga menghindari masalah caching yang dapat terjadi dengan sistem DNS (seperti Route 53).

Amazon CloudFront menawarkan failover asal, di mana jika permintaan yang diberikan ke titik akhir utama gagal, CloudFront merutekan permintaan ke titik akhir sekunder. Tidak seperti operasi failover yang dijelaskan sebelumnya, semua permintaan berikutnya masih masuk ke titik akhir utama, dan failover dilakukan per setiap permintaan.

AWS Pemulihan Bencana Elastis

AWS Elastic Disaster Recovery (DRS) terus mereplikasi aplikasi yang dihosting server dan database yang dihosting server dari sumber mana pun menjadi AWS menggunakan replikasi tingkat blok dari server yang mendasarinya. Elastic Disaster Recovery memungkinkan Anda menggunakan Wilayah AWS Cloud sebagai target pemulihan bencana untuk beban kerja yang dihosting di tempat atau di penyedia cloud lain, dan lingkungannya. Ini juga dapat digunakan untuk pemulihan bencana beban kerja yang AWS dihosting jika hanya terdiri dari aplikasi dan database yang dihosting EC2 (yaitu, bukan RDS). Elastic Disaster Recovery menggunakan strategi Pilot Light, memelihara salinan data dan sumber daya “dimatikan” di Amazon Virtual Private Cloud (Amazon VPC) yang digunakan sebagai area pementasan. Saat peristiwa failover dipicu, sumber daya bertahap digunakan untuk secara otomatis membuat penerapan kapasitas penuh di VPC Amazon target yang digunakan sebagai lokasi pemulihan.

Gambar 10 - Arsitektur Pemulihan Bencana AWS Elastis

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. Pendekatan ini juga memungkinkan Anda untuk lebih mudah melakukan pengujian atau menerapkan pengujian berkelanjutan untuk meningkatkan kepercayaan pada kemampuan Anda untuk pulih dari bencana.

Gambar 11 - Arsitektur siaga hangat

Catatan: Perbedaan antara lampu pilot dan siaga hangat terkadang sulit dipahami. Keduanya mencakup lingkungan di Wilayah DR Anda dengan salinan aset Wilayah utama Anda. Perbedaannya adalah bahwa lampu pilot tidak dapat memproses permintaan tanpa tindakan tambahan yang diambil terlebih dahulu, sedangkan siaga hangat dapat menangani lalu lintas (pada tingkat kapasitas yang dikurangi) dengan segera. Pendekatan pilot light mengharuskan Anda untuk “menghidupkan” server, mungkin menerapkan infrastruktur tambahan (non-inti), dan meningkatkan skala, sedangkan siaga hangat hanya mengharuskan Anda untuk meningkatkan (semuanya sudah digunakan dan berjalan). Gunakan kebutuhan RTO dan RPO Anda untuk membantu Anda memilih di antara pendekatan ini.

Layanan AWS

Semua layanan AWS yang tercakup dalam pencadangan dan pemulihan dan lampu pilot juga digunakan dalam keadaan siaga hangat untuk pencadangan data, replikasi data, perutean lalu lintas aktif/pasif, dan penyebaran infrastruktur termasuk instance. EC2

EC2 Auto Scaling Amazon digunakan untuk menskalakan sumber daya termasuk EC2 instans Amazon, tugas Amazon ECS, throughput Amazon DynamoDB, dan replika Amazon Aurora dalam Wilayah AWS. Amazon EC2 Auto Scaling menskalakan penyebaran EC2 instans di seluruh Availability Zone dalam Wilayah AWS, memberikan ketahanan dalam Wilayah tersebut. Gunakan Auto Scaling untuk meningkatkan skala Wilayah DR Anda ke kemampuan produksi penuh, sebagai bagian dari strategi lampu pilot atau siaga hangat. Misalnya, untuk EC2, tingkatkan pengaturan kapasitas yang diinginkan pada grup Auto Scaling. Anda dapat menyesuaikan pengaturan ini secara manual melalui AWS Management Console, secara otomatis melalui AWS SDK, atau dengan menerapkan ulang AWS CloudFormation template Anda menggunakan nilai kapasitas baru yang diinginkan. Anda dapat menggunakan AWS CloudFormation parameter untuk membuat redeploying CloudFormation template lebih mudah. Pastikan bahwa kuota layanan di Wilayah DR Anda ditetapkan cukup tinggi sehingga tidak membatasi Anda dari peningkatan kapasitas produksi.

Karena Auto Scaling adalah aktivitas bidang kontrol, mengambil ketergantungan padanya akan menurunkan ketahanan strategi pemulihan Anda secara keseluruhan. Ini adalah trade-off. Anda dapat memilih untuk menyediakan kapasitas yang cukup sehingga Wilayah pemulihan dapat menangani beban produksi penuh seperti yang digunakan. Konfigurasi stabil statis ini disebut hot standby (lihat bagian selanjutnya). Atau Anda dapat memilih untuk menyediakan lebih sedikit sumber daya yang biayanya lebih murah, tetapi bergantung pada Auto Scaling. Beberapa implementasi DR akan menggunakan sumber daya yang cukup untuk menangani lalu lintas awal, memastikan RTO rendah, dan kemudian mengandalkan Auto Scaling untuk meningkatkan lalu lintas berikutnya.

Multi-situs aktif/aktif

Anda dapat menjalankan beban kerja Anda secara bersamaan di beberapa Wilayah sebagai bagian dari strategi aktif/aktif aktif atau siaga aktif multi-situs aktif/pasif. Multi-situsactive/active serves traffic from all regions to which it is deployed, whereas hot standby serves traffic only from a single region, and the other Region(s) are only used for disaster recovery. With a multi-site active/active approach, users are able to access your workload in any of the Regions in which it is deployed. This approach is the most complex and costly approach to disaster recovery, but it can reduce your recovery time to near zero for most disasters with the correct technology choices and implementation (however data corruption may need to rely on backups, which usually results in a non-zero recovery point). Hot standby uses an active/passive configuration where users are only directed to a single region and DR regions do not take traffic. Most customers find that if they are going to stand up a full environment in the second Region, it makes sense to use it active/active. Atau, jika Anda tidak ingin menggunakan kedua Wilayah untuk menangani lalu lintas pengguna, maka Warm Standby menawarkan pendekatan yang lebih ekonomis dan operasional kurang kompleks.

Gambar 12 - Arsitektur aktif/aktif multi-situs (ubah satu jalur Aktif menjadi Tidak Aktif untuk siaga panas)

Dengan pendekatan multi-situs active/active, because the workload is running in more than one Region, there is no such thing as failover in this scenario. Disaster recovery testing in this case would focus on how the workload reacts to loss of a Region: Is traffic routed away from the failed Region? Can the other Region(s) handle all the traffic? Testing for a data disaster is also required. Backup and recovery are still required and should be tested regularly. It should also be noted that recovery times for a data disaster involving data corruption, deletion, or obfuscation will always be greater than zero and the recovery point will always be at some point before the disaster was discovered. If the additional complexity and cost of a multi-site active/active (atau siaga panas) diperlukan untuk mempertahankan waktu pemulihan mendekati nol, maka upaya tambahan harus dilakukan untuk menjaga keamanan dan untuk mencegah kesalahan manusia untuk mengurangi bencana manusia.

Layanan AWS

Semua layanan AWS yang tercakup dalam pencadangan dan pemulihan, lampu pilot, dan siaga hangat juga digunakan di sini untuk pencadangan point-in-time data, replikasi data, perutean lalu lintas aktif/aktif, serta penyebaran dan penskalaan infrastruktur termasuk instance. EC2

Untuk skenario aktif/pasif yang dibahas sebelumnya (Pilot Light dan Warm Standby), Amazon Route 53 dan AWS Global Accelerator dapat digunakan untuk rute lalu lintas jaringan ke wilayah aktif. Untuk strategi aktif/aktif di sini, kedua layanan ini juga memungkinkan definisi kebijakan yang menentukan pengguna mana yang pergi ke titik akhir regional aktif mana. Dengan AWS Global Accelerator Anda mengatur panggilan lalu lintas untuk mengontrol persentase lalu lintas yang diarahkan ke setiap titik akhir aplikasi. Amazon Route 53 mendukung pendekatan persentase ini, dan juga beberapa kebijakan lain yang tersedia termasuk kebijakan berbasis geoproximity dan latensi. Global Accelerator secara otomatis memanfaatkan jaringan ekstensif server AWS edge, untuk mengarahkan lalu lintas ke backbone jaringan AWS sesegera mungkin, sehingga latensi permintaan lebih rendah.

Replikasi data asinkron dengan strategi ini memungkinkan RPO mendekati nol. Layanan AWS seperti database global Amazon Aurora menggunakan infrastruktur khusus yang membuat database Anda sepenuhnya tersedia untuk melayani aplikasi Anda, dan dapat mereplikasi hingga lima Wilayah sekunder dengan latensi tipikal kurang dari satu detik. Dengan active/passive strategies, writes occur only to the primary Region. The difference with active/active merancang bagaimana konsistensi data dengan penulisan ke setiap Wilayah aktif ditangani. Merupakan hal yang umum untuk merancang bacaan pengguna untuk dilayani dari Wilayah terdekat dengan mereka, yang dikenal sebagai baca lokal. Dengan menulis, Anda memiliki beberapa opsi:

AWS CloudFormation adalah alat yang ampuh untuk menegakkan infrastruktur yang diterapkan secara konsisten di antara akun AWS di beberapa Wilayah AWS. AWS CloudFormation StackSetsmemperluas fungsi ini dengan memungkinkan Anda membuat, memperbarui, atau menghapus CloudFormation tumpukan di beberapa akun dan Wilayah dengan satu operasi. Meskipun AWS CloudFormation menggunakan YAMAL atau JSON untuk mendefinisikan Infrastruktur sebagai Kode, AWS Cloud Development Kit (AWS CDK)memungkinkan Anda untuk mendefinisikan Infrastruktur sebagai Kode menggunakan bahasa pemrograman yang sudah dikenal. Kode Anda dikonversi CloudFormation yang kemudian digunakan untuk menyebarkan sumber daya di AWS.