REL10-BP01 将工作负载部署到多个位置

将工作负载数据和资源分布到多个可用区，或在必要时分布到多个 AWS 区域。可通过选择不同位置满足各种需求。

中服务设计的基本原则之一 AWS 是避免底层物理基础设施出现单点故障。这促使我们构建使用多个可用区并能灵活应对单个可用区故障的软件和系统。同样，系统也构建成可灵活应对单个计算节点、单个存储卷或单个数据库实例故障。在构建依赖冗余组件的系统时，重要的是要确保组件独立运行，如果是冗余组件，则要自主运行。 AWS 区域只有实现了这一点，采用冗余组件的理论可用性计算的优点才能发挥作用。

可用区 (AZs)

AWS 区域 由多个可用区组成，这些可用区旨在相互独立。每个可用区之间的物理距离相隔很远，避免环境公害（如火灾、洪水和龙卷风）导致的相关故障情况。每个可用区还拥有独立的物理基础设施：专用的公用电源连接、独立备份电源、独立机械服务以及可用区内外的独立网络连接。此设计将这些系统的故障限制在受影响的那一个可用区中。尽管可用区在地理位置上相互分离，但它们位于相同的区域中，从而实现高吞吐量、低延迟的联网。整个 AWS 区域 （跨所有可用区，由多个物理上独立的数据中心组成）可以视为工作负载的单个逻辑部署目标，包括同步复制数据（例如，在数据库之间）的能力。这样一来，您便能在主动/主动或主动/备用配置中使用可用区。

可用区彼此独立，因此当工作负载采用了使用多个可用区的架构时，可以提高工作负载的可用性。一些 AWS 服务（包括 Amazon EC2 实例数据平面）是作为严格的区域服务部署的，它们与其所在的可用区有着共同的命运。但是，另一个中的Amazon EC2 实例AZs将不受影响并继续运行。与此类似，如果某个可用区中的故障导致 Amazon Aurora 数据库失败，则不受影响的可用区中的只读副本 Aurora 实例可以自动提升为主实例。另一方面，区域性 AWS 服务（例如 Amazon DynamoDB）在内部以主动/主动配置的形式使用多个可用区，以此实现为该服务设定的可用性设计目标，无需配置可用区置放。

图 9：跨三个可用区部署的多层架构。请注意，Amazon S3 和 Amazon DynamoDB 始终会自动部署到多个可用区。ELB还部署到所有三个区域。

虽然 AWS 控制平面通常能够管理整个区域（多个可用区）内的资源，但某些控制平面（包括 Amazon EC2 和 AmazonEBS）能够将结果筛选到单个可用区。完成筛选后，请求仅在指定可用区中进行处理，从而降低其他可用区的中断风险。此 AWS CLI 示例说明仅从 us-east-2c 可用区获取 Amazon EC2 实例信息：

 AWS ec2 describe-instances --filters Name=availability-zone,Values=us-east-2c
  

AWS 本地扩展区

AWS Local Zones 的作用与各自 AWS 区域 可用区域内的可用区域类似，因为它们可以被选为区域 AWS 资源（例如子网和EC2实例）的放置位置。它们之所以与众不同，是因为它们不位于相关的中心 AWS 区域，而是靠近当今不 AWS 区域 存在的大量人口、工业和IT中心。但是，您还是可以享有高带宽，而且可在 Local Zone 的本地工作负载之间以及在 AWS 区域内运行的本地工作负载之间进行安全连接。为了满足低延迟的要求，您应该利用 AWS Local Zones 将工作负载尽量部署在接近用户的地方。

Amazon 全球边缘网络

Amazon 全球边缘网络由全球各大城市的边缘站点组成。Amazon CloudFront 使用该网络以更低的延迟向最终用户交付内容。 AWS Global Accelerator 允许您在这些边缘位置创建工作负载终端节点，为靠近用户的 AWS 全球网络提供入门服务。Amazon G API ateway 允许使用 CloudFront 分配进行边缘优化的API终端节点，以方便客户端通过最近的边缘站点进行访问。

AWS 区域

AWS 区域 旨在实现自主性，因此，要使用多区域方法，您需要为每个区域部署专用的服务副本。

多区域方法对于灾难恢复策略很常见，用于在偶发的大规模事件中满足恢复目标。请参阅灾难恢复（DR）计划，了解有关这些策略的更多信息。不过，这里的重点是可用性，旨在达成长期使用中的平均正常运行时间目标。对于高可用性目标，通常可以将多区域架构设计为主动/主动模式，各个服务副本（在其各自的区域中）处于活动状态（为请求提供服务）。

AWS 为您提供跨区域运营服务的能力。例如，使用亚马逊简单存储服务 (Amazon S3) Simple S3 复制、亚马逊只读副本（包括 Aurora 只读副本）和RDS亚马逊 DynamoDB 全局表为数据 AWS 提供持续、异步的数据复制。通过连续复制，数据版本可近乎实时地供各个活动区域使用。

使用 AWS CloudFormation，您可以定义您的基础架构， AWS 账户 并在各个位置进行一致的部署 AWS 区域。并 AWS CloudFormation StackSets 扩展了此功能，允许您通过一次操作在多个账户和地区创建、更新或删除 AWS CloudFormation 堆栈。对于 Amazon EC2 实例部署，AMI（Amazon 系统映像）用于提供诸如硬件配置和已安装软件之类的信息。您可以实施一个 Amazon EC2 Image Builder 管道来创建AMIs您需要的内容并将其复制到您的活跃区域。这样可以确保这些 Golden AMIs 拥有在每个新区域部署和扩展工作负载所需的一切。

为了路由流量，Amazon Route 53 和 AWS 全球加速器都允许定义策略来确定哪些用户访问哪个活跃的区域终端节点。使用 Global Accelerator，您可以设置流量转盘，控制导向各个应用程序端点的流量的百分比。Route 53 支持这种百分比方法，还有多个其他策略可用，包括基于地理位置邻近度和延迟的策略。Global Accelerator 会自动利用广泛的 AWS 边缘服务器 AWS 网络，尽快将流量载入网络主干，从而降低请求延迟。

所有这些功能在执行时，都保留了各个区域的自主性。这种方法很少有例外，包括我们提供全球边缘交付的服务（例如亚马逊 CloudFront 和Amazon Route 53），以及 AWS Identity and Access Management (IAM) 服务的控制平面。大多数服务都完全在单个区域中运行。

本地数据中心

对于在本地数据中心运行的工作负载，请尽可能设计混合体验。 AWS Direct Connect 提供从您的场所连接的专用网络连接， AWS 允许您在两个场所运行。

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

在未建立这种最佳实践的情况下暴露的风险等级：高

实施指导

资源

相关文档：

相关视频：