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

边缘弹性

可靠性支柱包括工作负载在预期时正确、一致地执行其预期功能的能力。这包括能够在工作负载的整个生命周期中对其进行操作和测试。从这个意义上讲，在边缘设计弹性架构时，必须首先考虑将使用哪些基础架构来部署该架构。使用 AWS Local Zones 和可以实现三种可能的组合 AWS Outposts：前哨基地到前哨基地、前哨基地到本地区域以及本地区域到局域区域，如下图所示。尽管弹性架构还有其他可能性，例如将 AWS 边缘服务与传统的本地基础设施相结合 AWS 区域，或者，本指南重点介绍适用于混合云服务设计的这三种组合

基础架构注意事项

在 AWS，服务设计的核心原则之一是避免底层物理基础架构出现单点故障。由于这一原则， AWS 软件和系统使用多个可用区，并且能够抵御单个区域的故障。在边缘， AWS 提供基于 Local Zones 和 Outposts 的基础架构。因此，确保基础设施设计弹性的关键因素是定义应用程序资源的部署位置。

Local Zones

Local Zones 的作用与其中的可用区域类似 AWS 区域，因为可以选择它们作为子网和 EC2 实例等区域 AWS 资源的放置位置。但是，它们不在人口稠密 AWS 区域的工业和IT中心附近，而是在当今不 AWS 区域 存在的地方。尽管如此，它们仍然在本地区域中的本地工作负载与在本地区域中运行的工作负载之间保持高带宽的安全连接。 AWS 区域因此，您应该使用 Local Zones 将工作负载部署到离用户更近的地方，以满足低延迟要求。

Outposts

AWS Outposts 是一项完全托管的服务，可将 AWS 基础架构 AWS 服务 APIs、、和工具扩展到您的数据中心。您的数据中心安装的硬件基础设施与中 AWS Cloud 使用的硬件基础架构相同。然后，Outposts 与最近的哨所相连。 AWS 区域您可以使用 Outposts 来支持具有低延迟或本地数据处理要求的工作负载。

父可用区

每个本地区域或前哨基地都有一个父区域（也称为主区域）。父区域是 AWS 边缘基础设施（前哨基地或本地区域）的控制平面的锚定区域。就本地区域而言，父区域是本地区域的基本架构组件，客户无法对其进行修改。 AWS Outposts 将扩展 AWS Cloud 到您的本地环境，因此您必须在订购过程中选择特定的区域和可用区。此选项可将 Outposts 部署的控制平面锚定到所 AWS 选基础架构。

在边缘开发高可用性架构时，这些基础设施的父区域（例如 Outposts 或 Local Zones）必须相同，以便可以在它们之间扩展 VPC。这种扩展的 VPC 是创建这些高可用性架构的基础。在定义高弹性架构时，这就是为什么必须验证父区域和服务将（或已停靠）的区域的可用区。如下图所示，如果您想在两个 Outposts 之间部署高可用性解决方案，则必须选择两个不同的可用区来锚定 Outposts。这允许从控制平面角度实现多可用区架构。如果要部署包含一个或多个 Local Zones 的高可用性解决方案，则必须首先验证基础架构所在的父可用区。为此，请使用以下 AWS CLI 命令：

aws ec2 describe-availability-zones --zone-ids use1-mia1-az1

上一个命令的输出：

{     "AvailabilityZones": [         
          {
             "State": "available",
             "OptInStatus": "opted-in",
             "Messages": [],
             "RegionName": "us-east-1",
             "ZoneName": "us-east-1-mia-1a",
             "ZoneId": "use1-mia1-az1",
             "GroupName": "us-east-1-mia-1",
             "NetworkBorderGroup": "us-east-1-mia-1",
             "ZoneType": "local-zone",
             "ParentZoneName": "us-east-1d",
             "ParentZoneId": "use1-az2"
         }
     ]
 }

在此示例中，迈阿密本地区域 (us-east-1d-mia-1a1) 锚定在us-east-1d-az2可用区中。因此，如果您需要在边缘创建弹性架构，则必须确保辅助基础架构（Outposts 或 Local Zones）锚定到除之外的可用区。us-east-1d-az2例如，us-east-1d-az1将是有效的。

下图提供了高可用性边缘基础设施的示例。

联网注意事项

本节讨论边缘联网的初步注意事项，主要是访问边缘基础设施的连接。它审查了为服务链路提供弹性网络的有效架构。

Local Zones 的弹性网络

Local Zones 通过多个冗余、安全、高速的链路连接到父区域，使您能够无缝使用任何区域服务，例如 Amazon S3 和 Amazon RDS。您负责提供从您的本地环境或用户到本地区域的连接。无论您选择哪种连接架构（例如，VPN 或 AWS Direct Connect），通过网络链路实现的延迟都必须相同，以避免在主链路出现故障时对应用程序性能产生任何影响。如果您正在使用 AWS Direct Connect，则适用的弹性架构与用于访问的弹性架构相同 AWS 区域，如AWS Direct Connect 弹性建议中所述。但是，有些场景主要适用于国际 Local Zones。在启用本地区域的国家/地区，只有一个 AWS Direct Connect PoP 就无法创建推荐的 AWS Direct Connect 弹性架构。如果您只能访问单个 AWS Direct Connect 位置或需要单一连接以外的弹性，则可以在 Amazon EC2 上创建 VPN 设备 AWS Direct Connect，如 AWS 博客文章启用从本地到 AWS Local Zones的高可用性连接中所说明和讨论的那样。

Outposts 的弹性网络

与 Local Zones 形成鲜明对比的是，Outposts 具有冗余连接，可以从本地网络访问部署在 Outposts 中的工作负载。这种冗余是通过两台 Outposts 网络设备实现的 () ONDs。每个 OND 需要至少两个 1 Gbps、10 Gbps、40 Gbps 或 100 Gbps 的光纤连接到您的本地网络。必须将这些连接配置为链路聚合组 (LAG)，以允许以可扩展的方式添加更多链路。

有关此连接的更多信息，请参阅文档中的 Outposts Racks 的本地网络连接。 AWS Outposts

为了获得最佳体验和弹性， AWS建议您使用至少 500 Mbps（更好 1 Gbps）的冗余连接来连接到。 AWS 区域您可以使用 AWS Direct Connect 或互联网连接来获取服务链接。此最低限度使您能够启动 EC2 实例、附加 EBS 卷和访问 AWS 服务，例如 Amazon EKS、Amazon EMR 和指标。 CloudWatch

下图说明了这种用于高可用性专用连接的架构。

下图说明了这种用于高可用性公共连接的架构。

使用 ACE 机架扩展 Outposts 机架部署

聚合、核心、边缘 (ACE) 机架是 AWS Outposts 多机架部署的关键聚合点，主要推荐用于超过三个机架的安装或计划未来的扩展。每个 ACE 机架都有四台路由器，支持 10 Gbps、40 Gbps 和 100 Gbps 连接（100 Gbps 是最佳选择）。每个机架最多可连接四台上游客户设备，以实现最大冗余。ACE 机架消耗高达 10 kVA 的功率，重量可达 705 磅。主要优势包括降低物理网络需求、减少光纤布线上行链路以及减少 VLAN 虚拟接口。 AWS 通过 VPN 隧道通过遥测数据监控这些机架，并在安装过程中与客户密切合作，以确保适当的电源可用性、网络配置和最佳位置。随着部署规模的扩大，ACE 机架架构提供了不断增长的价值，并有效地简化了连接，同时降低了大型安装的复杂性和物理端口要求。 有关更多信息，请参阅 AWS 博客文章使用 ACE Rac AWS Outposts k 扩展机架部署。

在 Outposts 和 Local Zones 之间分配实例

Outposts 和 Local Zones 的计算服务器数量有限。如果您的应用程序部署了多个相关实例，则这些实例可能会部署在同一台服务器上或同一机架中的服务器上，除非它们的配置不同。除了默认选项外，您还可以跨服务器分配实例，以降低在同一基础架构上运行相关实例的风险。您还可以使用分区置放群组将实例分配到多个机架上。这称为展架分销模型。使用自动分配将实例分布到组中的各个分区，或者将实例部署到选定的目标分区。通过将实例部署到目标分区，您可以将选定的资源部署到同一个机架，同时在机架之间分配其他资源。Outpo sts 还提供了另一种名为 spre ad host 的选项，它允许你在主机级别分配工作负载。下图显示了分散机架和分散主机的分发选项。

Amazon RDS 中的多可用区 AWS Outposts

当您在 Outposts 上使用多可用区实例部署时，Amazon RDS 会在两个 Outposts 上创建两个数据库实例。每个 Outpost 都运行在自己的物理基础设施上，并连接到一个区域中的不同可用区以实现高可用性。当两个 Outposts 通过客户管理的本地连接连接时，Amazon RDS 会管理主数据库实例和备用数据库实例之间的同步复制。如果软件或基础设施出现故障，Amazon RDS 会自动将备用实例提升为主角色，并更新 DNS 记录以指向新的主实例。对于多可用区部署，Amazon RDS 会在一个 Outpost 上创建主数据库实例，并将数据同步复制到不同 Outpost 上的备用数据库实例。Outposts 上的多可用区部署与 AWS 区域中的多可用区部署类似，但有以下区别：

Outposts 上的 Amazon RDS 上所有支持的 MySQL 和 PostgreSQL 版本均支持多可用区部署。多可用区部署不支持本地备份。

下图显示了 Outposts 上的 Amazon RDS 多可用区配置的架构。

故障转移机制

负载平衡和自动扩展

Elastic Load Balancing (ELB) 会自动将您的传入应用程序流量分配到您正在 EC2 运行的所有实例。ELB 通过优化流量路由来帮助管理传入的请求，这样就不会让单个实例不堪重负。要将 ELB 与您的 Amazon A EC2 uto Scaling 组一起使用，请将负载均衡器附加到您的 Auto Scaling 组。这会将群组注册到负载均衡器，负载均衡器充当您的群组所有传入 Web 流量的单一联系点。在 Auto Scaling 组中使用 ELB 时，无需向负载均衡器注册单个 EC2 实例。您的 Auto Scaling 组所启动的实例会自动注册到负载均衡器。同样，由您的 Auto Scaling 组终止的实例将自动从负载均衡器注销。将负载均衡器连接到 Auto Scaling 组后，您可以将您的组配置为使用 ELB 指标（例如每个目标的 Application Load Balancer 请求数）来根据需求波动扩展组中的实例数量。或者，您可以将 ELB 运行状况检查添加到您的 Auto Scaling 组中，这样 Amazon A EC2 uto Scaling 就可以根据这些运行状况检查识别和替换运行状况不佳的实例。您也可以创建一个 Amazon CloudWatch 警报，当目标组的健康主机数低于允许值时，该警报会通知您。

下图说明了 Application Load Balancer 如何在 EC2 中管理 Amazon 上的工作负载 AWS Outposts。

下图说明了 Local Zones EC2 中亚马逊的类似架构。

用于 DNS 故障转移的亚马逊 Route 5

当您有多个资源执行相同的功能（例如多个 HTTP 或邮件服务器）时，您可以将 Amazon Rou te 53 配置为仅使用运行状况良好的资源来检查资源的运行状况并响应 DNS 查询。例如，假设您的网站托管在两台服务器上。example.com一台服务器在本地区域中，另一台服务器位于前哨基地。您可以将 Route 53 配置为仅使用当前运行状况的服务器来检查这些服务器的example.com运行状况并响应 DNS 查询。如果您使用别名记录将流量路由到选定 AWS 资源（例如 ELB 负载均衡器），则可以配置 Route 53 以评估资源的运行状况，并仅将流量路由到运行状况良好的资源。配置别名记录以评估资源的运行状况时，无需为该资源创建运行状况检查。

下图说明了 Route 53 的故障转移机制。

Amazon Route 53 Resolver on AWS Outposts

Amazon Route 53 Resolver可在 Outposts 机架上使用。它直接从 Outposts 为您的本地服务和应用程序提供本地 DNS 解析。本地 Route 53 解析器端点还支持 Outposts 和你的本地 DNS 服务器之间的 DNS 解析。Outposts 上的 Route 53 Resolver 有助于提高本地应用程序的可用性和性能。

Outposts 的典型用例之一是部署需要低延迟访问本地系统的应用程序，例如工厂设备、高频交易应用程序和医疗诊断系统。

当你选择在 Outposts 上使用本地 Route 53 解析器时，应用程序和服务将继续受益于本地 DNS 解析来发现其他服务，即使与 AWS 区域 父级的连接中断。本地解析器还有助于缩短 DNS 解析的延迟，因为查询结果是从 Outposts 本地缓存和提供的，从而消除了前往父节点的不必要往返行程。 AWS 区域 Outposts 中使用私有 DNS 的应用程序 VPCs 的所有 DNS 解析都是在本地提供的。

除了启用本地解析器外，此次启动还启用了本地解析器端点。Route 53 解析器出站终端节点允许 Route 53 解析器将 DNS 查询转发给您管理的 DNS 解析器，例如在您的本地网络上。相比之下，Route 53 Resolver 入站终端节点会将他们从 VPC 外部收到的 DNS 查询转发给在 Outposts 上运行的解析器。它允许您从该私有 Outposts VPC 外部为部署在私有 Outposts VPC 上的服务发送 DNS 查询。有关入站和出站终端节点的更多信息，请参阅 Route 53 文档中的解析 VPCs 与您的网络之间的 DNS 查询。