本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # AWS 服务类型 AWS 根据故障隔离边界运营三种不同类别的服务：区域性、区域性和全球性。本节将更详细地描述这些不同类型的服务是如何设计的，以便您可以确定特定服务类型的服务中的故障将如何影响您的工作负载 AWS。它还提供了有关如何设计工作负载以弹性方式使用这些服务的高级指导。对于全球服务，本文档还提供了规范性指导[附录 B-边缘网络全球服务指南](appendix-b---edge-network-global-service-guidance.md)，可以帮助您防止服务中的[附录 A-分区服务指南](appendix-a---partitional-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 允许提供区域服务，例如亚马逊EC2和亚马逊EBS。区域服务是指能够指定将资源部署到哪个可用区的服务。这些服务在一个区域内的每个可用区中独立运行，更重要的是，这些服务在每个可用区中也独立失效。这意味着一个可用区中的服务组件不依赖于其他可用区中的组件。我们可以这样做，因为区域服务具有**区域数据平**面。在某些情况下（例如使用）EC2，该服务还包括用于区域对齐操作（例如启动实例EC2）的区域控制平面。对于这些服务， AWS 还提供了区域控制平面终端节点，便于与服务进行交互。区域控制平面还提供区域范围的功能，并充当区域控制平面之上的聚合和路由层。如下图所示。 ![\[此图显示了具有区域隔离控制平面和数据平面的分区服务\]](http://docs.aws.amazon.com/zh_cn/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 Scaling EC2 实例组来动态扩展和缩小。对于在几分钟到几十分钟内逐渐发生的使用量变化，自动缩放效果很好。但是，启动新EC2实例需要时间，尤其是在您的实例需要引导（例如安装代理、应用程序二进制文件或配置文件）的情况下。在此期间，您的剩余容量可能会被当前负载所淹没。此外，通过 auto Scaling 部署新实例依赖于EC2控制平面。这就需要权衡取舍：为了保持静态稳定性，以防单个可用区的丢失，您需要在其他可用区中预置足够的EC2实例来处理已从受损可用区转移的负载，而不是依赖 auto scaling 来配置新实例。但是，预先配置额外容量可能会产生额外费用。 例如，在正常操作期间，假设您的工作负载需要六个实例来为三个可用区的客户流量提供服务。为了在单个可用区出现故障时保持静态稳定，您将在每个可用区部署三个实例，总共部署九个实例。如果单个可用区域的实例出现故障，则还剩下六个实例，并且无需在故障期间预置和配置新实例即可继续为客户流量提供服务。实现EC2容量的静态稳定性需要额外的成本，因为在本例中，您运行的实例数量增加了 50%。并非所有可以预配置资源的服务都会产生额外费用，例如预配置 S3 存储桶或用户。您需要权衡实现静态稳定性与超出工作负载所需恢复时间的风险。 AWS Local Zones 和 Outposts 使特定 AWS 服务的数据平面更接近最终用户。这些服务的控制平面位于父区域。您的本地区域或 Outposts 实例将依赖于区域服务，例如EC2您在其中创建本地区域或 Outposts 子网的可用区。EBS它们还将依赖区域控制平面来提供区域服务，例如Elastic Load Balancing (ELB)、安全组和由亚马逊弹性 Kubernetes Service[（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 多个可用区之上构建的服务，因此客户不必弄清楚如何充分利用区域服务。我们在逻辑上将部署在多个可用区的服务组合在一起，为客户提供单个区域终端节点。亚马逊SQS和[亚马逊 Dynam](https://aws.amazon.com/dynamodb/) oDB 就是区域服务的示例。它们利用可用区域的独立性和冗余性来最大限度地减少基础设施故障，这是可用性和耐久性风险中的一类。例如，Amazon S3 将请求和数据分散到多个可用区，旨在自动从可用区的故障中恢复。但是，您只能与服务的区域终端节点进行交互。 AWS 相信大多数客户可以通过使用依赖区域服务的区域服务或多可用区架构在单个区域实现其弹性目标。但是，某些工作负载可能需要额外的冗余，您可以使用的隔离 AWS 区域 来创建用于高可用性或业务连续性的多区域架构。两者之间的物理和逻辑分离 AWS 区域 避免了它们之间的相关故障。换句话说，与您是EC2客户并可以通过跨可用区部署来从隔离可用区中受益类似，通过跨多个区域进行部署，您也可以获得同样的优势来获得区域服务。这要求您为应用程序实施多区域架构，这可以帮助您抵御区域服务的损害。 但是，实现多区域架构的好处可能很困难；要利用区域隔离，同时又不能在应用程序层面撤消任何东西，需要谨慎行事。例如，如果您要在区域之间对应用程序进行故障切换，则需要在每个区域的应用程序堆栈之间保持严格分离，注意所有应用程序依赖关系，并将应用程序的所有部分一起进行故障转移。使用复杂的、基于微服务的架构实现这一目标，该架构在应用程序之间存在许多依赖关系，需要许多工程和业务团队进行规划和协调。允许单个工作负载自己做出故障转移决策可以降低协调的复杂性，但是由于不同区域之间发生的延迟与单个区域内部的延迟存在显著差异，从而引入了模态行为。 AWS 目前不提供同步跨区域复制功能。使用跨区域异步复制的数据存储库（由提供 AWS）时，当您在区域之间对应用程序进行故障转移时，可能会出现数据丢失或不一致的情况。为了减少可能的不一致性，您需要一个值得信赖的可靠数据协调流程，并且可能需要对工作负载组合中的多个数据存储进行操作，或者您需要愿意接受数据丢失。最后，你需要练习故障转移，才能知道它会在你需要的时候起作用。定期在区域之间轮换应用程序以练习故障转移需要大量的时间和资源投入。如果您决定使用跨区域同步复制的数据存储来支持在多个区域同时运行的应用程序，那么跨越 100 或 1000 英里的此类数据库的性能特征和延迟与在单个区域中运行的数据库有很大不同。这要求您从头开始规划应用程序堆栈，以应对这种行为。它还使两个区域的可用性成为硬性依赖，这可能会导致工作负载的弹性降低。 # 全球服务 除了区域和区域 AWS 服务外，还有一小部分 AWS 服务的控制平面和数据平面不是在每个地区独立存在的。*由于它们的资源不是特定于区域的，因此它们通常被称为全球资源。*全球 AWS 服务仍然遵循传统的 AWS 设计模式，将控制平面和数据平面分开，以实现静态稳定性。大多数全球服务的显著区别在于，它们的控制平面托管在*单个*服务器中 AWS 区域，而其数据平面则是全球分布的。根据您选择的配置，有三种不同的全球服务类型和一组看起来像是全球性的服务。 以下各节将确定每种类型的全球服务以及它们的控制平面和数据平面是如何分开的。您可以使用这些信息来指导如何构建可靠的高可用性 (HA) 和灾难恢复 (DR) 机制，而无需依赖全球服务控制平面。这种方法有助于消除架构中的单点故障，避免潜在的跨区域影响，即使您在与托管全球服务控制平面不同的区域中运营也是如此。它还可以帮助您安全地实现不依赖于全局服务控制平面的故障转移机制。 ## 按分区划分的唯一全球服务 每个分区中都存在一些全局 AWS 服务（本 paper 中称为*分区服务*）。分区服务将其控制平面合而为一 AWS 区域。某些分区服务（例如 AWS Network Manager）仅限控制平面并协调其他服务的数据平面。其他分区服务（例如）有自己的数据平面IAM，该数据平面是隔离的，分布在分区 AWS 区域 中的所有分区中。分区服务中的故障不会影响其他分区。在`aws`分区中，IAM服务的控制平面位于`us-east-1`区域中，分区的每个区域都有隔离的数据平面。分区服务在和`aws-cn`分区中也有独立的控制平面`aws-us-gov`和数据平面。的控制平面和数据平面的分离如下图所示。IAM ![\[此图说明了IAM它具有单个控制平面和区域化数据平面\]](http://docs.aws.amazon.com/zh_cn/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-type 操作。因此，如果您的恢复策略依赖于这些操作，那么对控制平面或托管控制平面的区域的可用性影响将降低成功恢复的机会。 [附录 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内的公共 53 号公路和私有路线）。Route 53 运行状况检查也是数据平面的一部分，从`aws`分区 AWS 区域 中的 8 个开始执行。客户端可以从互联网上的任何地方DNS使用 Route 53 公共托管区域进行解析 GovCloud，包括其他分区，例如 AWS 虚拟私有云 (VPC)。以下是全球边缘网络服务及其在`aws`分区中的控制平面位置： + 53 号公路 DNS (`us-east-1`) + 亚马逊 CloudFront (`us-east-1`) + AWS WAF 经典 fo CloudFront r (`us-east-1`) + AWS WAF 对于 CloudFront (`us-east-1`) + 适用于 (ACM) 的 Amazon Certifice 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-type操作。如果您在恢复策略中依赖这些操作，那么与仅依赖这些服务的数据平面相比，该策略成功的可能性可能要小。 ****建议**** 在恢复路径中，不要依赖边缘网络服务的控制平面。相反，请依赖这些服务的数据平面操作。有关如何在边缘网络中设计全球服务的更多详细信息，请参阅[附录 B-边缘网络全球服务指南](appendix-b---edge-network-global-service-guidance.md)。 ## 全球单一区域运营 最后一个类别由具有全球影响范围的服务中的特定控制平面操作组成，而不是像前面的类别那样由整个服务组成。当您与指定区域中的地区和区域服务进行交互时，某些操作对与资源所在位置不同的单个区域有潜在的依赖关系。这些服务与仅在单个地区提供的服务不同；有关这些服务的列表，请参阅。[附录 C-单区域服务](appendix-c---single-region-services.md) 在影响底层全局依赖关系的故障期间，您可能无法使用依赖操作的 CRUDL-type 操作。如果您在恢复策略中依赖这些操作，那么与仅依赖这些服务的数据平面相比，该策略成功的可能性可能要小。恢复策略应避免依赖这些操作。 以下是其他服务可能依赖的服务列表，这些服务具有全局范围： + **53 号公路** 一些 AWS 服务创建的资源可提供特定于资源的DNS名称。例如，当您配置 Elastic Load Balancer (ELB) 时，该服务会在 Route 53 中为创建公共DNS记录和运行状况检查ELB。这依赖于 53 号公路的控制飞机`us-east-1`。您使用的其他服务可能还需要预置ELB、创建公共 Route 53 DNS 记录或创建 Route 53 运行状况检查作为其控制平面工作流程的一部分。例如，配置亚马逊API网关RESTAPI资源、亚马逊关系数据库服务 (AmazonRDS) 数据库或亚马逊 OpenSearch 服务域都会导致在 Route 53 中创建DNS记录。以下是服务列表，这些服务的控制平面依赖于 Route 53 控制平面`us-east-1`来创建、更新或删除DNS记录、托管区域和/或创建 Route 53 运行状况检查。此列表并不详尽；它旨在重点介绍一些最常用的服务，这些服务的创建、更新或删除资源的控制平面操作取决于 Route 53 控制平面： + 亚马逊 API Gateway REST 和 HTTP APIs + 亚马逊RDS实例 + 亚马逊 Aurora 数据库 + Amazon ELB 负载均衡器 + AWS PrivateLink VPC端点 + AWS Lambda URLs + Amazon ElastiCache + 亚马逊 OpenSearch 服务 + Amazon CloudFront + Amazon MemoryDB + Amazon Neptune + 亚马逊 DynamoDB 加速器 () DAX + AGA + 带有DNS基于服务发现功能的亚马逊弹性容器服务 (AmazonECS)（使用管理 Route 53DNS） AWS Cloud Map API + 亚马逊 EKS Kubernetes 控制飞机 值得注意的是，主机名等VPCDNS服务独立存在于每个[EC2 AWS 区域 主机名](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html)中，不依赖于 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 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) 的控制平面[仅托管在中 `us-west-2`](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MrapOperations.html)，创建、更新或删除请求直接MRAPs针对该区域。的控制平面MRAP还依赖于 AGA in `us-west-2`、Route 53 in `us-east-1` 以及配置MRAP为从ACM中提供内容的每个区域。您不应依赖恢复路径或您自己系统的数据平面中MRAP控制平面的可用性。这与[MRAP故障转移控制](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MrapFailover.html)不同，后者用于为中的每个存储段指定主动或被动路由状态。MRAPAPIs它们分为[五 AWS 区域](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MrapOperations.html#update-mrap-route-configuration)个托管，可用于使用服务的数据平面有效地转移流量。 此外，Amazon S3 [存储桶名称是全球唯一](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html)的`us-east-1`，所有对`CreateBucket`和的调用都`DeleteBucket`APIs依赖于`aws`分区中的名称以确保名称的唯一性，即使API调用指向要在其中创建存储桶的特定区域。最后，如果您有关键的存储桶创建工作流程，则不应依赖存储桶名称的任何特定拼写是否可用，尤其是那些遵循明显模式的拼写。 ****建议**** 不要依赖删除或创建新的 S3 存储桶或更新 S3 存储桶配置作为恢复路径的一部分。使用必要的配置预置所有必需的 S3 存储桶，这样您就无需进行更改即可从故障中恢复。这种方法MRAPs也适用于。 + **CloudFront** Amazon API Gateway 提供[边缘优化的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 还[需要从区域终端节点请求临时证书。STS](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html#signature-versions)您不能使用全局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)静态稳定的方式创建 breakglass 用户的详细信息，请参阅。 ****建议**** 更新您的IAM角色信任政策以接受来自多个区域的SAML登录。在故障期间，如果您的首选SAML终端节点受损，请更新您的 IdP 配置以使用其他区域终端节点。创建漏洞用户，以防您的 IdP 受损或不可用。 **AWS IAMIdentity Center：**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)静态稳定的方式创建 breakglass 用户的详细信息，请参阅。 ****建议**** 在 Ident IAM ity Center 中设置权限集的中继状态URL，使其与部署服务的区域相匹配。如果您的 Ident IAM ity Center 部署不可用，请创建漏洞用户。 **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 服务相似的隔离和独立原则。影响某个区域的数据平面的故障不会影响另一个 AWS 区域区域IAM中该IAM数据平面的运行。同样，影响 PoP 中 53 号公路数据平面的故障不会影响其余部分 53 号公路数据平面的运行。 PoPs因此，我们必须考虑的是影响控制平面运行区域或影响控制平面本身的服务可用性事件。由于每个全局服务只有一个控制平面，因此影响该控制平面的故障可能会对 CRUDL-type 操作（这些配置操作通常用于设置或配置服务，而不是直接使用服务）产生跨区域影响。 设计工作负载以弹性方式使用全球服务的最有效方法是使用静态稳定性。在故障场景中，设计工作负载时无需使用控制平面进行更改以减轻影响或故障转移到其他位置。有关如何[附录 A-分区服务指南](appendix-a---partitional-service-guidance.md)利用这些类型的全球服务来消除控制平面依赖关系并消除单点故障的规范性指导，请参阅和。[附录 B-边缘网络全球服务指南](appendix-b---edge-network-global-service-guidance.md)如果您需要控制平面操作中的数据进行恢复，请将这些数据缓存在可通过其数据平面访问的数据存储中，例如 Sy [AWS stems 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 Identity Center 让操作员在故障事件期间访问生产环境。 + 将IAM身份中心部署到其他区域`us-east-1`后，依靠默认的 Identity Center 配置来使用控制台。 + 更改AGA流量拨号权重以手动执行区域故障转移。 + 更新 CloudFront 分配的源配置，使其无法从受损的来源中移开。 + 配置灾难恢复 (DR) 资源，例如ELBs故障事件期间的RDS实例，这些资源依赖于在 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登录。在故障期间，如果您的首选SAML终端节点受损，请更新您的 IdP 配置以使用其他区域终端节点。创建漏洞用户，以防您的 IdP 受损或不可用。 在 Ident IAM ity Center 中设置权限集的中继状态URL，使其与部署服务的区域相匹配。如果您的 Identity Center 部署不可用，请创建漏洞用户。 如果在中出现影响服务的故障期间，您需要来自默认 S3 Storage Lens 仪表板的数据`us-east-1`，请在备用主区域创建其他仪表板。您也可以复制您在其他区域中创建的任何其他自定义仪表板。