Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # AWS jenis layanan AWS mengoperasikan tiga kategori layanan yang berbeda berdasarkan batas isolasi kesalahan mereka: zona, Regional, dan global. Bagian ini akan menjelaskan secara lebih rinci bagaimana berbagai jenis layanan ini telah dirancang sehingga Anda dapat menentukan bagaimana kegagalan dalam layanan dari jenis layanan tertentu akan berdampak pada AWS beban kerja Anda berjalan. Ini juga memberikan panduan tingkat tinggi tentang cara merancang beban kerja Anda untuk menggunakan layanan ini dengan cara yang tangguh. Untuk layanan global, dokumen ini juga memberikan panduan preskriptif [Lampiran A - Panduan layanan partisi](appendix-a---partitional-service-guidance.md) dan [Lampiran B - Panduan layanan global jaringan Edge](appendix-b---edge-network-global-service-guidance.md) yang dapat membantu Anda mencegah dampak pada beban kerja Anda dari gangguan bidang kontrol dalam AWS layanan, membantu Anda mengambil ketergantungan dengan aman pada layanan global sambil meminimalkan pengenalan satu titik kegagalan. **Topics** + [Layanan Zonal](zonal-services.md) + [Layanan regional](regional-services.md) + [Layanan global](global-services.md) # Layanan Zonal [https://aws.amazon.com/builders-library/static-stability-using-availability-zones/](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/) (AZI) memungkinkan AWS untuk menawarkan layanan zona, seperti Amazon EC2 dan AmazonEBS. Layanan zonal adalah layanan yang menyediakan kemampuan untuk menentukan Availability Zone mana sumber daya digunakan. Layanan ini beroperasi secara independen di setiap Availability Zone dalam suatu Wilayah, dan yang lebih penting, gagal secara independen di setiap Availability Zone juga. Ini berarti bahwa komponen layanan dalam satu Availability Zone tidak mengambil dependensi pada komponen di Availability Zone lainnya. Kita dapat melakukan ini karena layanan zonal memiliki bidang **data zona**. Dalam beberapa kasus, seperti denganEC2, layanan ini juga mencakup bidang kontrol zona untuk operasi yang disejajarkan secara zonal, seperti meluncurkan instance. EC2 Untuk layanan tersebut, AWS juga menyediakan endpoint pesawat kontrol regional untuk memudahkan berinteraksi dengan layanan. Bidang kontrol regional juga menyediakan fungsionalitas cakupan regional serta berfungsi sebagai lapisan agregasi dan perutean di atas bidang kontrol zona. Ini ditunjukkan pada gambar berikut. ![\[Gambar ini menunjukkan layanan zona dengan bidang kontrol dan bidang data yang terisolasi secara zona\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-fault-isolation-boundaries/images/a-zonal-service-with-zonally-isolated-control-planes-and-data-planes.png) Availability Zones memberi pelanggan kemampuan untuk mengoperasikan beban kerja produksi yang lebih tersedia, toleran terhadap kesalahan, dan skalabel daripada yang mungkin dilakukan dari satu pusat data. Ketika beban kerja menggunakan beberapa Availability Zone, pelanggan akan lebih terisolasi dan terlindungi dari masalah yang berdampak pada infrastruktur fisik Availability Zone tunggal. Ini membantu pelanggan untuk membangun layanan yang berlebihan di seluruh Availability Zone dan, jika dirancang dengan benar, tetap beroperasi meskipun satu Availability Zone mengalami kegagalan. Pelanggan dapat memanfaatkan AZI untuk menciptakan beban kerja yang sangat tersedia dan tangguh. Menerapkan AZI dalam arsitektur Anda membantu Anda memulihkan dengan cepat dari kegagalan Availability Zone yang terisolasi karena sumber daya Anda dalam satu Availability Zone meminimalkan atau menghilangkan interaksi dengan sumber daya di Availability Zone lainnya. Ini membantu menghapus dependensi lintas Availability Zone yang menyederhanakan evakuasi Availability Zone. Lihat [Pola Ketahanan Multi-AZ Tingkat Lanjut](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/advanced-multi-az-resilience-patterns.html) untuk detail selengkapnya tentang pembuatan mekanisme evakuasi Availability Zone. Selain itu, Anda dapat memanfaatkan Availability Zone lebih lanjut dengan mengikuti beberapa praktik terbaik yang sama yang AWS digunakan untuk layanannya sendiri, seperti hanya menerapkan perubahan ke Availability Zone tunggal pada satu waktu atau menghapus Availability Zone dari layanan jika perubahan di Availability Zone berjalan buruk. [Stabilitas statis](static-stability.md) juga merupakan konsep penting untuk arsitektur Multi-Availability Zone. Salah satu mode kegagalan yang harus Anda rencanakan dengan arsitektur Multi-Availability Zone adalah hilangnya Availability Zone, yang dapat mengakibatkan hilangnya kapasitas Availability Zone. Jika Anda belum menyediakan kapasitas yang cukup untuk menangani hilangnya Availability Zone, ini dapat mengakibatkan kapasitas Anda yang tersisa kewalahan oleh beban saat ini. Selain itu, Anda harus bergantung pada bidang kontrol layanan zona yang Anda gunakan untuk mengganti kapasitas yang hilang, yang bisa kurang dapat diandalkan daripada desain yang stabil secara statis. Dalam hal ini, pra-penyediaan kapasitas ekstra yang cukup dapat membantu Anda stabil secara statis terhadap hilangnya domain kesalahan, seperti Availability Zone, dengan dapat melanjutkan operasi normal tanpa perlu perubahan dinamis. Anda dapat memilih untuk menggunakan grup EC2 instans penskalaan otomatis yang diterapkan di beberapa Availability Zone untuk menskalakan masuk dan keluar secara dinamis, berdasarkan kebutuhan beban kerja Anda. Penskalaan otomatis berfungsi dengan baik untuk perubahan bertahap dalam penggunaan yang terjadi selama beberapa menit hingga puluhan menit. Namun, meluncurkan EC2 instance baru membutuhkan waktu, terutama jika instance Anda memerlukan bootstrap (seperti menginstal agen, binari aplikasi, atau file konfigurasi). Selama waktu ini, kapasitas Anda yang tersisa bisa kewalahan oleh beban saat ini. Selain itu, menerapkan instance baru melalui penskalaan otomatis bergantung pada bidang kontrol. EC2 Ini menyajikan trade-off: Agar stabil secara statis terhadap hilangnya satu Availability Zone, Anda perlu menyediakan EC2 instance yang cukup di Availability Zone lainnya untuk menangani beban yang telah digeser dari Availability Zone yang terganggu, alih-alih mengandalkan penskalaan otomatis untuk menyediakan instance baru. Namun, kapasitas ekstra pra-penyediaan dapat menimbulkan biaya tambahan. Misalnya, selama operasi normal, anggap beban kerja Anda memerlukan enam instance untuk melayani lalu lintas pelanggan di tiga Availability Zone. Agar stabil secara statis terhadap satu kegagalan Availability Zone, Anda akan menerapkan tiga instance di setiap Availability Zone, dengan total sembilan. Jika satu instance Availability Zone gagal, Anda masih memiliki enam yang tersisa dan dapat terus melayani lalu lintas pelanggan Anda tanpa perlu menyediakan dan mengonfigurasi instance baru selama kegagalan. Mencapai stabilitas statis untuk EC2 kapasitas Anda memiliki biaya tambahan, karena, dalam hal ini, Anda menjalankan 50% instance tambahan. Tidak semua layanan di mana Anda dapat menyediakan sumber daya pra-penyediaan akan dikenakan biaya tambahan, seperti pra-penyediaan bucket S3 atau pengguna. Anda perlu mempertimbangkan setiap trade-off penerapan stabilitas statis terhadap risiko melebihi waktu pemulihan yang diinginkan untuk beban kerja Anda. AWS Local Zones dan Outposts membawa bidang data AWS layanan tertentu lebih dekat ke pengguna akhir. Pesawat kontrol untuk layanan ini berada di Wilayah induk. Instans Local Zone atau Outposts Anda akan memiliki dependensi bidang kontrol untuk layanan zona seperti EC2 dan EBS pada Availability Zone tempat Anda membuat subnet Local Zone atau Outposts. Mereka juga akan memiliki dependensi pada pesawat kontrol Regional untuk layanan Regional seperti Elastic Load Balancing ELB (), grup keamanan, dan pesawat kontrol Kubernetes yang dikelola Amazon Elastic Kubernetes [Service EKS](https://docs.aws.amazon.com/eks/latest/userguide/local-zones.html) (Amazon) (jika Anda menggunakan). EKS Untuk informasi tambahan khusus untuk Outposts, lihat [dokumentasi](https://docs.aws.amazon.com/outposts/latest/userguide/disaster-recovery-resiliency.html) dan [dukungan dan pemeliharaan](https://aws.amazon.com/outposts/rack/faqs/). FAQ Menerapkan stabilitas statis saat menggunakan Local Zones atau Outposts untuk membantu meningkatkan ketahanan untuk mengontrol gangguan atau gangguan pesawat dalam konektivitas jaringan ke Wilayah induk. # 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](https://aws.amazon.com/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. # Layanan global Selain AWS layanan Regional dan zona, ada satu set kecil AWS layanan yang pesawat kontrol dan pesawat datanya tidak ada secara independen di setiap Wilayah. *Karena sumber daya mereka tidak spesifik Wilayah, mereka biasanya disebut sebagai global.* AWS Layanan global masih mengikuti pola AWS desain konvensional untuk memisahkan bidang kontrol dan bidang data untuk mencapai stabilitas statis. Perbedaan signifikan untuk sebagian besar layanan global adalah bahwa pesawat kontrol mereka di-host dalam *satu* Wilayah AWS, sementara pesawat data mereka didistribusikan secara global. Ada tiga jenis layanan global dan satu set layanan yang dapat tampak global berdasarkan konfigurasi yang Anda pilih. Bagian berikut akan mengidentifikasi setiap jenis layanan global dan bagaimana bidang kontrol dan bidang data mereka dipisahkan. Anda dapat menggunakan informasi ini untuk memandu bagaimana Anda membangun mekanisme ketersediaan tinggi (HA) dan pemulihan bencana (DR) yang andal tanpa perlu bergantung pada pesawat kontrol layanan global. Pendekatan ini membantu menghilangkan satu titik kegagalan dalam arsitektur Anda dan menghindari potensi dampak lintas wilayah, bahkan ketika Anda beroperasi di Wilayah yang berbeda dari tempat pesawat kontrol layanan global di-host. Ini juga membantu Anda menerapkan mekanisme failover dengan aman yang tidak bergantung pada pesawat kontrol layanan global. ## Layanan global yang unik berdasarkan partisi Beberapa AWS layanan global ada di setiap partisi (disebut dalam paper ini sebagai layanan *partisi*). Layanan partisi menyediakan bidang kontrol mereka dalam satu Wilayah AWS. Beberapa layanan partisi, seperti AWS Network Manager, hanya mengontrol pesawat dan mengatur bidang data layanan lain. Layanan partisi lainnya, sepertiIAM, memiliki bidang data mereka sendiri yang diisolasi dan didistribusikan di semua partisi. Wilayah AWS Kegagalan dalam layanan partisi tidak memengaruhi partisi lain. Di `aws` partisi, bidang kontrol IAM layanan berada di `us-east-1` Wilayah, dengan bidang data terisolasi di setiap Wilayah partisi. Layanan partisi juga memiliki bidang kontrol independen dan pesawat data di `aws-us-gov` dan `aws-cn` partisi. Pemisahan bidang kontrol dan bidang data untuk IAM ditunjukkan pada diagram berikut. ![\[Gambar ini menggambarkan bahwa IAM memiliki bidang kontrol tunggal dan bidang data regional\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-fault-isolation-boundaries/images/iam-single-control-plane-and-regionalized-data-plane.png) Berikut ini adalah layanan partisi dan lokasi bidang kontrol mereka di `aws` partisi: + AWS IAM (`us-east-1`) + AWS Organizations (`us-east-1`) + AWS Manajemen Akun (`us-east-1`) + Route 53 Application Recovery Controller (ARC`us-west-2`) () - Layanan ini hanya ada di `aws` partisi + AWS Manajer Jaringan (`us-west-2`) + Rute 53 Pribadi DNS (`us-east-1`) Jika salah satu dari pesawat kontrol layanan ini memiliki peristiwa yang berdampak pada ketersediaan, Anda mungkin tidak dapat menggunakan operasi CRUDL tipe -yang disediakan oleh layanan ini. Jadi, jika strategi pemulihan Anda memiliki ketergantungan pada operasi ini, dampak ketersediaan pada pesawat kontrol atau Wilayah yang menampung pesawat kontrol akan mengurangi peluang Anda untuk pemulihan yang berhasil. [Lampiran A - Panduan layanan partisi](appendix-a---partitional-service-guidance.md)menyediakan strategi untuk menghilangkan dependensi pada pesawat kontrol layanan global selama pemulihan. ****Rekomendasi**** Jangan mengandalkan bidang kontrol layanan partisi di jalur pemulihan Anda. Sebaliknya, andalkan operasi pesawat data dari layanan ini. Lihat [Lampiran A - Panduan layanan partisi](appendix-a---partitional-service-guidance.md) untuk detail tambahan tentang bagaimana Anda harus merancang untuk layanan partisi. ## Layanan global di jaringan edge Rangkaian AWS layanan global berikutnya memiliki bidang kontrol di `aws` partisi dan meng-host pesawat data mereka di infrastruktur [titik kehadiran](points-of-presence.md) global (PoP) (dan berpotensi Wilayah AWS juga). Pesawat data yang di-host PoPs dapat diakses dari sumber daya di partisi apa pun serta internet. Misalnya, Route 53 mengoperasikan pesawat kontrolnya di `us-east-1` Wilayah, tetapi pesawat datanya didistribusikan di ratusan PoPs secara global, serta masing-masing Wilayah AWS (untuk mendukung Rute 53 Publik dan Swasta di DNS dalam Wilayah). Pemeriksaan kesehatan Route 53 juga merupakan bagian dari bidang data, dan dilakukan dari delapan Wilayah AWS di `aws` partisi. Klien dapat menyelesaikan DNS menggunakan zona yang dihosting publik Route 53 dari mana saja di internet, termasuk partisi lain seperti GovCloud, serta dari AWS Virtual Private Cloud (VPC). Berikut ini adalah layanan jaringan edge global dan lokasi bidang kontrolnya di `aws` partisi: + Rute 53 Publik DNS (`us-east-1`) + Amazon CloudFront (`us-east-1`) + AWS WAF Klasik untuk CloudFront (`us-east-1`) + AWS WAF untuk CloudFront (`us-east-1`) + Amazon Certificate Manager (ACM) untuk CloudFront (`us-east-1`) + AWSAkselerator Global (AGA) (`us-west-2`) + AWS Shield Advanced (`us-east-1`) Jika Anda menggunakan pemeriksaan AGA kesehatan untuk EC2 instance atau alamat IP Elastis, ini menggunakan pemeriksaan kesehatan Route 53. Membuat atau memperbarui pemeriksaan AGA kesehatan akan tergantung pada bidang kontrol Route 53 di`us-east-1`. Pelaksanaan pemeriksaan AGA kesehatan menggunakan pesawat data pemeriksaan kesehatan Rute 53. Selama kegagalan yang berdampak pada Wilayah yang menampung pesawat kontrol untuk layanan ini, atau kegagalan yang berdampak pada bidang kontrol itu sendiri, Anda mungkin tidak dapat menggunakan operasi CRUDL tipe -yang disediakan oleh layanan ini. Jika Anda telah mengambil ketergantungan pada operasi ini dalam strategi pemulihan Anda, strategi itu mungkin lebih kecil kemungkinannya untuk berhasil daripada jika Anda hanya mengandalkan bidang data dari layanan ini. ****Rekomendasi**** Jangan mengandalkan bidang kontrol layanan jaringan tepi di jalur pemulihan Anda. Sebaliknya, andalkan operasi pesawat data dari layanan ini. Lihat [Lampiran B - Panduan layanan global jaringan Edge](appendix-b---edge-network-global-service-guidance.md) untuk detail tambahan tentang cara merancang layanan global di jaringan edge. ## Operasi Wilayah Tunggal Global Kategori terakhir terdiri dari operasi pesawat kontrol khusus dalam layanan yang memiliki cakupan dampak global, bukan seluruh layanan seperti kategori sebelumnya. Saat Anda berinteraksi dengan layanan zona dan Regional di Wilayah yang Anda tentukan, operasi tertentu memiliki ketergantungan mendasar pada satu Wilayah yang berbeda dari tempat sumber daya berada. Ini berbeda dari layanan yang hanya disediakan di satu Wilayah; lihat [Lampiran C - Layanan Single-Region](appendix-c---single-region-services.md) untuk daftar layanan tersebut. Selama kegagalan yang memengaruhi ketergantungan global yang mendasarinya, Anda mungkin tidak dapat menggunakan tindakan CRUDL -type dari operasi dependen. Jika Anda telah mengambil ketergantungan pada operasi ini dalam strategi pemulihan Anda, strategi itu mungkin lebih kecil kemungkinannya untuk berhasil daripada jika Anda hanya mengandalkan bidang data dari layanan ini. Anda harus menghindari ketergantungan pada operasi ini untuk strategi pemulihan Anda. Berikut ini adalah daftar layanan yang mungkin bergantung pada layanan lain, yang memiliki cakupan global: + **Rute 53** Beberapa AWS layanan membuat sumber daya yang menyediakan DNS nama khusus sumber daya. Misalnya, saat Anda menyediakan Elastic Load Balancer (ELB), layanan akan membuat DNS catatan publik dan pemeriksaan kesehatan di Route 53 untuk. ELB Ini bergantung pada pesawat kontrol Route 53 di`us-east-1`. Layanan lain yang Anda gunakan mungkin juga perlu menyediakanELB, membuat DNS catatan Route 53 publik, atau membuat pemeriksaan kesehatan Route 53 sebagai bagian dari alur kerja bidang kontrol mereka. Misalnya, penyediaan REST API sumber daya Amazon API Gateway, database Amazon Relational Database Service (AmazonRDS), atau domain OpenSearch Layanan Amazon semuanya menghasilkan pembuatan DNS catatan di Route 53. Berikut ini adalah daftar layanan yang bidang kontrolnya bergantung pada bidang kontrol Route 53 `us-east-1` untuk membuat, memperbarui, atau menghapus DNS catatan, zona yang dihosting, dan/atau membuat pemeriksaan kesehatan Route 53. Daftar ini tidak lengkap; ini dimaksudkan untuk menyoroti beberapa layanan yang paling umum digunakan yang tindakan bidang kontrolnya untuk membuat, memperbarui, atau menghapus sumber daya bergantung pada bidang kontrol Route 53: + Amazon API Gateway REST dan HTTP APIs + RDSContoh Amazon + Basis data Amazon Aurora + Penyeimbang ELB beban Amazon + Titik akhir AWS PrivateLink VPC + AWS Lambda URLs + Amazon ElastiCache + OpenSearch Layanan Amazon + Amazon CloudFront + Amazon MemoryDB + Amazon Neptune + Akselerator Amazon DynamoDB () DAX + AGA + Amazon Elastic Container Service (AmazonECS) dengan Service Discovery DNS berbasis (yang menggunakan AWS Cloud Map API untuk mengelola Route 53DNS) + Pesawat kontrol Amazon EKS Kubernetes Penting untuk dicatat bahwa VPC DNS layanan [EC2misalnya nama host](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html) ada secara independen di masing-masing Wilayah AWS dan tidak bergantung pada bidang kontrol Route 53. Catatan yang AWS dibuat untuk EC2 instance dalam VPC DNS layanan, seperti,`ip-10-0-10.ec2.internal`,`ip-10-0-1-5.compute.us-west-2.compute.internal`, dan `i-0123456789abcdef.ec2.internal``i-0123456789abcdef.us-west-2.compute.internal`, tidak bergantung pada bidang kontrol Route 53 di`us-east-1`. ****Rekomendasi**** Jangan mengandalkan pembuatan, pembaruan, atau penghapusan sumber daya yang memerlukan pembuatan, pembaruan, atau penghapusan catatan sumber daya Route 53, zona yang dihosting, atau pemeriksaan kesehatan di jalur pemulihan Anda. Pra-penyediaan sumber daya ini, sepertiELBs, untuk mencegah ketergantungan pada bidang kontrol Route 53 di jalur pemulihan Anda. + **Amazon S3** Operasi bidang kontrol Amazon S3 berikut memiliki ketergantungan mendasar `us-east-1` pada partisi. `aws` Kegagalan yang memengaruhi Amazon S3 atau layanan `us-east-1` lain dapat menyebabkan tindakan pesawat kontrol ini terganggu di Wilayah lain: ``` PutBucketCors DeleteBucketCors PutAccelerateConfiguration PutBucketRequestPayment PutBucketObjectLockConfiguration PutBucketTagging DeleteBucketTagging PutBucketReplication DeleteBucketReplication PutBucketEncryption DeleteBucketEncryption PutBucketLifecycle DeleteBucketLifecycle PutBucketNotification PutBucketLogging DeleteBucketLogging PutBucketVersioning PutBucketPolicy DeleteBucketPolicy PutBucketOwnershipControls DeleteBucketOwnershipControls PutBucketAcl PutBucketPublicAccessBlock DeleteBucketPublicAccessBlock ``` Bidang kontrol untuk Amazon S3 Multi-Region Access Points (MRAP) [hanya di-host `us-west-2`](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MrapOperations.html) dan meminta untuk membuat, memperbarui, atau menghapus MRAPs target Wilayah tersebut secara langsung. Bidang kontrol untuk MRAP juga memiliki dependensi mendasar pada AGA in`us-west-2`, Route 53 in`us-east-1`, dan ACM di setiap Wilayah tempat MRAP dikonfigurasi untuk menyajikan konten. Anda tidak boleh bergantung pada ketersediaan pesawat MRAP kontrol di jalur pemulihan Anda atau di pesawat data sistem Anda sendiri. Ini berbeda dari [kontrol MRAP failover](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MrapFailover.html) yang digunakan untuk menentukan status perutean aktif atau pasif untuk setiap bucket Anda di. MRAP Ini APIs di-host dalam [lima Wilayah AWS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MrapOperations.html#update-mrap-route-configuration) dan dapat digunakan untuk secara efektif mengalihkan lalu lintas menggunakan pesawat data layanan. Selain itu, [nama bucket Amazon S3 unik secara global](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html) dan semua panggilan ke `CreateBucket` dan `DeleteBucket` APIs bergantung pada`us-east-1`, di `aws` partisi, untuk memastikan keunikan nama, meskipun API panggilan diarahkan ke Wilayah tertentu tempat Anda ingin membuat bucket. Terakhir, jika Anda memiliki alur kerja pembuatan bucket yang penting, Anda tidak boleh bergantung pada ketersediaan ejaan tertentu dari nama bucket, terutama yang mengikuti pola yang terlihat. ****Rekomendasi**** Jangan mengandalkan menghapus atau membuat bucket S3 baru atau memperbarui konfigurasi bucket S3 sebagai bagian dari jalur pemulihan Anda. Pra-penyediaan semua bucket S3 yang diperlukan dengan konfigurasi yang diperlukan sehingga Anda tidak perlu melakukan perubahan untuk pulih dari kegagalan. Pendekatan ini juga berlaku untukMRAPs. + **CloudFront** Amazon API Gateway menyediakan titik akhir yang [dioptimalkan tepi API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-endpoint-types.html#api-gateway-api-endpoint-types-edge-optimized). Membuat titik akhir ini bergantung pada bidang CloudFront kontrol `us-east-1` untuk membuat distribusi di depan titik akhir gateway. ****Rekomendasi**** Jangan mengandalkan pembuatan titik akhir API Gateway baru yang dioptimalkan tepi sebagai bagian dari jalur pemulihan Anda. Pra-penyediaan semua titik akhir API Gateway yang diperlukan. Semua dependensi yang dibahas di bagian ini adalah tindakan bidang kontrol, bukan tindakan bidang data. Jika beban kerja Anda dikonfigurasi agar stabil secara statis, dependensi ini seharusnya tidak memengaruhi jalur pemulihan Anda, dengan mengingat bahwa stabilitas statis memerlukan pekerjaan atau layanan tambahan untuk diterapkan. ## Layanan yang menggunakan endpoint global default Dalam beberapa kasus, AWS layanan menyediakan titik akhir global default, seperti AWS Security Token Service ([AWS STS](https://docs.aws.amazon.com/general/latest/gr/sts.html)). Layanan lain mungkin menggunakan titik akhir global default ini dalam konfigurasi defaultnya. Ini berarti bahwa layanan Regional yang Anda gunakan dapat memiliki ketergantungan global pada satu Wilayah AWS. Rincian berikut menjelaskan cara menghapus dependensi yang tidak diinginkan pada endpoint global default yang akan membantu Anda menggunakan layanan dengan cara Regional. **AWS STS:** STS adalah layanan web yang memungkinkan Anda untuk meminta kredensi hak istimewa terbatas sementara untuk IAM pengguna atau untuk pengguna yang Anda autentikasi (pengguna gabungan). STSpenggunaan dari kit pengembangan AWS perangkat lunak (SDK) dan antarmuka baris perintah (CLI) default ke. `us-east-1` STSLayanan ini juga menyediakan titik akhir Regional. Titik akhir ini diaktifkan secara default di Wilayah yang juga diaktifkan secara default. Anda dapat memanfaatkan ini kapan saja dengan mengonfigurasi SDK atau CLI mengikuti petunjuk berikut: Titik akhir [AWS STSregional](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html). Menggunakan Sigv4a juga [memerlukan kredensil sementara yang diminta dari titik akhir Regional. STS](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html#signature-versions) Anda tidak dapat menggunakan STS titik akhir global untuk operasi ini. ****Rekomendasi**** Perbarui CLI konfigurasi SDK dan Anda untuk menggunakan STS titik akhir Regional. **Security Assertion Markup Language (SAML) Masuk:** SAML layanan ada di semua. Wilayah AWS Untuk menggunakan layanan ini, pilih SAML titik akhir regional yang sesuai, seperti [https://us-west-2.signin.aws.amazon.com/saml.](https://us-west-2.signin.aws.amazon.com/saml) Anda harus memperbarui konfigurasi dalam kebijakan kepercayaan dan Penyedia Identitas (iDP) Anda untuk menggunakan titik akhir regional. Lihat [AWS SAMLdokumentasi](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html) untuk detail spesifik. Jika Anda menggunakan IDP yang juga di-host AWS, ada risiko bahwa mereka juga dapat terpengaruh selama peristiwa AWS kegagalan. Hal ini dapat mengakibatkan Anda tidak dapat memperbarui konfigurasi IDP Anda atau Anda mungkin tidak dapat melakukan federasi sepenuhnya. Anda harus menyediakan terlebih dahulu pengguna “break-glass” jika IDP Anda rusak atau tidak tersedia. Lihat detail tentang cara membuat pengguna break-glass dengan cara yang stabil secara statis. [Lampiran A - Panduan layanan partisi](appendix-a---partitional-service-guidance.md) ****Rekomendasi**** Perbarui kebijakan kepercayaan IAM peran Anda untuk menerima SAML login dari beberapa Wilayah. Selama kegagalan, perbarui konfigurasi IDP Anda untuk menggunakan SAML titik akhir Regional yang berbeda jika titik akhir pilihan Anda terganggu. Buat pengguna break-glass jika IDP Anda rusak atau tidak tersedia. **AWS IAMPusat Identitas:** Identity Center adalah layanan berbasis cloud yang memudahkan pengelolaan akses masuk tunggal ke aplikasi pelanggan dan cloud secara terpusat. Akun AWS Pusat Identitas harus digunakan di satu Wilayah pilihan Anda. Namun, perilaku default untuk layanan ini adalah menggunakan SAML titik akhir global ([https://signin.aws.amazon.com/saml](https://signin.aws.amazon.com/saml)), yang di-host di`us-east-1`. Jika Anda telah menerapkan Pusat Identitas ke dalam yang berbeda Wilayah AWS, Anda harus memperbarui [status relai](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtopermrelaystate.html) URL dari setiap izin yang ditetapkan untuk menargetkan titik akhir konsol Regional yang sama dengan penerapan Pusat Identitas Anda. [Misalnya, jika Anda menerapkan Pusat Identitas ke dalam`us-west-2`, Anda harus memperbarui status relaystate dari set izin Anda untuk menggunakan https://us-west-2.console.aws.amazon.com.](https://us-west-2.console.aws.amazon.com) Ini akan menghapus ketergantungan apa pun `us-east-1` dari penyebaran Pusat Identitas Anda. Selain itu, karena Pusat IAM Identitas hanya dapat diterapkan ke dalam satu Wilayah, Anda harus menyediakan pengguna “break-glass” terlebih dahulu jika penerapan Anda terganggu. Lihat detail tentang cara membuat pengguna break-glass dengan cara yang stabil secara statis. [Lampiran A - Panduan layanan partisi](appendix-a---partitional-service-guidance.md) ****Rekomendasi**** Setel status relaystate URL dari set izin Anda di Pusat IAM Identitas agar sesuai dengan Wilayah tempat Anda memiliki layanan yang digunakan. Buat pengguna break-glass jika penyebaran Pusat IAM Identitas Anda tidak tersedia. Lensa Penyimpanan **Amazon S3: Lensa Penyimpanan** menyediakan dasbor default yang disebut. default-account-dashboard Konfigurasi dasbor dan metrik terkait disimpan di`us-east-1`. Anda dapat membuat dasbor tambahan di Wilayah lain dengan menentukan [Wilayah beranda](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage_lens_basics_metrics_recommendations.html#storage_lens_basics_home_region) untuk konfigurasi dasbor dan data metrik. ****Rekomendasi**** Jika Anda memerlukan data dari dasbor Lensa Penyimpanan S3 default selama kegagalan yang memengaruhi layanan`us-east-1`, buat dasbor tambahan di Wilayah rumah alternatif. Anda juga dapat menduplikasi dasbor khusus lainnya yang telah Anda buat di Wilayah tambahan. ## Ringkasan layanan global Pesawat data untuk layanan global menerapkan prinsip isolasi dan independensi yang serupa dengan AWS layanan Regional. Kegagalan yang memengaruhi bidang data IAM di Wilayah tidak memengaruhi pengoperasian bidang IAM data di wilayah lain Wilayah AWS. Demikian pula, kegagalan yang memengaruhi bidang data Route 53 di PoP tidak memengaruhi pengoperasian bidang data Route 53 di bagian PoPs lainnya. Oleh karena itu, yang harus kita pertimbangkan adalah peristiwa ketersediaan layanan yang mempengaruhi Wilayah tempat pesawat kontrol beroperasi atau mempengaruhi bidang kontrol itu sendiri. Karena hanya ada satu bidang kontrol untuk setiap layanan global, kegagalan yang mempengaruhi bidang kontrol itu dapat memiliki efek lintas wilayah pada operasi CRUDL -type (yang merupakan operasi konfigurasi yang biasanya digunakan untuk mengatur atau mengkonfigurasi layanan sebagai lawan dari penggunaan langsung layanan). Cara paling efektif untuk merancang beban kerja untuk menggunakan layanan global secara tangguh adalah dengan menggunakan stabilitas statis. Selama skenario kegagalan, rancang beban kerja Anda agar tidak perlu melakukan perubahan dengan bidang kontrol untuk mengurangi dampak atau kegagalan ke lokasi yang berbeda. Lihat [Lampiran A - Panduan layanan partisi](appendix-a---partitional-service-guidance.md) dan [Lampiran B - Panduan layanan global jaringan Edge](appendix-b---edge-network-global-service-guidance.md) untuk panduan preskriptif tentang cara memanfaatkan jenis layanan global ini untuk menghilangkan dependensi bidang kontrol dan menghilangkan satu titik kegagalan. Jika Anda memerlukan data dari operasi bidang kontrol untuk pemulihan, cache data ini di penyimpanan data yang dapat diakses melalui bidang datanya, seperti parameter [AWS Systems Manager](https://aws.amazon.com/systems-manager/) Parameter Store (SSMParameter Store), tabel DynamoDB, atau bucket S3. Untuk redundansi, Anda juga dapat memilih untuk menyimpan data tersebut di Wilayah tambahan. Misalnya, mengikuti [praktik terbaik](https://docs.aws.amazon.com/r53recovery/latest/dg/route53-arc-best-practices.html) untuk Route 53 Application Recovery Controller (ARC), Anda harus membuat hardcode atau menandai lima titik akhir cluster Regional Anda. Selama peristiwa kegagalan, Anda mungkin tidak dapat mengakses beberapa API operasi, termasuk operasi Route 53 ARC API yang tidak dihosting di cluster pesawat data yang sangat andal. Anda dapat membuat daftar titik akhir untuk ARC cluster Route 53 Anda dengan menggunakan operasi. `DescribeCluster` API Berikut ini adalah ringkasan dari beberapa kesalahan konfigurasi atau anti-pola yang paling umum yang memperkenalkan dependensi pada bidang kontrol layanan global: + Membuat perubahan pada rekaman Route 53, seperti memperbarui nilai catatan A atau mengubah bobot set rekaman tertimbang, untuk melakukan failover. + Membuat atau memperbarui IAM sumber daya, termasuk IAM peran dan kebijakan, selama kegagalan. Ini biasanya tidak disengaja, tetapi mungkin merupakan hasil dari rencana failover yang belum teruji. + Mengandalkan Pusat IAM Identitas bagi operator untuk mendapatkan akses ke lingkungan produksi selama peristiwa kegagalan. + Mengandalkan konfigurasi Pusat IAM Identitas default untuk memanfaatkan konsol `us-east-1` saat Anda telah menerapkan Pusat Identitas ke Wilayah lain. + Membuat perubahan pada bobot panggilan AGA lalu lintas untuk melakukan failover Regional secara manual. + Memperbarui konfigurasi asal CloudFront distribusi agar gagal menjauh dari asal yang terganggu. + Penyediaan sumber daya pemulihan bencana (DR), suka ELBs dan RDS contoh selama peristiwa kegagalan, yang bergantung pada pembuatan DNS catatan di Route 53. Berikut ini adalah ringkasan dari rekomendasi yang diberikan di bagian ini untuk menggunakan layanan global dengan cara yang tangguh yang akan membantu mencegah anti-pola umum sebelumnya. ****Ringkasan rekomendasi**** Jangan mengandalkan bidang kontrol layanan partisi di jalur pemulihan Anda. Sebaliknya, andalkan operasi pesawat data dari layanan ini. Lihat [Lampiran A - Panduan layanan partisi](appendix-a---partitional-service-guidance.md) untuk detail tambahan tentang bagaimana Anda harus merancang untuk layanan partisi. Jangan mengandalkan bidang kontrol layanan jaringan tepi di jalur pemulihan Anda. Sebaliknya, andalkan operasi pesawat data dari layanan ini. Lihat [Lampiran B - Panduan layanan global jaringan Edge](appendix-b---edge-network-global-service-guidance.md) untuk detail tambahan tentang cara merancang layanan global di jaringan edge. Jangan mengandalkan pembuatan, pembaruan, atau penghapusan sumber daya yang memerlukan pembuatan, pembaruan, atau penghapusan catatan sumber daya Route 53, zona yang dihosting, atau pemeriksaan kesehatan di jalur pemulihan Anda. Pra-penyediaan sumber daya ini, sepertiELBs, untuk mencegah ketergantungan pada bidang kontrol Route 53 di jalur pemulihan Anda. Jangan mengandalkan menghapus atau membuat bucket S3 baru atau memperbarui konfigurasi bucket S3 sebagai bagian dari jalur pemulihan Anda. Pra-penyediaan semua bucket S3 yang diperlukan dengan konfigurasi yang diperlukan sehingga Anda tidak perlu melakukan perubahan untuk pulih dari kegagalan. Pendekatan ini juga berlaku untukMRAPs. Jangan mengandalkan pembuatan titik akhir API Gateway baru yang dioptimalkan tepi sebagai bagian dari jalur pemulihan Anda. Pra-penyediaan semua titik akhir API Gateway yang diperlukan. Perbarui CLI konfigurasi SDK dan Anda untuk menggunakan STS titik akhir Regional. Perbarui kebijakan kepercayaan IAM peran Anda untuk menerima SAML login dari beberapa Wilayah. Selama kegagalan, perbarui konfigurasi IDP Anda untuk menggunakan SAML titik akhir Regional yang berbeda jika titik akhir pilihan Anda terganggu. Buat pengguna break-glass jika IDP Anda rusak atau tidak tersedia. Setel status relaystate URL dari set izin Anda di Pusat IAM Identitas agar sesuai dengan Wilayah tempat Anda memiliki layanan yang digunakan. Buat pengguna break-glass jika penyebaran Pusat Identitas Anda tidak tersedia. Jika Anda memerlukan data dari dasbor Lensa Penyimpanan S3 default selama kegagalan yang memengaruhi layanan`us-east-1`, buat dasbor tambahan di Wilayah rumah alternatif. Anda juga dapat menduplikasi dasbor khusus lainnya yang telah Anda buat di Wilayah tambahan.