全球服务 - AWS故障隔离边界
按分区划分的唯一全球服务边缘网络中的全球服务全球单一区域运营 使用默认全局端点的服务全球服务摘要

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

全球服务

除了区域和区域 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它具有单个控制平面和区域化数据平面

IAM具有单个控制平面和区域化数据平面

以下是分区服务及其控制平面在aws分区中的位置：

  • AWS IAM (us-east-1)

  • AWS Organizations (us-east-1)

  • AWS 账户管理 (us-east-1)

  • Route 53 应用程序恢复控制器 (ARCus-west-2) ()-此服务仅存在于aws分区中

  • AWS 网络管理器 (us-west-2)

  • 53 号公路私人 DNS (us-east-1)

如果这些服务控制平面中的任何一个发生影响可用性的事件，则可能无法使用这些服务提供的 CRUDL-type 操作。因此，如果您的恢复策略依赖于这些操作，那么对控制平面或托管控制平面的区域的可用性影响将降低成功恢复的机会。 附录 A-分区服务指南提供了在恢复期间消除对全局服务控制平面依赖的策略。

建议

在恢复路径中，不要依赖分区服务的控制平面。相反，请依赖这些服务的数据平面操作。附录 A-分区服务指南有关应如何设计分区服务的更多详细信息，请参阅。

边缘网络中的全球服务

下一组全球 AWS 服务在aws分区中有一个控制平面，并将其数据平面托管在全局接入点 (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-边缘网络全球服务指南。

全球单一区域运营

最后一个类别由具有全球影响范围的服务中的特定控制平面操作组成，而不是像前面的类别那样由整个服务组成。当您与指定区域中的地区和区域服务进行交互时，某些操作对与资源所在位置不同的单个区域有潜在的依赖关系。这些服务与仅在单个地区提供的服务不同；有关这些服务的列表，请参阅。附录 C-单区域服务

在影响底层全局依赖关系的故障期间，您可能无法使用依赖操作的 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 区域 主机名中，不依赖于 Route 53 控制平面。为VPCDNS服务中的EC2实例 AWS 创建的记录（例如、ip-10-0-10.ec2.internalip-10-0-1-5.compute.us-west-2.compute.internali-0123456789abcdef.ec2.internali-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，创建、更新或删除请求直接MRAPs针对该区域。的控制平面MRAP还依赖于 AGA in us-west-2、Route 53 in us-east-1 以及配置MRAP为从ACM中提供内容的每个区域。您不应依赖恢复路径或您自己系统的数据平面中MRAP控制平面的可用性。这与MRAP故障转移控制不同，后者用于为中的每个存储段指定主动或被动路由状态。MRAPAPIs它们分为五 AWS 区域个托管，可用于使用服务的数据平面有效地转移流量。

    此外，Amazon S3 存储桶名称是全球唯一的us-east-1，所有对CreateBucket和的调用都DeleteBucketAPIs依赖于aws分区中的名称以确保名称的唯一性，即使API调用指向要在其中创建存储桶的特定区域。最后，如果您有关键的存储桶创建工作流程，则不应依赖存储桶名称的任何特定拼写是否可用，尤其是那些遵循明显模式的拼写。

    建议

    不要依赖删除或创建新的 S3 存储桶或更新 S3 存储桶配置作为恢复路径的一部分。使用必要的配置预置所有必需的 S3 存储桶，这样您就无需进行更改即可从故障中恢复。这种方法MRAPs也适用于。

  • CloudFront

    Amazon API Gateway 提供边缘优化的API端点。创建这些端点取决于中的 CloudFront控制平面us-east-1，以便在网关终端节点前面创建分发。

    建议

    不要依赖创建新的边缘优化的API网关端点作为恢复路径的一部分。预配置所有必需的API网关终端节点。

    本节中讨论的所有依赖关系都是控制平面操作，而不是数据平面操作。如果您的工作负载配置为静态稳定，则这些依赖关系不应影响您的恢复路径，请记住，静态稳定性需要额外的工作或服务才能实现。

使用默认全局端点的服务

在少数情况下， AWS 服务会提供默认的全局端点，例如 AWS 安全令牌服务 (AWS STS)。其他服务可能会在其默认配置中使用此默认的全局端点。这意味着您正在使用的区域服务可能对单个服务具有全球依赖性 AWS 区域。以下详细信息说明了如何删除对默认全局终端节点的意外依赖关系，这将有助于您以区域方式使用该服务。

AWS STS: STS 是一项 Web 服务，允许您为IAM用户或经过身份验证的用户（联合用户）申请临时的、有限权限的证书。STS AWS 软件开发套件 (SDK) 和命令行界面 (CLI) 中的用法默认为us-east-1。该STS服务还提供区域终端节点。这些终端节点在默认情况下也处于启用状态的区域中处于启用状态。您可以随时通过配置SDK或CLI遵循以下说明来利用这些优势：AWS STS区域化终端节点。使用 Sigv4a 还需要从区域终端节点请求临时证书。STS您不能使用全局STS终端节点执行此操作。

建议

更新您的SDK和CLI配置以使用区域终STS端节点。

安全断言标记语言 (SAML) 登录：所有SAML服务都存在。 AWS 区域要使用此服务，请选择相应的区域SAML终端节点，例如 https://us-west-2.signin.aws.amazon.com/saml。您必须更新信任策略和身份提供商 (IdP) 中的配置才能使用区域终端节点。有关具体细节，请参阅AWS SAML文档。

如果您使用的 IdP 也托管在其上 AWS，则它们也有可能在 AWS 故障事件期间受到影响。这可能导致您无法更新 IdP 配置，或者可能无法完全联合。您应该预先配置 “破碎玻璃” 用户，以防您的 IdP 受损或不可用。有关如何以附录 A-分区服务指南静态稳定的方式创建 breakglass 用户的详细信息，请参阅。

建议

更新您的IAM角色信任政策以接受来自多个区域的SAML登录。在故障期间，如果您的首选SAML终端节点受损，请更新您的 IdP 配置以使用其他区域终端节点。创建漏洞用户，以防您的 IdP 受损或不可用。

AWS IAMIdentity Center：Identity Center 是一项基于云的服务，可轻松集中管理对客户 AWS 账户 和云应用程序的单点登录访问。身份中心必须部署在您选择的单个区域。但是，该服务的默认行为是使用托管在中的全局SAML终端节点 (https://signin.aws.amazon.com/saml) us-east-1。如果您已将 Identity Center 部署到不同的服务器中 AWS 区域，则应更新每个权限集URL的中继状态，使其定位到与身份中心部署相同的区域控制台终端节点。例如，如果您将 Identity Center 部署到中us-west-2，则应将权限集的中继状态更新为使用 https://us-west-2.console.aws.amazon.com。这将us-east-1从您的身份中心部署中移除对的任何依赖。

此外，由于 IAM Identity Center 只能部署到单个区域，因此您应预先配置 “破碎玻璃” 用户，以防部署受损。有关如何以附录 A-分区服务指南静态稳定的方式创建 breakglass 用户的详细信息，请参阅。

建议

在 Ident IAM ity Center 中设置权限集的中继状态URL，使其与部署服务的区域相匹配。如果您的 Ident IAM ity Center 部署不可用，请创建漏洞用户。

Amazon S3 存储镜头：存储镜头提供了一个名为的默认控制面板 default-account-dashboard。仪表板配置及其相关指标存储在中us-east-1。您可以通过为仪表板配置和指标数据指定主区域，在其他区域创建其他控制面板。

建议

如果在中出现影响服务的故障期间，您需要来自默认 S3 Storage Lens 仪表板的数据us-east-1，请在备用主区域创建其他仪表板。您也可以复制您在其他区域中创建的任何其他自定义仪表板。

全球服务摘要

全球服务的数据平面采用与区域 AWS 服务相似的隔离和独立原则。影响某个区域的数据平面的故障不会影响另一个 AWS 区域区域IAM中该IAM数据平面的运行。同样，影响 PoP 中 53 号公路数据平面的故障不会影响其余部分 53 号公路数据平面的运行。 PoPs因此，我们必须考虑的是影响控制平面运行区域或影响控制平面本身的服务可用性事件。由于每个全局服务只有一个控制平面，因此影响该控制平面的故障可能会对 CRUDL-type 操作（这些配置操作通常用于设置或配置服务，而不是直接使用服务）产生跨区域影响。

设计工作负载以弹性方式使用全球服务的最有效方法是使用静态稳定性。在故障场景中，设计工作负载时无需使用控制平面进行更改以减轻影响或故障转移到其他位置。有关如何附录 A-分区服务指南利用这些类型的全球服务来消除控制平面依赖关系并消除单点故障的规范性指导，请参阅和。附录 B-边缘网络全球服务指南如果您需要控制平面操作中的数据进行恢复，请将这些数据缓存在可通过其数据平面访问的数据存储中，例如 Sy AWS stems Manager 参数存储（SSM参数存储）参数、DynamoDB 表或 S3 存储桶。为了实现冗余，您也可以选择将该数据存储在其他区域。例如，按照 Route 53 应用程序恢复控制器 (ARC) 的最佳实践，您应该对五个区域群集终端节点进行硬编码或添加书签。在发生故障事件期间，您可能无法访问某些API操作，包括未托管在极其可靠的数据平面集群上的 Route 53 ARC API 操作。您可以使用DescribeClusterAPI操作列出 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-分区服务指南有关应如何设计分区服务的更多详细信息，请参阅。

在恢复路径中，不要依赖边缘网络服务的控制平面。相反，请依赖这些服务的数据平面操作。有关如何在边缘网络中设计全球服务的更多详细信息，请参阅附录 B-边缘网络全球服务指南。

不要依赖创建、更新或删除恢复路径中需要创建、更新或删除 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，请在备用主区域创建其他仪表板。您也可以复制您在其他区域中创建的任何其他自定义仪表板。