Layanan regional

Layanan regional adalah layanan yang AWS telah dibangun di atas beberapa Availability Zone sehingga pelanggan tidak perlu mencari cara untuk memanfaatkan layanan zona dengan sebaik-baiknya. Kami secara logis mengelompokkan layanan yang diterapkan di beberapa Availability Zone untuk menyajikan satu titik akhir Regional kepada pelanggan. Amazon SQS dan Amazon DynamoDB adalah contoh layanan Regional. Mereka menggunakan independensi dan redundansi Availability Zone untuk meminimalkan kegagalan infrastruktur sebagai kategori risiko ketersediaan dan daya tahan. Amazon S3, misalnya, menyebarkan permintaan dan data di beberapa Availability Zone dan dirancang untuk memulihkan secara otomatis dari kegagalan Availability Zone. Namun, Anda hanya berinteraksi dengan titik akhir Regional layanan.

AWS percaya bahwa sebagian besar pelanggan dapat mencapai tujuan ketahanan mereka di satu Wilayah dengan menggunakan layanan Regional atau arsitektur Multi-AZ yang mengandalkan layanan zona. Namun, beberapa beban kerja mungkin memerlukan redundansi tambahan, dan Anda dapat menggunakan isolasi Wilayah AWS untuk membuat arsitektur Multi-Region untuk HA atau tujuan kontinuitas bisnis. Pemisahan fisik dan logis antara Wilayah AWS menghindari kegagalan yang berkorelasi di antara mereka. Dengan kata lain, mirip dengan jika Anda adalah EC2 pelanggan dan bisa mendapatkan keuntungan dari isolasi Availability Zone dengan menyebarkan di seluruh mereka, Anda bisa mendapatkan manfaat yang sama untuk layanan Regional dengan menyebarkan di beberapa Wilayah. Ini mengharuskan Anda menerapkan arsitektur Multi-wilayah untuk aplikasi Anda, yang dapat membantu Anda tahan terhadap gangguan layanan Regional.

Namun, mencapai manfaat arsitektur Multi-Region bisa jadi sulit; itu membutuhkan kerja yang cermat untuk memanfaatkan isolasi Regional sambil tidak membatalkan apa pun di tingkat aplikasi. Misalnya, jika Anda gagal dalam aplikasi antar Wilayah, Anda perlu menjaga pemisahan yang ketat antara tumpukan aplikasi di setiap Wilayah, mengetahui semua dependensi aplikasi, dan failover semua bagian aplikasi secara bersamaan. Mencapai hal ini dengan arsitektur berbasis layanan mikro yang kompleks yang memiliki banyak ketergantungan antar aplikasi memerlukan perencanaan dan koordinasi di antara banyak tim teknik dan bisnis. Mengizinkan beban kerja individu untuk membuat keputusan failover mereka sendiri membuat koordinasi menjadi kurang kompleks, tetapi memperkenalkan perilaku modal melalui perbedaan signifikan dalam latensi yang terjadi di seluruh Wilayah dibandingkan dengan di dalam satu Wilayah.

AWS tidak menyediakan fitur replikasi Lintas Wilayah sinkron saat ini. Saat menggunakan datastore yang direplikasi secara asinkron (disediakan oleh AWS) di seluruh Wilayah, ada kemungkinan kehilangan atau ketidakkonsistenan data saat Anda gagal dalam aplikasi antar Wilayah. Untuk mengurangi kemungkinan ketidakkonsistenan, Anda memerlukan proses rekonsiliasi data yang andal yang Anda yakini dan mungkin perlu beroperasi pada beberapa penyimpanan data di seluruh portofolio beban kerja Anda, atau Anda harus bersedia menerima kehilangan data. Akhirnya, Anda perlu mempraktikkan failover untuk mengetahui bahwa itu akan berfungsi saat Anda membutuhkannya. Memutar aplikasi Anda secara teratur antar Wilayah untuk mempraktikkan failover adalah investasi waktu dan sumber daya yang substansif. Jika Anda memutuskan untuk menggunakan datastore yang direplikasi secara sinkron di seluruh Wilayah untuk mendukung aplikasi Anda yang berjalan dari lebih dari satu Wilayah secara bersamaan, karakteristik kinerja dan latensi database semacam itu yang mencakup 100-an atau 1000-an mil sangat berbeda dari database yang beroperasi di satu Wilayah. Ini mengharuskan Anda untuk merencanakan tumpukan aplikasi Anda dari bawah ke atas untuk memperhitungkan perilaku ini. Ini juga membuat ketersediaan kedua Wilayah menjadi ketergantungan yang sulit, yang dapat mengakibatkan penurunan ketahanan beban kerja Anda.