附录 A-分区服务指南

对于分区服务，应实现静态稳定性，以便在AWS服务控制平面受损期间保持工作负载的弹性。以下内容提供了规范性指导，说明如何考虑对分区服务的依赖以及在控制平面损伤期间哪些会起作用和可能不起作用。

AWS Identity and Access Management (IAM)

AWS Identity and Access Management(IAM) 控制平面由所有公共 IAM API 组成（包括 Access Advisor，但不包括 Access Anywhere 的 Access Any 这包括CreateRole、、AttachRolePolicyChangePasswordUpdateSAMLProvider、和等操作UpdateLoginProfile。IAM 数据平面为每个AWS 区域平台中的 IAM 主体提供身份验证和授权。在控制平面受损期间，IAM 的 CRUDL 类型操作可能不起作用，但现有主体的身份验证和授权将继续有效。STS 是一项独立于 IAM 且不依赖于 IAM 控制平面的纯数据平面服务。

这意味着，当你计划依赖于 IAM 时，你不应该在恢复路径中依赖 IAM 控制平面。例如，对于 “break-glass” 管理员用户，静态稳定的设计是创建一个附加适当权限的用户，设置密码并配置访问密钥和私有访问密钥，然后将这些凭证锁定在物理或虚拟保管库中。在紧急情况下需要时，从保管库检索用户凭证并根据需要使用它们。一种non-statically-stable设计是在出现故障时为用户进行配置，或者预先配置用户，但仅在需要时附加管理员策略。这些方法将取决于 IAM 控制平面。

AWS Organizations

AWS Organizations控制平面由所有公共Organizations API 组成，如AcceptHandshakeAttachPolicyCreateAccountCreatePolicy、、和ListAccounts。没有专用的数据平面AWS Organizations。它为 IAM 等其他服务协调数据平面。在控制平面受损期间，Organizations 的 CRUDL 类型的操作可能不起作用，但是服务控制策略 (SCP) 和标签策略等策略将继续有效，并作为 IAM 授权过程的一部分进行评估。Organizations 支持的其他AWS服务中的委托管理员权能和多账户功能也将继续发挥作用。

这意味着，在规划依赖关系时，在恢复路径中不应依赖 AWS Organizations Organizations 控制平面。取而代之的是，在恢复计划中实现静态稳定性。例如，一种non-statically-stable方法可能是更新 SCP 以AWS 区域通过aws:RequestedRegion条件取消对允许的限制，或者为特定 IAM 角色启用管理员权限。这依赖于Organizations 控制平面来进行这些更新。更好的方法是使用会话标签来授予管理员权限的使用。您的身份提供商 (IdP) 可以包含可以根据aws:PrincipalTag条件进行评估的会话标签，这可以帮助您动态配置某些主体的权限，同时帮助您的 SCP 保持静态。这消除了对控制平面的依赖关系，仅使用数据平面操作。

AWS 账户管理

AWS账户管理控制平面托管在 us-east-1 中，由所有用于管理的公共 API 组成AWS 账户，例如和。GetContactInformation PutContactInformation它还包括AWS 账户通过管理控制台创建或关闭新的。CloseAccount、CreateAccountCreateGovCloudAccount、和的 API DescribeAccount 是控制平面的一部分，AWS Organizations控制平面也托管在 us-east-1 中。此外，在外部创建GovCloud账户AWS Organizations依赖于 us-east-AWS 账户 1 中的管理控制平面。此外，GovCloud账户必须以 1:1 的比例链接到aws分区AWS 账户中的。在aws-cn分区中创建账户的 us-eaaast-1 不依赖于 us-eaaast-1 的 的数据平面AWS 账户是账户本身。在控制平面受损期间，CRUDL 类型的操作（例如创建新账户或获取和更新联系信息）AWS 账户可能不起作用。IAM 政策中对账户的引用将继续有效。

这意味着，当你计划依赖AWS账户管理时，在恢复路径中不应依赖账户管理控制平面。尽管账户管理控制平面不提供您在恢复情况下通常使用的直接功能，但有时候您可能会这样做。例如，静态稳定的设计是预先配置故障转移所需的所有资源AWS 账户。一种non-statically-stable设计是在故障事件发生AWS 账户期间创建新的资源来托管您的灾难恢复资源。

Route 53 应用程序恢复控制器

Route 53 ARC 的控制平面由用于恢复控制和恢复就绪的 API 组成，具体参见：Amazon Route 53 应用程序恢复控制器终端节点和配额。您可以使用控制平面管理就绪检查、路由控制和集群操作。ARC 的数据平面是您的恢复集群，它管理 Route 53 运行状况检查查询的路由控制值，还实施安全规则。Route 53 ARC 的数据层面功能可通过您的恢复集群 API 进行访问，例如https://aaaaaaaa.route53-recovery-cluster.eu-west-1.amazonaws.com。

这意味着你不应该在恢复路径中依赖 Route 53 ARC 控制平面。有两种最佳做法可帮助实施本指南：

• 首先，将五个区域集群终端节点加入书签或硬编码。这样就无需在故障转移场景中使用DescribeCluster控制平面操作来发现端点值。

• 其次，使用 Route 53 ARC 集群 API，使用 CLI 或 SDK 对路由控制进行更新，而不是AWS Management Console。这消除了管理控制台对故障转移计划的依赖关系，并确保它仅依赖于数据平面操作。

AWS 网络管理器

AWS网络管理器服务主要是托管在 us-west-2 中的仅限控制飞机的系统。其目的是跨AWS 账户区域和本地位置集中管理 WAN 核心网络和 Transit Gateway 网络的 Tr AWS ansit Gateway 网络。AWS Cloud它还会汇总您在 us-west-2 中的云广域网指标，也可以通过数据平面访问这些指标。CloudWatch如果 Network Manager 受到损害，则其协调的服务的数据平面不会受到影响。us-we CloudWatch ast-2 的 Cloud WAN 的 us-weast-2 的 WAN 如果您想要历史指标数据，例如每个区域的进出字节，以了解在影响 us-west-2 的故障期间或出于其他运营目的可能会有多少流量转移到其他区域，则可以直接从CloudWatch控制台将这些指标导出为 CSV 数据或使用以下方法：将亚马逊CloudWatch指标发布到 CSV 文件。数据可以在AWS/Network Manager命名空间下找到，您可以按自己选择的时间表执行此操作，然后将其存储在 S3 或您选择的其他数据存储中。要实施静态稳定的恢复计划，请勿使用 AWS Network Manager 对网络进行更新，也不要依赖其控制平面操作中的数据进行故障切换输入。

53 号路由私有 DNS

每个分区都支持 Route 53 私有托管区域；但是，Route 53 中私有托管区域和公共托管区域的注意事项是相同的。请参阅附录 B-边缘网络全球服务指南中的 Amazon Route 53。