本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# AWS 服務類型
AWS 根據故障隔離邊界來運作三種不同類別的服務：區域、區域和全球。本節將更詳細地說明這些不同類型的服務的設計方式，以便您可以判斷特定服務類型的服務中的故障將如何影響執行的工作負載 AWS。它還提供了如何架構工作負載以彈性方式使用這些服務的高層級指導。對於全球服務，本文件也在中[附錄 A-部分服務指引](appendix-a---partitional-service-guidance.md)提供規範性指引，[附錄 B-邊緣網路全球服務指南](appendix-b---edge-network-global-service-guidance.md)可協助您避免服務中的控制平面損傷對工作負載造成影響，協助您安全地採取全域 AWS 服務的相依性，同時將單點故障引入降到最低。
**Topics**
+ [區域服務](zonal-services.md)
+ [區域服務](regional-services.md)
+ [全球服務](global-services.md)
# 區域服務
[https://aws.amazon.com/builders-library/static-stability-using-availability-zones/](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)（AZI）可 AWS 以提供區域服務，如 Amazon EC2 和 Amazon EBS。區域服務是提供指定資源部署到哪個可用區域的能力的服務。這些服務在一個區域內的每個可用區域獨立運作，更重要的是，在每個可用區域也會獨立失敗。這表示一個可用區域中的服務元件不會取得其他可用區域中元件的相依性。我們可以這樣做是因為區域服務具有**區域資料平**面。在某些情況下 (例如與)EC2，此服務也包含區域對齊作業的區域控制平面，例如啟動執行個EC2體。對於這些服務， AWS 還提供區域控制平面端點，以便於與服務互動。區域控制平面還提供區域範圍的功能，以及作為區域控制平面頂部的聚合和路由層。這顯示在下圖中。
![\[此影像顯示具有區域隔離控制平面和資料平面的區域服務\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/aws-fault-isolation-boundaries/images/a-zonal-service-with-zonally-isolated-control-planes-and-data-planes.png)
可用區域讓客戶能夠操作比單一資料中心更具高可用性、容錯能力和可擴充性的生產工作負載。當工作負載使用多個可用區域時，客戶可以更好地隔離並避免影響單一可用區域實體基礎架構的問題。這有助於客戶建置跨可用區域備援的服務，如果架構正確，即使一個可用區域發生故障，仍可保持運作。客戶可以利用建立高可用性和彈性的AZI工作負載。AZI在您的架構中實作可協助您從隔離的可用區域故障中快速復原，因為您在一個可用區域中的資源可最小化或消除與其他可用區域中的資源互動。這有助於移除跨可用區域相依性，進而簡化可用區域疏散。如需建立可用區域撤離機制的詳細資訊，請參閱[進階異地同步備份復原模式](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/advanced-multi-az-resilience-patterns.html)。此外，您還可以遵循其自身服務 AWS 使用的一些相同的最佳作法，例如一次只將變更部署到單一可用區域，或者在可用區域中發生嚴重變更時，從服務中移除可用區域，以進一步利用可用區域。
[靜態穩定性](static-stability.md)也是多可用區域架構的重要概念。您應該規劃使用多可用區域架構的故障模式之一是可用區域遺失，這可能會導致可用區域的容量損失。如果您沒有預先佈建足夠的容量來處理可用區域的損失，這可能會導致剩餘的容量因目前的負載而不堪重負。此外，您將需要依賴用於替換損失容量的區域服務的控制平面，與靜態穩定的設計相比，可靠性較低。在這種情況下，預先佈建足夠的額外容量可協助您在不需要動態變更的情況下繼續正常作業，讓您在遺失容錯網域 (例如可用區域) 時保持靜態穩定。
您可以選擇使用跨多個可用區域部署的 auto 動調整EC2執行個體群組，根據工作負載的需求動態擴展和擴展。自動縮放功能適用於在數分鐘到數十分鐘內逐漸變化的使用情況。不過，啟動新EC2執行個體需要時間，尤其是在執行個體需要啟動載入時 (例如安裝代理程式、應用程式二進位檔案或設定檔)。在此期間，您剩餘的容量可能會因目前的負載而不堪重負。此外，透過 auto 擴展部署新的執行個體也依賴於EC2控制平面。這提供了一個權衡：為了在單一可用區域遺失時保持靜態穩定，您需要在其他可用區域預先佈建足夠的EC2執行個體，以處理已從受損可用區域移開的負載，而不是依賴 auto 擴展佈建新執行個體。不過，預先佈建額外容量可能會產生額外費用。
例如，在正常操作期間，假設您的工作負載需要六個執行個體來服務跨三個可用區域的客戶流量。為了在單一可用區域故障時保持靜態穩定，您需要在每個可用區域部署三個執行個體，總共九個執行個體。如果單一可用區域值的執行個體失敗，您仍然可以剩下六個，並且能夠繼續為客戶流量提供服務，而無需在故障期間佈建和設定新的執行個體。實現EC2容量的靜態穩定性需要額外的費用，因為在這種情況下，您執行的是額外 50% 的執行個體。並非所有可預先佈建資源的服務都會產生額外費用，例如預先佈建 S3 儲存貯體或使用者。您將需要權衡實施靜態穩定性的任何權衡，以免超過工作負載所需的復原時間的風險。
AWS Local Zones 和 Outposts 使特定 AWS 服務的數據平面更接近最終用戶。這些服務的控制平面位於父區域中。您的本地區域或 Outposts 實例將具有區域服務的控制平面依賴關係，例如EC2EBS在您創建本地區域或 Outposts 子網路的可用區域服務。他們也會依賴區域服務的區域控制平面，例如 Elastic Load Balancing (ELB)、安全群組和 Amazon Elastic Kubernetes Service ([Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/local-zones.html)) 受管 Kubernetes 控制平面 (如果您使用)。EKS有關 Outposts 的其他特定信息，請參閱[文檔](https://docs.aws.amazon.com/outposts/latest/userguide/disaster-recovery-resiliency.html)以及[支持和維護FAQ](https://aws.amazon.com/outposts/rack/faqs/)。使用 Local Zones 或 Outposts 時實現靜態穩定性，以幫助提高控制平面損傷或與父區域的網絡連接中斷的彈性。
# 區域服務
區域服務是 AWS 建立在多個可用區域之上的服務，因此客戶不必弄清楚如何充分利用區域服務。我們以邏輯方式將跨多個可用區域部署的服務組合在一起，向客戶呈現單一區域端點。Amazon SQS 和亞[馬遜 DynamoDB](https://aws.amazon.com/dynamodb/) 是區域服務的示例。他們使用可用區域的獨立性和備援，將基礎設施故障降到最低，因為可用性和耐久性風險。例如，Amazon S3 將請求和資料分散到多個可用區域，其設計目的是從可用區域的故障中自動復原。不過，您只能與服務的區域端點互動。
AWS 相信大多數客戶可以使用依賴區域服務的區域服務或異地同步備份架構，在單一區域實現其彈性目標。不過，某些工作負載可能需要額外的備援，而且您可以使用的隔離 AWS 區域 來建立多區域架構以達到 HA 或業務持續性目的。物理和邏輯之間的分離 AWS 區域 避免了它們之間的相關故障。換句話說，類似於您是EC2客戶，並且可以通過在其中部署可用區域來隔離中受益，您可以通過跨多個區域部署來獲得相同的區域服務優勢。這需要您為應用程式實作多區域架構，以協助您抵禦區域服務的損害。
不過，實現多區域架構的優點可能很困難；要利用區域隔離，而不是在應用程式層級撤銷任何事情，需要仔細的工作。例如，如果您要在區域之間容錯移轉應用程式，則需要在每個區域中的應用程式堆疊之間保持嚴格的區隔、注意所有應用程式相依性，並將應用程式的所有部分一起容錯移轉。透過複雜的微服務架構實現這一目標，該架構在應用程式之間具有許多相依性，需要在許多工程和業務團隊之間進行規劃和協調。允許個別工作負載做出自己的容錯移轉決策，使協調不那麼複雜，但是透過與單一區域內部相比，跨區域發生的延遲顯著差異來引入模態行為。
AWS 目前不提供同步跨區域複寫功能。跨區域使用非同步複寫的資料存放區 (由提供 AWS) 時，當您在區域之間容錯移轉應用程式時，可能會遺失資料或不一致。為了減少可能出現的不一致情況，您需要一個可靠的資料對帳程序，讓您有信心且可能需要在整個工作負載產品組合的多個資料存放區上進行操作，否則您必須願意接受資料遺失。最後，您需要練習容錯移轉，以便知道它可以在您需要時運作。在區域之間定期輪換您的應用程式以實踐容錯移轉是一項大量的時間和資源投資 如果您決定跨區域使用同步複寫的資料存放區來支援從多個區域同時執行的應用程式，則此類跨越 100 或 1000 英哩的資料庫的效能特性和延遲與在單一區域中運作的資料庫有很大的不同。這需要您從頭開始計劃應用程序堆棧以解釋此行為。這也會讓兩個區域的可用性成為硬性相依性，因此可能會降低工作負載的彈性。
# 全球服務
除了區域和區域 AWS 服務外，還有一小組服 AWS 務，其控制平面和資料平面在每個區域中並不獨立存在。*由於它們的資源不是特定於區域的，因此通常稱為全域資源。*為了實現靜態穩定性，全球 AWS 服務仍然遵循分離控制平面和數據平面的傳統 AWS 設計模式。大多數全球服務的顯著差異在於它們的控制平面託管在一個*單*一的 AWS 區域，而資料平面則是全球分佈的。根據您選取的組態，有三種不同類型的全域服務和一組服務可能會顯示為全域。
以下各節將識別每種類型的全域服務，以及它們的控制平面和資料平面是如何分離的。您可以使用此資訊來指導如何建置可靠的高可用性 (HA) 和災難復原 (DR) 機制，而不需要依賴全域服務控制平面。這種方法有助於移除架構中的單一故障點，並避免潛在的跨區域影響，即使您所在的區域與託管全域服務控制平面的地方不同。它也可協助您安全地實作不依賴全域服務控制平面的容錯移轉機制。
## 依分割區獨一無二的全域服務
某些全域 AWS 服務存在於每個分割區中 (在本 paper 中稱為*部分*服務)。分區服務在一個單 AWS 區域一的提供他們的控制平面。某些部分服務 (例如 AWS 網路管理員) 僅限控制平面，並協調其他服務的資料平面。其他部分服務 (例如) 都有自己的資料平面IAM，這些資料平面會隔離並散佈在分割區 AWS 區域 中的所有資料平面。分區服務中的故障不會影響其他磁碟分割。在`aws`分割區中，IAM服務的控制平面位於「`us-east-1`區域」中，分割區的每個區域都有隔離的資料平面。分割服務在和`aws-cn`分割區中也有獨立的控制平面`aws-us-gov`和資料平面。的控制平面和數據平面的分IAM離示於下圖中。
![\[此影像說明了IAM具有單一控制平面和區域化資料平面\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/aws-fault-isolation-boundaries/images/iam-single-control-plane-and-regionalized-data-plane.png)
以下是分割服務及其控制平面在`aws`分割區中的位置：
+ AWS IAM (`us-east-1`)
+ AWS Organizations (`us-east-1`)
+ AWS 帳戶管理 (`us-east-1`)
+ Route 53 應用程序恢復控制器（ARC`us-west-2`）（）-此服務僅存在於`aws`分區中
+ AWS 網路管理員 (`us-west-2`)
+ 53 號私人路線DNS（`us-east-1`）
如果任何這些服務控制平面有可用性影響的事件，您可能無法使用這些服務提供的CRUDL類型操作。因此，如果您的復原策略依賴於這些作業，則對控制平面或託管控制平面的區域產生可用性影響，將減少您成功復原的機會。 [附錄 A-部分服務指引](appendix-a---partitional-service-guidance.md)提供在復原期間移除全域服務控制平面相依性的策略。
****建議****
請勿在復原路徑中依賴部分服務的控制平面。而是仰賴這些服務的資料平面作業。如需有[附錄 A-部分服務指引](appendix-a---partitional-service-guidance.md)關如何設計分區服務的其他詳細資訊，請參閱。
## 邊緣網路中的全球服務
下一組全域 AWS 服務在`aws`分割區中有一個控制平面，並將其資料平面託管在全域[存在點](points-of-presence.md) (PoP) 基礎結構 (也可能也是 AWS 區域 如此)。託管在的數據平面 PoPs 可以從任何分區以及互聯網的資源訪問。例如，Route 53 在`us-east-1`區域中運行其控制平面，但其數據平面分佈在 PoPs 全球數百個以及每個 AWS 區域 （以支持區域DNS內的 Route 53 公共和私有）。Route 53 健康狀態檢查也是資料平面的一部分，並從`aws`分割區 AWS 區域 中的八個執行。客戶可以從互聯網上的任何地方DNS使用 Route 53 公共託管區域進行解決 GovCloud，包括其他分區，例如，以及從 AWS 虛擬私有雲（VPC）。以下是全域邊緣網路服務及其在`aws`分割區中的控制平面位置：
+ 53 號幹線公眾 DNS (`us-east-1`)
+ Amazon CloudFront （`us-east-1`）
+ AWS WAF 經典的 CloudFront （`us-east-1`）
+ AWS WAF 為 CloudFront （`us-east-1`）
+ Amazon Certific ACM ate Manager CloudFront （`us-east-1`）
+ AWS全域加速器 (AGA) (`us-west-2`)
+ AWS Shield Advanced (`us-east-1`)
如果您對EC2執行個體或彈性 IP 地址使用AGA健康狀態檢查，這些檢查會使用 Route 53 運作狀態檢 建立或更新AGA健康狀態檢查將取決於中的 Route 53 控制平面`us-east-1`。執行AGA健康檢查會利用 Route 53 健康狀態檢查資料平面。
在影響託管這些服務的控制平面的區域的故障，或影響控制平面本身的故障期間，您可能無法使用這些服務提供的CRUDL類型操作。如果您已在復原策略中對這些作業採取相依性，則該策略成功的可能性可能會比僅依賴這些服務的資料平面來得低。
****建議****
請勿依賴復原路徑中邊緣網路服務的控制平面。而是仰賴這些服務的資料平面作業。如需有[附錄 B-邊緣網路全球服務指南](appendix-b---edge-network-global-service-guidance.md)關如何在邊緣網路中設計全球服務的其他詳細資訊，請參閱。
## 全球單一區域營運
最終類別是由具有全域影響範圍的服務內的特定控制平面作業組成，而不是像先前類別那樣的整個服務。當您與所指定區域中的區域和區域服務互動時，某些作業會對單一區域具有與資源所在位置不同的基礎相依性。這些與僅在單一區域中提供的服務不同；如需這些服務[附錄 C-單一區域服務](appendix-c---single-region-services.md)的清單，請參閱。
在影響基礎全域相依性的失敗期間，您可能無法使用相依作業的CRUDL類型動作。如果您已在復原策略中對這些作業採取相依性，則該策略成功的可能性可能會比僅依賴這些服務的資料平面來得低。針對復原策略，您應該避免與這些作業相依性。
以下是其他服務可能依賴的服務列表，這些服務具有全局範圍：
+ **53 號幹線**
有數個 AWS 服務會建立提供資源特定DNS名稱的資源。例如，當您佈建 Elastic Load Balancer (ELB) 時，服務會在 Route 53 中為ELB. DNS 這取決於中的 Route 53 控制平面`us-east-1`。您使用的其他服務也可能需要佈建ELB、建立公用 Route 53 DNS 記錄，或建立 Route 53 健康狀態檢查，做為其控制平面工作流程的一部分。例如，佈建 Amazon API 閘道RESTAPI資源、Amazon Relational Database Service (AmazonRDS) 資料庫或 Amazon OpenSearch 服務網域，都會在 Route 53 中建立DNS記錄。以下是其控制平面依賴於中的 Route 53 控制平面`us-east-1`來建立、更新或刪除DNS記錄、託管區域和/或建立 Route 53 健康狀態檢查的服務清單。此清單並非詳盡無遺；它的目的是強調一些最常用的服務，其建立、更新或刪除資源的控制平面動作取決於 Route 53 控制平面：
+ Amazon API 網關REST和 HTTP APIs
+ Amazon RDS 實例
+ Amazon Aurora 資料
+ Amazon ELB 負載平衡器
+ AWS PrivateLink VPC端點
+ AWS Lambda URLs
+ Amazon ElastiCache
+ Amazon OpenSearch 服務
+ Amazon CloudFront
+ Amazon MemoryDB
+ Amazon Neptune
+ Amazon DynamoDB 加速器 () DAX
+ AGA
+ Amazon 彈性容器服務（AmazonECS）與DNS基於服務發現（使 AWS Cloud Map API用管理路線 53DNS）
+ Amazon EKS 控制平面
請務必注意，[EC2執行個體主機名稱的VPCDNS服務獨立存在於每個主](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html)機名稱中， AWS 區域 並不依賴於 Route 53 控制平面。為VPCDNS服務中的EC2執行個體 AWS 建立的記錄 (例如`ip-10-0-10.ec2.internal``ip-10-0-1-5.compute.us-west-2.compute.internal``i-0123456789abcdef.ec2.internal`、`i-0123456789abcdef.us-west-2.compute.internal`、和) 不依賴中的 Route 53 控制平面`us-east-1`。
****建議****
請勿依賴建立、更新或刪除需要在復原路徑中建立、更新或刪除 Route 53 資源記錄、託管區域或健康狀態檢查的資源。預先佈建這些資源，例如ELBs，以防止依賴於復原路徑中的 Route 53 控制平面。
+ **Amazon Simple Storage Service (Amazon S3)**
下列 Amazon S3 控制平面操作在`aws`分割區`us-east-1`中具有基礎相依性。影響 Amazon S3 或其他服務的故障`us-east-1`可能會導致其他區域的這些控制平面動作受損：
```
PutBucketCors
DeleteBucketCors
PutAccelerateConfiguration
PutBucketRequestPayment
PutBucketObjectLockConfiguration
PutBucketTagging
DeleteBucketTagging
PutBucketReplication
DeleteBucketReplication
PutBucketEncryption
DeleteBucketEncryption
PutBucketLifecycle
DeleteBucketLifecycle
PutBucketNotification
PutBucketLogging
DeleteBucketLogging
PutBucketVersioning
PutBucketPolicy
DeleteBucketPolicy
PutBucketOwnershipControls
DeleteBucketOwnershipControls
PutBucketAcl
PutBucketPublicAccessBlock
DeleteBucketPublicAccessBlock
```
Amazon S3 多區域存取點 (MRAP) 的控制平面[僅託管在該區域中](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MrapOperations.html)，`us-west-2`並請求直接建立、更新或刪除該區域的MRAPs目標。的控制平面MRAP也具有在AGA中`us-west-2`、Route 53 in `us-east-1` 以及ACM設定為提供內容的每個區域的基礎相依性。MRAP您不應該依賴於復原路徑或自己系統資料層中MRAP控制平面的可用性。這與用於為中的每個值區指定主動或被動路由狀態的[MRAP容錯移轉控制](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MrapFailover.html)不同MRAP。這APIs些託管在[五個](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MrapOperations.html#update-mrap-route-configuration)中 AWS 區域，可用於使用服務的數據平面有效轉移流量。
此外，Amazon S3 儲存[貯體名稱是全域唯](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html)一的`us-east-1`，`DeleteBucket`APIs而`CreateBucket`且所有呼叫都依賴於`aws`分割區中的和，以確保名稱的唯一性，即使API呼叫是針對您要建立儲存貯體的特定區域。最後，如果您有重要的值區建立工作流程，則不應依賴值區名稱的任何特定拼字的可用性，尤其是遵循可辨別模式的拼字。
****建議****
請勿依賴刪除或建立新的 S3 儲存貯體或更新 S3 儲存貯體組態作為復原路徑的一部分。使用必要的組態預先佈建所有必要的 S3 儲存貯體，這樣您就不需要進行變更即可從故障中復原。這種方法也適用於。MRAPs
+ **CloudFront**
Amazon API 閘道提供[邊緣優化API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-endpoint-types.html#api-gateway-api-endpoint-types-edge-optimized)端點。建立這些端點取決於中的 CloudFront控制平面，`us-east-1`以便在閘道端點前面建立發佈。
****建議****
請勿依賴建立新的邊緣最佳化API閘道端點做為復原路徑的一部分。預先佈建所有必要的API閘道端點。
本節中討論的所有相依性都是控制平面動作，而不是資料平面動作。如果您的工作負載設定為靜態穩定，則這些相依性不會影響您的復原路徑，請記住，靜態穩定性需要額外的工作或服務才能實作。
## 使用預設全域端點的服務
在少數情況下， AWS 服務會提供預設的全域端點，例如 AWS 安全性權杖服務 ([AWS STS](https://docs.aws.amazon.com/general/latest/gr/sts.html))。其他服務可能會在其預設組態中使用此預設全域端點。這意味著您正在使用的區域服務可能對單個服務具有全局依賴性 AWS 區域。下列詳細資訊說明如何移除預設全域端點上的意外相依性，以協助您以地區方式使用服務。
**AWS STS:** STS 是一種 Web 服務，可讓您為IAM用戶或您驗證的用戶（聯合用戶）請求臨時的有限權限憑據。STS AWS 軟體開發套件 (SDK) 和命令列介面 (CLI) 的使用預設為`us-east-1`。該STS服務還提供區域端點。依預設，這些端點會在預設啟用的區域中啟用。您可以隨時透過設定SDK或CLI遵循以下指示來利用這些功能：[AWS STS區域化](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html)端點。使用 SigV4a 也[需要從區域端點要求的臨時登入資料](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html#signature-versions)。STS您無法使用全域STS端點進行此作業。
****建議****
更新您的SDK和CLI配置以使用區域STS端點。
**安全斷言標記語言（SAML）登錄：**SAML服務存在於所有 AWS 區域。若要使用此服務，請選擇適當的地區SAML端點，例如 [https://us-west-2.signin.aws.amazon.com/saml](https://us-west-2.signin.aws.amazon.com/saml)。您必須更新信任策略和身分識別提供者 (IdP) 中的組態，才能使用地區端點。如需特定詳細資訊，請參閱[AWS SAML文件](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html)。
如果您使用的是同時託管的 IdP AWS，則在 AWS 失敗事件期間也可能會受到影響。這可能會導致您無法更新 IdP 組態，或者您可能無法完全同盟。如果您的 IdP 受損或無法使用，您應該預先佈建「防碎玻璃」使用者。如需有關如何以[附錄 A-部分服務指引](appendix-a---partitional-service-guidance.md)靜態穩定方式建立破碎玻璃使用者的詳細資訊，請參閱。
****建議****
更新您的IAM角色信任原則，以接受來自多個區域的SAML登入。在失敗期間，如果偏好的端點受損，請更新您的 IdP 組態以使用不同的區域SAML端點。創建一個破碎玻璃用戶（s）的情況下，您的 IdP 受損或不可用。
**AWS IAM身分識別中心：**Identity Center 是一項雲端服務，可讓您輕鬆地集中管理客戶 AWS 帳戶 和雲端應用程式的單一登入存取。身分識別中心必須部署在您選擇的單一區域中。不過，服務的預設行為是使用託管於中的全域SAML端點 ([https://signin.aws.amazon.com/saml](https://signin.aws.amazon.com/saml)) `us-east-1`。如果您已將 Identity Center 部署到其他部署 AWS 區域，則應更新每個權限集URL的[轉送狀態](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtopermrelaystate.html)，以將與 Identity Center 部署相同的地區主控台端點作為目標。[例如，如果您將身分識別中心部署到`us-west-2`，則應將權限集的轉送狀態更新為使用 https://us-west-2.console.aws.amazon.com。](https://us-west-2.console.aws.amazon.com)這會移除身分識別中心部署`us-east-1`中的任何相依性。
此外，由於 IAM Identity Center 只能部署到單一區域，因此您應該預先佈建「防破」使用者，以防部署受損。如需有關如何以[附錄 A-部分服務指引](appendix-a---partitional-service-guidance.md)靜態穩定方式建立破碎玻璃使用者的詳細資訊，請參閱。
****建議****
在 IAM Identity Center 中設定權限集URL的轉送狀態，以符合您部署服務的區域。如果您的IAM身分識別中心部署無法使用，請建立防漏使用者。
**Amazon S3 儲存鏡頭：**儲存鏡頭提供名為的預設儀表板 default-account-dashboard。儀表板組態及其關聯的指標會儲存在中`us-east-1`。您可以指定儀表板組態和指標資料的[主區域，在其他區](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage_lens_basics_metrics_recommendations.html#storage_lens_basics_home_region)域建立其他控制面板。
****建議****
如果在影響服務的故障期間需要來自預設 S3 Storage Lens 儀表板的資料`us-east-1`，請在備用本地區域建立其他儀表板。您也可以複製在其他區域中建立的任何其他自訂儀表板。
## 全球服務摘要
全球服務的資料平面採用與區域 AWS 服務類似的隔離和獨立原則。影響區域中的資料平面IAM的失敗不會影響另一個 AWS 區域區域中IAM資料平面的作業。同樣地，影響 PoP 中 Route 53 資料平面的失敗不會影響路由 53 資料平面在其餘部分的 PoPs操作。因此，我們必須考慮的是服務可用性事件，這些事件會影響控制平面運作或影響控制平面本身的區域。由於每個全域服務只有一個控制平面，因此影響該控制平面的失敗可能會對CRUDL類型作業產生跨區域的影響 (這些作業通常用來設定或設定服務，而非直接使用服務)。
建構工作負載以彈性方式使用全域服務的最有效方法是使用靜態穩定性。在故障情況下，將您的工作負載設計為不需要使用控制平面進行變更，以減輕影響或容錯移轉至不同位置。如需如何利用這些類型的全域服務，以移除控制平面相依性並消除單一故障點的規範性指引，請參閱和。[附錄 A-部分服務指引](appendix-a---partitional-service-guidance.md) [附錄 B-邊緣網路全球服務指南](appendix-b---edge-network-global-service-guidance.md)如果您需要控制平面作業中的資料進行復原，請在可透過其資料平面存取的資料存放區中快取此資料，例如 [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 參數存放區 (SSM參數存放區) 參數、DynamoDB 表或 S3 儲存貯體。對於冗餘，您也可以選擇將該數據存儲在其他區域中。例如，遵循 Route 53 應用程式復原控制器 (ARC) 的[最佳做法](https://docs.aws.amazon.com/r53recovery/latest/dg/route53-arc-best-practices.html)，您應該對五個地區叢集端點進行硬式編碼或書籤。在失敗事件期間，您可能無法存取某些API作業，包括非常可靠的資料平面叢集上裝載的 Route 53 ARC API 作業。您可以使用此`DescribeCluster`API作業列出 Route 53 ARC 叢集的端點。
以下是一些最常見的錯誤配置或反模式的摘要，這些錯誤配置或反模式引入了全局服務的控制平面的依賴關係：
+ 變更 Route 53 記錄，例如更新 A 記錄的值或變更加權記錄集的權重，以執行容錯移轉。
+ 在容錯移轉期間建立或更新IAM資源，包括IAM角色和原則。這通常不是故意的，但可能是未經測試的容錯移轉計劃的結果。
+ 依靠IAM身分識別中心讓操作員在發生故障事件期間取得生產環境的存取權。
+ 當您將IAM身分識別中心部署到不同區域`us-east-1`時，依賴預設的身分識別中心組態來使用中的主控台。
+ 變更AGA流量撥號權重以手動執行區域容錯移轉。
+ 更新 CloudFront 發行版的來源組態，使其無法遠離受損的來源。
+ 在故障事件期間佈建災難復原 (DR) 資源，RDS例如ELBs和執行個體，這些資源取決於在 Route 53 中建立DNS記錄。
以下是本節所提供有助於防止先前常見反模式的彈性方式使用全域服務的建議摘要。
****推薦摘要****
請勿在復原路徑中依賴部分服務的控制平面。而是仰賴這些服務的資料平面作業。如需有[附錄 A-部分服務指引](appendix-a---partitional-service-guidance.md)關如何設計分區服務的其他詳細資訊，請參閱。
請勿依賴復原路徑中邊緣網路服務的控制平面。而是仰賴這些服務的資料平面作業。如需有[附錄 B-邊緣網路全球服務指南](appendix-b---edge-network-global-service-guidance.md)關如何在邊緣網路中設計全球服務的其他詳細資訊，請參閱。
請勿依賴建立、更新或刪除需要在復原路徑中建立、更新或刪除 Route 53 資源記錄、託管區域或健康狀態檢查的資源。預先佈建這些資源，例如ELBs，以防止依賴於復原路徑中的 Route 53 控制平面。
請勿依賴刪除或建立新的 S3 儲存貯體或更新 S3 儲存貯體組態作為復原路徑的一部分。使用必要的組態預先佈建所有必要的 S3 儲存貯體，這樣您就不需要進行變更即可從故障中復原。這種方法也適用於。MRAPs
請勿依賴建立新的邊緣最佳化API閘道端點做為復原路徑的一部分。預先佈建所有必要的API閘道端點。
更新您的SDK和CLI配置以使用區域STS端點。
更新您的IAM角色信任原則，以接受來自多個區域的SAML登入。在失敗期間，如果偏好的端點受損，請更新您的 IdP 組態以使用不同的區域SAML端點。創建破碎玻璃用戶的情況下，您的 IdP 受損或不可用。
在 IAM Identity Center 中設定權限集URL的轉送狀態，以符合您部署服務的區域。如果您的身分識別中心部署無法使用，請建立防漏使用者。
如果在影響服務的故障期間需要來自預設 S3 Storage Lens 儀表板的資料`us-east-1`，請在備用本地區域建立其他儀表板。您也可以複製在其他區域中建立的任何其他自訂儀表板。