本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 附录 B-边缘网络全球服务指南
对于边缘网络全球服务，应实现静态稳定性，以便在AWS服务控制平面受损期间保持工作负载的弹性。
## Route 53
Route 53 控制平面由所有公共 Route 53 API 组成，涵盖托管区域、记录、运行状况检查、DNS 查询日志、可重复使用的委托集、流量策略和成本分配标签等功能。它托管在 us-east-1。数据层面是权威 DNS 服务，它运行在 200 多个接入点 POP 位置，根据您的托管区域和运行状况检查数据应答 DNS 查询。AWS 区域此外，Route 53 有一个用于运行状况检查的数据平面，它也是一项分布在多个服务器上的全球分布式服务。AWS 区域该数据层面可执行运行状况检查、汇总结果并将它们传送到 Route 53 公有和私有 DNS 和 AGA 的数据层面。在控制平面受损期间，Route 53 的 CRUDL 类操作可能无法正常运行，但是 DNS 解析和运行状况检查以及因运行状况检查变化而导致的路由更新将继续有效。
这意味着，在规划对 Route 53 的依赖关系时，在恢复路径中不应依赖 Route 53 控制平面。例如，静态稳定的设计是使用运行状况检查状态在区域之间执行故障转移或撤出可用区。您可以使用 R [oute 53 应用程序恢复控制器 (ARC) 路由控制](https://docs.aws.amazon.com/r53recovery/latest/dg/routing-control.html)来手动更改运行状况检查的状态并更改对 DNS 查询的响应。您可以根据自己的要求实现与 ARC 提供的模式相似的模式。[使用 Route 53 创建灾难恢复机制](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)和[高级多可用区弹性模式运行状况检查断路器部分概述了其中一些模式](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/pattern-1-health-check-circuit-breaker.html)。如果您选择使用多区域 DR 计划，请预先配置需要创建 DNS 记录的资源，例如 ELB 和 RDS 实例。一种non-statically-stable设计是通过 `ChangeResourceRecordSets` API 更新 Route 53 资源记录的值、更改加权记录的权重或创建新记录以执行故障转移。这些方法取决于 53 号公路控制平面。
## Amazon CloudFront
亚马逊CloudFront控制平面由所有用于管理分发的公共 CloudFront API 组成，托管在 us-east-1 中。数据平面是边缘网络PoPs中的分布本身。它对您的原始内容执行请求处理、路由和缓存。在控制平面受损期间，CRUDL 类型的操作CloudFront（包括失效请求）可能不起作用，但您的内容将继续被缓存和提供服务，[原始故障转移](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html)将继续有效。
这意味着，当你计划依赖关系时CloudFront，你不应该在恢复路径中依赖CloudFront控制平面。例如，静态稳定的设计是使用自动原点故障转移来减轻损坏对您的某个来源的影响。您也可以选择使用 Lamda @Edge 构建原始负载平衡或故障转移，有关该[模式的更多详细信息，请参阅使用 Amazon 的高可用性应用程序的三种高级设计模式CloudFront](https://aws.amazon.com/blogs/networking-and-content-delivery/three-advanced-design-patterns-for-high-available-applications-using-amazon-cloudfront/)以及[使用 Amazon CloudFront 和 Amazon S3 构建多区域活跃地理邻近应用程序](https://aws.amazon.com/blogs/networking-and-content-delivery/using-amazon-cloudfront-and-amazon-s3-to-build-multi-region-active-active-geo-proximity-applications/)。一种non-statically-stable设计是手动更新发行版的配置以应对源故障。这种方法将取决于CloudFront控制平面。
### 亚马逊Certificate Manager
如果您在CloudFront发行版中使用自定义证书，则还依赖于 ACM。在您的CloudFront发行版中使用的是来自us-east-1 区域内的 ACM 控制层面。在控制层面损坏期间，您在分发中配置的现有证书将继续有效，证书会自动续订。不要依赖更改发行版的配置或创建新证书作为恢复路径的一部分。
### AWSWeb 应用程序防火墙 (WAF) 和 WAF 经典版
如果您在CloudFront发行版中AWS WAF使用，则依赖于 WAF 控制平面，该平面也托管在 us-east-1 区域。在控制平面受损期间，配置的 Web 访问控制列表 (ACL) 及其相关规则将继续发挥作用。不要依赖更新 WAF Web ACL 作为恢复路径的一部分。
## AWS Global Accelerator
AGA 控制平面由所有公共 AGA API 组成，托管在 us-west-2 中。数据平面是 AGA 向您的注册端点提供的 anycast IP 地址的网络路由。AGA 还利用 Route 53 运行状况检查来确定您的 AGA 终端节点（作为 Route 53 数据平面的一部分）的运行状况。在控制飞机损伤期间，AGA 的 CRUDL 类操作可能不起作用。路由到您的现有终端节点，以及用于将流量路由或转移到其他终端节点和终端节点组的现有运行状况检查、流量拨号和终端节点权重配置将继续有效。
这意味着，当你计划依赖于 AGA 时，你不应该在恢复路径中依赖 AGA 控制平面。例如，静态稳定的设计是利用已配置的运行状况检查的状态来排除不健康的端点。有关此配置的示例，请参阅[AWS使用AWS全球加速器中的部署多区域应用程序](https://aws.amazon.com/blogs/networking-and-content-delivery/deploying-multi-region-applications-in-aws-using-aws-global-accelerator/)。一种non-statically-stable设计是在受损期间修改 AGA 流量拨号百分比、编辑端点组或从端点组中删除端点。这些方法将取决于 AGA 控制平面。
## 亚马逊Shield
亚马逊 Shield Advanced 控制平面由所有公共 Shield Advanced API 组成，托管在 us-east-1。这包括`CreateProtection`、、`CreateProtectionGroup``AssociateHealthCheck``DesribeDRTAccess`、和等功能`ListProtections`。数据层面是 Shield Advanced 提供的 DDoS 防护，也是Shield Advanced指标的创建。如果你配置了 Route 53 生命值检查（这是 Route 53 数据平面的一部分），Shield Advanced 还会使用这些检查。在控制平面受损期间，Shield Advanced 的 CRUDL 类操作可能无法运行，但是为您的资源配置的 DDoS 保护以及对运行状况检查变更的响应将继续运行。
这意味着你不应该在恢复路径中依赖 Shield Advanced 控制平面。尽管 Shield Advanced 控制平面不提供你通常在恢复情况下使用的直接功能，但有时候你可能会这样做。例如，静态稳定的设计是将您的灾难恢复资源配置为保护组的一部分并对其进行相关的运行状况检查，而不是在故障发生后配置该保护。这样可以防止依赖 Shield Advanced 控制平面进行恢复。