Opsi pemulihan bencana di cloud

Strategi pemulihan bencana yang tersedia bagi 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 sejumlah Wilayah aktif. Penting untuk secara rutin menguji strategi pemulihan bencana Anda sehingga Anda memiliki keyakinan dalam menjalankannya, saat strategi ini diperlukan.

Gambar 6 - Strategi pemulihan bencana

Untuk peristiwa bencana berdasarkan gangguan atau kehilangan satu pusat data fisik untuk beban kerja yang dirancang dengan baik dan berketersediaan tinggi, Anda mungkin hanya memerlukan pendekatan pencadangan dan pemulihan untuk pemulihan bencana. Jika definisi bencana Anda tidak hanya berupa gangguan atau kehilangan pusat data fisik di suatu Wilayah atau jika Anda tunduk pada persyaratan peraturan yang mewajibkannya, maka Anda harus mempertimbangkan Pilot Light, Warm Standby, atau Multi-Lokasi Aktif/Aktif.

Pencadangan dan pemulihan

Pencadangan dan pemulihan adalah pendekatan yang cocok untuk mengurangi kehilangan atau kerusakan data. Pendekatan ini juga dapat digunakan untuk mengurangi bencana regional dengan mereplikasi data ke Wilayah AWS lainnya, atau untuk memitigasi kurangnya redundansi untuk beban kerja yang di-deploy ke Zona Ketersediaan tunggal. Selain data, Anda harus men-deploy ulang infrastruktur, konfigurasi, dan kode aplikasi di Wilayah pemulihan. Untuk memungkinkan infrastruktur di-deploy kembali dengan cepat tanpa kesalahan, Anda harus selalu men-deploy infrastruktur sebagai kode (IAC) menggunakan layanan seperti AWS CloudFormation atau AWS Cloud Development Kit (AWS CDK). Tanpa IAC, mungkin akan rumit untuk memulihkan beban kerja di Wilayah pemulihan, yang akan menyebabkan penambahan waktu pemulihan dan mungkin melebihi RTO Anda. Selain data pengguna, pastikan juga untuk mencadangkan kode dan konfigurasi, termasuk Amazon Machine Image (AMI) yang Anda gunakan untuk membuat instans Amazon EC2. Anda dapat menggunakan AWS CodePipeline untuk mengotomatisasi deployment ulang kode aplikasi dan konfigurasi.

Gambar 7 - Arsitektur pencadangan dan pemulihan

Layanan AWS

Data beban kerja Anda akan memerlukan strategi pencadangan yang berjalan secara berkala atau terus-menerus. Seberapa sering Anda menjalankan cadangan Anda akan menentukan titik pemulihan yang dapat dicapai (yang harus selaras untuk memenuhi RPO Anda). Cadangannya juga harus menawarkan cara untuk dipulihkan ke titik waktu saat cadangan tersebut dibuat. Cadangan dengan pemulihan titik waktu (PITR) tersedia melalui layanan dan sumber daya berikut:

• Snapshot Amazon Elastic Block Store (Amazon EBS)

• Cadangan Amazon DynamoDB

• Snapshot Amazon RDS

• Snapshot Amazon Aurora DB

• Cadangan Amazon EFS (saat menggunakan AWS Backup)

• Snapshot Amazon Redshift

• Snapshot Amazon Neptunus

Untuk Amazon Simple Storage Service (Amazon S3), Anda dapat menggunakan Amazon S3 Cross-Region Replication (CRR) untuk secara asinkron menyalin objek ke bucket S3 di wilayah DR secara terus-menerus, sambil memberikan versioning untuk objek yang disimpan sehingga Anda dapat memilih titik pemulihan Anda. Replikasi data yang berkelanjutan memiliki keuntungan waktu yang paling singkat (mendekati nol) untuk mencadangkan data Anda, tetapi mungkin tidak melindungi dari peristiwa bencana seperti kerusakan data atau serangan jahat (seperti penghapusan data yang tidak sah) serta pencadangan titik waktu (point-in-time). Replikasi berkelanjutan dibahas dalam bagian Layanan AWS untuk Pilot Light.

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

• Volume Amazon Elastic Block Store (Amazon EBS)

• Instans Amazon EC2

• Basis data Amazon Relational Database Service (Amazon RDS) (termasuk basis data Amazon Aurora)

• Tabel Amazon DynamoDB

• Sistem file Amazon Elastic File System (Amazon EFS)

• Volume AWS Storage Gateway

• Amazon FSx for Windows File Server dan Amazon FSx for Lustre

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

Sebagai strategi pemulihan bencana tambahan untuk data Amazon S3 Anda, aktifkan versioning objek S3. Versioning objek melindungi data Anda di S3 dari konsekuensi tindakan penghapusan atau modifikasi dengan mempertahankan versi asli sebelum tindakan tersebut. Versioning 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, ketika objek dihapus dalam bucket sumber, Amazon S3 menambahkan delete marker di bucket sumber saja. Pendekatan ini melindungi data di Wilayah DR dari penghapusan berniat jahat di wilayah sumber.

Selain data, Anda juga harus mencadangkan konfigurasi dan infrastruktur yang diperlukan untuk men-deploy kembali beban kerja Anda dan memenuhi Sasaran Waktu Pemulihan (RTO). AWS CloudFormation menyediakan Infrastruktur sebagai kode (IaC), dan memungkinkan Anda menentukan semua sumber daya AWS dalam beban kerja sehingga Anda dapat men-deploy dan men-deploy kembali secara andal ke sejumlah akun AWS dan Wilayah AWS. Anda dapat mencadangkan instans Amazon EC2 yang digunakan oleh beban kerja Anda sebagai Amazon Machine Image (AMI). AMI dibuat dari snapshot volume root instans Anda dan volume EBS lainnya yang dilampirkan pada instans Anda. Anda dapat menggunakan AMI ini untuk meluncurkan versi instans EC2 yang dipulihkan. AMI dapat disalin di dalam atau di antara Wilayah. Atau, Anda dapat menggunakan AWS Backup untuk menyalin cadangan di antara akun dan ke Wilayah AWS lainnya. Kemampuan pencadangan lintas-akun membantu melindungi dari peristiwa bencana yang mencakup ancaman orang dalam atau kebocoran keamanan akun. AWS Backup juga menambahkan kemampuan tambahan untuk cadangan EC2—selain volume EBS individual untuk instans, AWS Backup juga menyimpan dan melacak metadata berikut: jenis instans, Virtual Private Cloud (VPC) yang dikonfigurasi, grup keamanan, IAM role, konfigurasi pemantauan, dan tag. Namun, metadata tambahan ini hanya digunakan saat memulihkan cadangan EC2 ke Wilayah AWS yang sama.

Setiap data yang tersimpan di Wilayah pemulihan bencana sebagai cadangan harus dipulihkan pada saat failover. AWS Backup menawarkan kemampuan pemulihan, tetapi saat ini tidak memungkinkan pemulihan terjadwal atau otomatis. Anda dapat menerapkan pemulihan otomatis ke wilayah DR menggunakan SDK AWS untuk memanggil API AWS Backup. Anda dapat menyiapkannya sebagai tugas yang berulang secara rutin atau memicu pemulihan setiap kali pencadangan selesai. Gambar berikut menunjukkan contoh pemulihan otomatis menggunakan Amazon Simple Notification Service (Amazon SNS) dan AWS Lambda.

Gambar 8 - Memulihkan dan menguji cadangan

catatan

Strategi pencadangan Anda harus menyertakan pengujian cadangan Anda. Lihat bagian Menguji Pemulihan Bencana untuk informasi lebih lanjut. Lihat AWS Well-Architected Lab: Menguji Pencadangan dan Pemulihan Data untuk demonstrasi implementasi langsung.

Pilot light

Dengan pendekatan pilot light, Anda mereplikasi data Anda dari satu Wilayah ke Wilayah lainnya dan menyediakan salinan infrastruktur beban kerja inti Anda. Sumber daya yang diperlukan untuk mendukung replikasi data dan cadangan, seperti 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. 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 menskalakan keluar server aplikasi Anda.

Gambar 9 - Arsitektur pilot light

Pendekatan pilot light meminimalkan biaya pemulihan bencana yang berkelanjutan dengan meminimalkan sumber daya aktif, dan menyederhanakan pemulihan pada saat bencana karena semua persyaratan infrastruktur inti sudah terpenuhi. Opsi pemulihan ini mengharuskan Anda untuk mengubah pendekatan deployment Anda. Anda perlu membuat perubahan infrastruktur inti ke setiap Wilayah dan men-deploy perubahan beban kerja (konfigurasi, kode) secara bersamaan ke setiap Wilayah. Langkah ini dapat disederhanakan dengan mengotomatisasi deployment Anda dan menggunakan infrastruktur sebagai kode (IAC) untuk men-deploy infrastruktur di sejumlah akun dan Wilayah (deployment infrastruktur penuh ke Wilayah utama dan deployment infrastruktur yang berskala rendah/dimatikan ke wilayah DR). Sebaiknya Anda menggunakan akun yang berbeda per Wilayah untuk memberikan tingkat isolasi sumber daya dan keamanan tertinggi (jika kredensial yang mengalami kebocoran keamanan juga merupakan bagian dari rencana pemulihan bencana Anda).

Dengan pendekatan ini, Anda juga harus mengurangi dampak bencana data. Replikasi data berkelanjutan melindungi Anda dari sebagian jenis bencana, tetapi mungkin tidak melindungi Anda dari kerusakan atau pemusnahan data kecuali jika strategi Anda juga mencakup versioning data yang disimpan atau opsi untuk pemulihan titik waktu (PITR). Anda dapat mencadangkan data yang direplikasi di Wilayah bencana untuk membuat cadangan point-in-time di Wilayah yang sama.

Layanan AWS

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

Untuk pilot light, replikasi data terus-menerus ke basis data dan penyimpanan data aktif di wilayah DR adalah pendekatan terbaik untuk RPO rendah (jika digunakan di samping pencadangan point-in-time yang dibahas sebelumnya). AWS menyediakan replikasi data asinkron lintas wilayah yang berkelanjutan untuk data menggunakan layanan dan sumber daya berikut:

• Replikasi Amazon Simple Storage Service (Amazon S3)

• Replika baca Amazon RDS

• Basis data global Amazon Aurora

• Tabel global Amazon DynamoDB

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 basis data global Amazon Aurora.

Ketika melakukan failover untuk menjalankan beban kerja baca/tulis Anda dari Wilayah pemulihan bencana, Anda harus mempromosikan replika baca RDS untuk menjadi instans utama. Untuk instans DB selain Aurora, prosesnya membutuhkan waktu beberapa menit untuk selesai, termasuk rebooting. Untuk Cross-Region Replication (CRR) dan failover dengan RDS, penggunaan basis data global Amazon Aurora memberikan beberapa keuntungan. Basis data global menggunakan infrastruktur khusus yang membuat basis data Anda sepenuhnya tersedia untuk melayani aplikasi Anda, dan dapat mereplikasi ke Wilayah sekunder dengan latensi standar di bawah satu detik (dan dalam Wilayah AWS, jauh lebih rendah dari 100 milidetik). Dengan basis data global Amazon Aurora, jika Wilayah utama Anda mengalami penurunan atau gangguan performa, Anda dapat mempromosikan salah satu wilayah sekunder untuk mengambil tanggung jawab baca/tulis dalam waktu kurang dari 1 menit bahkan jika terjadi gangguan regional yang menyeluruh. Promosi ini bisa otomatis dan tidak ada reboot.

Versi yang berskala rendah dari infrastruktur beban kerja inti Anda dengan sumber daya yang lebih sedikit atau lebih kecil harus di-deploy di Wilayah DR Anda. Dengan menggunakan AWS CloudFormation, Anda dapat menentukan infrastruktur Anda dan men-deploy-nya secara konsisten di seluruh akun AWS dan di seluruh Wilayah AWS. AWS CloudFormation menggunakan parameter semu yang telah ditetapkan untuk mengidentifikasi akun AWS dan Wilayah AWS tempat layanan ini digunakan. Oleh karena itu, Anda dapat menerapkan logika kondisi di templat CloudFormation Anda untuk men-deploy hanya versi berskala rendah dari infrastruktur Anda di Wilayah DR. Untuk deployment instans EC2, Amazon Machine Image (AMI) menyediakan informasi seperti konfigurasi perangkat keras dan perangkat lunak yang diinstal. Anda dapat menerapkan alur Image Builder yang membuat AMI yang Anda butuhkan dan menyalinnya ke Wilayah utama dan cadangan Anda. Ini membantu memastikan bahwa golden AMI ini memiliki semua yang Anda butuhkan untuk men-deploy ulang atau menskalakan keluar beban kerja Anda di wilayah baru, jika terjadi peristiwa bencana. Instans Amazon EC2 digunakan dalam konfigurasi berskala rendah (lebih sedikit instans daripada di Wilayah utama Anda). Anda dapat menggunakan hibernasi untuk mengalihkan instans EC2 ke dalam status berhenti yang tidak mengharuskan Anda membayar biaya EC2, Anda hanya membayar penyimpanan yang digunakan. Untuk memulai instans EC2, Anda dapat membuat skrip menggunakan AWS Command Line Interface (CLI) atau SDK AWS. Untuk menskalakan keluar infrastruktur untuk mendukung lalu lintas produksi, lihat AWS Auto Scaling di bagian Warm Standby.

Untuk konfigurasi aktif/siaga seperti pilot light, semua lalu lintas awalnya pergi ke Wilayah utama dan beralih ke Wilayah pemulihan bencana jika Wilayah utama tidak lagi tersedia. Ada dua opsi manajemen lalu lintas yang perlu dipertimbangkan dengan menggunakan layanan AWS. Opsi pertama adalah menggunakan Amazon Route 53. Menggunakan Amazon Route 53, Anda dapat mengaitkan sejumlah titik akhir IP di satu atau beberapa Wilayah AWS dengan nama domain Route 53. Kemudian, Anda dapat mengarahkan lalu lintas ke titik akhir yang sesuai dengan nama domain tersebut. Pemeriksaan kondisi Amazon Route 53 memantau titik akhir ini. Dengan menggunakan pemeriksaan kondisi ini, Anda dapat mengonfigurasi failover DNS untuk memastikan lalu lintas dikirim ke titik akhir yang berkondisi baik.

Pilihan kedua adalah dengan menggunakan AWS Global Accelerator. Dengan menggunakan AnyCast IP, Anda dapat mengaitkan sejumlah titik akhir dalam satu atau beberapa Wilayah AWS dengan alamat IP statis yang sama. AWS Global Accelerator kemudian merutekan lalu lintas ke titik akhir yang sesuai yang terkait dengan alamat itu. Pemeriksaan kondisi Accelerator Global memantau titik akhir. Dengan menggunakan pemeriksaan kondisi ini, AWS Global Accelerator secara otomatis memeriksa kondisi aplikasi Anda dan mengarahkan lalu lintas pengguna hanya ke titik akhir aplikasi yang berkondisi baik. Global Accelerator menawarkan latensi yang lebih rendah ke titik akhir aplikasi karena memanfaatkan jaringan edge AWS 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).

CloudEndure Disaster Recovery

CloudEndure Disaster Recovery, yang tersedia dari AWS Marketplace, terus mereplikasi aplikasi yang di-host server dan basis data yang di-host server dari sumber mana pun ke AWS menggunakan replikasi tingkat blok terhadap server yang mendasarinya. CloudEndure Disaster Recovery memungkinkan Anda menggunakan AWS Cloud sebagai Wilayah pemulihan bencana untuk beban kerja on-premise dan lingkungannya. Ini juga dapat digunakan untuk pemulihan bencana beban kerja yang di-host AWS jika hanya terdiri dari aplikasi dan basis data yang di-host di EC2 (yaitu bukan RDS). CloudEndure Disaster Recovery menggunakan strategi Pilot Light, dengan memelihara salinan data dan sumber daya yang dimatikan di Amazon Virtual Private Cloud (Amazon VPC) yang digunakan sebagai area persiapan. Ketika peristiwa failover dipicu, sumber daya yang dipersiapkan akan digunakan untuk secara otomatis membuat deployment kapasitas penuh di Amazon VPC target yang digunakan sebagai lokasi pemulihan.

Gambar 10 - CloudEndure Disaster Recovery

Warm standby

Pendekatan warm standby berfokus untuk memastikan bahwa ada salinan lingkungan produksi Anda yang berskala rendah, namun berfungsi penuh, di Wilayah lain. Pendekatan ini memperluas konsep pilot light dan mengurangi waktu pemulihan karena beban kerja Anda selalu aktif di Wilayah lain. 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 warm standby

Catatan: Perbedaan antara pilot light dan warm standby terkadang sulit dimengerti. Keduanya mencakup sebuah lingkungan di Wilayah DR Anda dengan salinan aset Wilayah utama Anda. Perbedaannya adalah bahwa pilot light tidak dapat memproses permintaan tanpa tindakan tambahan yang diambil terlebih dahulu, sedangkan warm standby dapat menangani lalu lintas (pada tingkat kapasitas yang berkurang) dengan segera. Pendekatan pilot light mengharuskan Anda untuk “menghidupkan” server, mungkin men-deploy infrastruktur tambahan (non-inti), dan menaikkan skala, sedangkan Warm Standby hanya mengharuskan Anda untuk menaikkan skala (semuanya sudah di-deploy 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 pilot light juga digunakan dalam warm standby untuk pencadangan data, replikasi data, perutean lalu lintas aktif/siaga, dan deployment infrastruktur termasuk instans EC2.

AWS Auto Scaling digunakan untuk menskalakan sumber daya termasuk instans Amazon EC2, tugas Amazon ECS, throughput Amazon DynamoDB, dan replika Amazon Aurora dalam Wilayah AWS. Amazon EC2 Auto Scaling menskalakan deployment instans EC2 di seluruh Zona Ketersediaan dalam Wilayah AWS, yang memberikan ketahanan dalam Wilayah tersebut. Gunakan Auto Scaling untuk menskalakan keluar Wilayah DR Anda untuk kemampuan produksi penuh, sebagai bagian dari strategi pilot light atau warm standby. 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 SDK AWS, atau dengan men-deploy ulang templat AWS CloudFormation Anda menggunakan nilai kapasitas baru yang diinginkan. Anda dapat menggunakan parameter AWS CloudFormation untuk mempermudah deployment ulang templat CloudFormation. Pastikan kuota layanan di Wilayah DR Anda ditetapkan cukup tinggi sehingga tidak membatasi Anda untuk menskalakan ke atas hingga kapasitas produksi.

Multi-lokasi aktif/aktif

Anda dapat menjalankan beban kerja Anda secara bersamaan di sejumlah Wilayah sebagai bagian dari strategi multi-lokasi aktif/aktif atau hot standby aktif/pasif. Multi-lokasi aktif/aktif melayani lalu lintas dari semua wilayah tempat strategi ini di-deploy, sedangkan hot standby melayani lalu lintas hanya dari satu wilayah, dan Wilayah lainnya hanya digunakan untuk pemulihan bencana. Dengan pendekatan multi-lokasi aktif/aktif, pengguna dapat mengakses beban kerja Anda di Wilayah mana pun tempat strategi ini di-deploy. Pendekatan ini adalah pendekatan yang paling kompleks dan mahal untuk pemulihan bencana, tetapi dapat mengurangi waktu pemulihan Anda mendekati nol untuk sebagian besar bencana dengan pilihan dan implementasi teknologi yang benar (namun kerusakan data mungkin akan memerlukan cadangan, yang biasanya menghasilkan titik pemulihan non-nol). Hot standby menggunakan konfigurasi aktif/pasif yang hanya mengarahkan pengguna ke satu wilayah, dan wilayah DR tidak mengambil lalu lintas. Sebagian besar pelanggan menemukan bahwa jika mereka akan menyiapkan lingkungan penuh di Wilayah kedua, masuk akal untuk menggunakannya dengan konfigurasi aktif/aktif. Atau, jika Anda tidak ingin menggunakan kedua Wilayah untuk menangani lalu lintas pengguna, maka Warm Standby menawarkan pendekatan yang lebih ekonomis dan secara operasional tidak kompleks.

Gambar 12 - Arsitektur multi-lokasi aktif/aktif (ubah satu jalur Aktif menjadi Tidak Aktif untuk hot standby)

Dengan multi-lokasi aktif/aktif, karena beban kerja berjalan di lebih dari satu Wilayah, tidak akan ada failover yang diperlukan dalam skenario ini. Pengujian pemulihan bencana dalam hal ini akan berfokus pada bagaimana beban kerja bereaksi terhadap kehilangan suatu Wilayah: Apakah lalu lintas dialihkan jauh dari Wilayah yang gagal? Dapatkah Wilayah lain menangani semua lalu lintas? Pengujian untuk bencana data juga diperlukan. Pencadangan dan pemulihan masih diperlukan dan harus diuji secara teratur. Perlu juga dicatat bahwa waktu pemulihan untuk bencana data yang mencakup kerusakan, penghapusan, atau obfuskasi data akan selalu lebih besar dari nol dan titik pemulihan akan selalu berada di titik tertentu sebelum bencana ditemukan. Jika kompleksitas dan biaya tambahan dari pendekatan multi-lokasi aktif/aktif (atau hot standby) diperlukan untuk mempertahankan waktu pemulihan hampir nol, maka upaya tambahan harus dilakukan untuk menjaga keamanan dan mencegah kesalahan manusia agar dapat mengurangi bencana manusia.

Layanan AWS

Semua layanan AWS yang tercakup dalam pencadangan dan pemulihan, pilot light, dan warm standby juga digunakan di sini untuk pencadangan data point-in-time, replikasi data, perutean lalu lintas aktif/aktif, dan deployment dan penskalaan infrastruktur termasuk instans EC2.

Untuk skenario aktif/pasif yang dibahas sebelumnya (Pilot Light dan Warm Standby), Amazon Route 53 dan AWS Global Accelerator dapat digunakan untuk merutekan lalu lintas jaringan ke wilayah aktif. Untuk strategi aktif/aktif di sini, kedua layanan ini juga memungkinkan definisi kebijakan yang menentukan pengguna mana yang dialihkan ke titik akhir regional aktif tertentu. Dengan AWS Global Accelerator, Anda menetapkan dial lalu lintas untuk mengontrol persentase lalu lintas yang diarahkan ke setiap titik akhir aplikasi. Amazon Route 53 mendukung pendekatan persentase ini, dan juga sejumlah kebijakan lain yang tersedia termasuk yang berbasis geoproksimitas dan latensi. Global Accelerator secara otomatis memanfaatkan jaringan server edge AWS yang luas, untuk melakukan onboarding lalu lintas ke tulang punggung jaringan AWS sesegera mungkin, sehingga menghasilkan latensi permintaan yang lebih rendah.

Replikasi data dengan strategi ini memungkinkan RPO mendekati nol. Layanan AWS, seperti basis data global Aurora , menggunakan infrastruktur khusus yang membuat basis data Anda tersedia sepenuhnya untuk melayani aplikasi, dan dapat mereplikasi ke satu wilayah sekunder dengan latensi standar di bawah satu detik. Dengan strategi aktif/pasif, penulisan hanya terjadi pada Wilayah utama. Perbedaan dengan aktif/aktif adalah merancang bagaimana menangani penulisan untuk setiap Wilayah aktif. Biasanya pembacaan pengguna dirancang agar disajikan dari Wilayah yang terdekat, yang dikenal sebagai read local. Dengan penulisan, Anda memiliki beberapa opsi:

• Strategi write global akan merutekan semua penulisan ke satu Wilayah. Jika Wilayah itu gagal, Wilayah lain akan dipromosikan untuk menerima penulisan. Basis data global Aurora sangat cocok untuk write global, karena mendukung sinkronisasi dengan replika baca di seluruh Wilayah, dan Anda dapat mempromosikan salah satu Wilayah sekunder untuk mengambil tanggung jawab baca/tulis dalam waktu kurang dari 1 menit.

• Strategi write local merutekan penulisan ke Wilayah terdekat (seperti pembacaan). Tabel global Amazon DynamoDB memungkinkan strategi seperti itu, sehingga memungkinkan pembacaan dan penulisan dari setiap wilayah, tempat tabel global Anda di-deploy. Tabel global Amazon DynamoDB menggunakan rekonsiliasi penulis terakhir diprioritaskan jika ada pembaruan yang bersamaan.

• Strategi write partitioned menetapkan penulisan ke Wilayah tertentu berdasarkan kunci partisi (seperti ID pengguna) untuk menghindari konflik penulisan. Replikasi Amazon S3 yang dikonfigurasi secara dua arah dapat digunakan untuk kasus ini, dan saat ini mendukung replikasi antara dua Wilayah. Saat menerapkan pendekatan ini, pastikan untuk mengaktifkan sinkronisasi modifikasi replika pada kedua bucket A dan B untuk mereplikasi perubahan metadata seperti daftar kontrol akses (ACL) objek, tag objek, atau kunci objek pada objek yang direplikasi. Anda juga dapat mengonfigurasi apakah akan mereplikasi delete marker di antara bucket di Wilayah aktif Anda. Selain replikasi, strategi Anda juga harus menyertakan pencadangan point-in-time untuk melindungi terhadap peristiwa kerusakan atau pemusnahan data.

AWS CloudFormation adalah alat yang ampuh untuk menegakkan infrastruktur yang di-deploy secara konsisten di antara akun AWS di sejumlah Wilayah AWS. AWS CloudFormation StackSets memperluas fungsionalitas ini dengan memungkinkan Anda membuat, memperbarui, atau menghapus tumpukan CloudFormation di sejumlah akun dan Wilayah dengan satu operasi. Meskipun AWS CloudFormation menggunakan YAML atau JSON untuk mendefinisikan Infrastruktur sebagai Kode (IaC), AWS Cloud Development Kit (AWS CDK) memungkinkan Anda untuk mendefinisikan Infrastruktur sebagai Kode (IaC) menggunakan bahasa pemrograman yang sudah dikenal. Kode Anda dikonversi ke CloudFormation yang kemudian digunakan untuk men-deploy sumber daya di AWS.