本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# AWS 基础设施
本节概述了AWS全球基础架构及其提供的故障隔离边界。此外，本节将概述控制平面和数据平面的概念，它们是其服务AWS设计方式的关键区别。这些信息为了解故障隔离边界以及服务的控制平面和数据平面如何应用于我们在下一节中讨论的AWS服务类型提供了基准。
**Topics**
+ [可用区](availability-zones.md)
+ [区域](regions.md)
+ [AWSLocal Zones](aws-local-zones.md)
+ [AWS Outposts](aws-outposts.md)
+ [存在点](points-of-presence.md)
+ [分区](partitions.md)
+ [控制面板和数据面板](control-planes-and-data-planes.md)
+ [静态稳定性](static-stability.md)
+ [Summary](summary.md)
# 可用区
AWS在全球多个地区运营着 100 多个可用区（当前数字可在此处找到：[AWS全球基础设施](https://aws.amazon.com/about-aws/global-infrastructure/)）。可用区是一个或多个独立的数据中心，其中包含独立和冗余的电源基础架构、网络和连接AWS 区域。一个区域中的可用区域彼此之间的距离相当大，最远可达 60 英里（约 100 km），以防止相关故障，但距离足够近，可以使用延迟为个位数毫秒的同步复制。它们的设计不会同时受到共同命运情景的影响，例如公用事业电力、水中断、光纤隔离、地震、火灾、龙卷风或洪水。常见的故障点（例如发电机和冷却设备）不是在可用区之间共享的，而是由独立的变电站提供的。在为其服务AWS部署更新时，会及时将部署到同一区域的可用区域分开，以防止出现相关故障。
一个区域中的所有可用区域都通过完全冗余的专用城域光纤与高带宽、低延迟的网络互连。*一个区域中的每个可用区都通过两个中转中心连接到互联网，那里AWS有多个[一级互联网提供商（有关更多信息，请参阅 Amazon Web Ser](https://en.wikipedia.org/wiki/Tier_1_network) [vices 概述](https://docs.aws.amazon.com/whitepapers/latest/aws-overview/introduction.html?did=wp_card&trk=wp_card)）。*
这些功能使可用区彼此之间具有很强的隔离，我们称之为可用区独立性 (AZI)。下图描述了可用区的逻辑结构及其与互联网的连接。
![\[此图显示了可用区如何由一个或多个物理数据中心组成，这些数据中心相互冗余连接并连接到互联网\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/aws-fault-isolation-boundaries/images/availability-zones.png)
# 区域
每个可用区都AWS 区域由一个地理区域内的多个独立且物理上独立的可用区组成。所有区域目前都有三个或更多可用区。区域本身是孤立的，独立于其他区域，但本文档后面会提到一些例外[（请参阅全球单一区域操作）](global-services.md#global-single-region-operations)。区域间的这种分隔将服务故障发生时限制在单个区域内。在这种情况下，其他地区的正常运营不受影响。此外，除非您明确使用AWS服务提供的复制或复制功能或自己复制资源，否则您在一个区域创建的资源和数据不存在于任何其他区域。
![\[此图说明了截至 2022 年 12 月的当前和计划中的 AWS 区域。\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/aws-fault-isolation-boundaries/images/current-and-planned-aws-regions.png)
# AWSLocal Zones
AWSL@@ [ocal Z](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) ones 是一种基础架构部署，它将计算、存储、数据库和其他[精选AWS服务](https://aws.amazon.com/about-aws/global-infrastructure/localzones/features/)放在靠近人口众多和行业中心的地方。您可以在本地区域中使用AWS诸如计算和存储服务之类的服务在边缘运行低延迟应用程序或简化混合云迁移。Local Zones 具有本地互联网入口和出口，以减少延迟，但也通过 Amazon 的冗余和高带宽专用网络连接到其父区域，从而使在 L AWS ocal Zones 中运行的应用程序可以快速、安全、无缝地访问所有服务。
# AWS Outposts
[AWS Outposts](https://aws.amazon.com/outposts/)是一系列完全托管的解决方案，可向几乎任何本地或边缘位置提供AWS基础设施和服务，以实现真正一致的混合体验。 Outposts 解决方案允许您在本地扩展和运行原生AWS服务，并且有多种外形可供选择，从 1U 和 2U Outposts 服务器到 42U Outposts 机架以及多机架部署。
使用AWS Outposts，您可以在本地运行[选定的AWS服务](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html#services)，并连接到父级中提供的各种服务AWS 区域。 AWS Outposts是完全托管且可配置的计算和存储机架，AWS采用精心设计的硬件构建，允许客户在本地运行计算和存储，同时无缝连接到AWS云中的各种服务。
# 存在点
除AWS 区域和可用区外，AWS还运营着全球分布的接入点 (PoP) 网络。它们 PoPs 托管内容分发网络 (CDN) 亚马逊、公共域名系统 (DNS) 解析服务 Amazon Route 53 和边缘网络优化服务AWS全球加速器 (AGA)。 CloudFront全球边缘网络目前由 410 多个边缘站点组成 PoPs，包括 400 多个边缘站点，以及 48 个国家/地区的 90 多个城市的 13 个区域中端缓存（当前状态可在此处找到：A [mazon CloudFront 主要功能](https://aws.amazon.com/cloudfront/features/)）。
![\[此图显示了 Amazon 的 CloudFront 全球边缘网络\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/aws-fault-isolation-boundaries/images/amazon-cloudfront.png)
每个 PoP 都与其他 PoP 隔离，这意味着影响单个 PoP 或大都市区的故障不会影响全球网络的其余部分。该AWS网络与全球数千家1/2/3级电信运营商同行，与所有主要接入网络连接良好，可实现最佳性能，并拥有数百太比特的部署容量。边缘站点AWS 区域通过网络主干与AWS网络主干相连，这是一种完全冗余的多个 100GbE 并行光纤，环绕全球并与成千上万个网络连接，以改善来源获取和动态内容加速。
# 分区
AWS将区域分组为[分区](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html)。每个区域恰好位于一个分区中，每个分区都有一个或多个区域。分区具有独立的 AWS Identity and Access Management (IAM) 实例，在不同分区中的区域之间提供了硬边界。 AWS商业区域位于`aws`分区中，中国区域位于`aws-cn`分区中，AWS GovCloud 区域位于`aws-us-gov`分区中。有些AWS服务旨在提供跨区域功能，例如 [Amazon S3 跨区域复制或 T AWS ransit Gateway 区域](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html#crr-scenario)[间](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-peering.html)对等互连。只有同一分区中的区域之间才支持这些类型的功能。您不能使用来自一个分区的 IAM 凭证与其他分区中的资源进行交互。
# 控制面板和数据面板
AWS将大多数服务分为*控制平面*和*数据*平面的概念。这些术语来自网络世界，特别是路由器。路由器的数据平面是其主要功能，它根据规则四处移动数据包。但是路由策略必须从某个地方创建和分发，而这正是控制平面的用武之地。
控制平面提供用于创建、读取/描述、更新、删除和列出 (CRUDL) 资源的管理 API。例如，以下都是控制平面操作：启动新的[亚马逊弹性计算云](https://aws.amazon.com/ec2/) (Amazon EC2) 实例、创建[亚马逊简单存储服务 (Amazon S3) 存储](https://aws.amazon.com/s3/)桶以及描述[亚马逊简单队列服务 (Amazon SQS) 队列](https://aws.amazon.com/sqs/)。当您启动 EC2 实例时，控制平面必须执行多项任务，例如查找具有容量的物理主机、分配网络接口、准备 A [mazon Elastic Block Store](https://aws.amazon.com/ebs/) (Amazon EBS) 卷、生成 IAM 证书、添加安全组规则等。控制平面往往是复杂的编排和聚合系统。
数据平面是提供服务主要功能的平面。例如，以下是所涉及的每项服务的数据平面的所有部分：正在运行的 EC2 实例本身、读取和写入 EBS 卷、获取和放入 S3 存储桶中的对象，以及 Route 53 应答 DNS 查询和执行运行状况检查。
与控制平面相比，数据平面故意不那么复杂，活动部件更少，控制平面通常实现由工作流程、业务逻辑和数据库组成的复杂系统。这使得从统计学上讲，与控制平面相比，数据平面中发生故障事件的可能性较小。虽然数据平面和控制平面都为服务的整体运营和成功做出了贡献，但AWS认为它们是截然不同的组成部分。这种分离具有性能和可用性两方面的好处。
# 静态稳定性
AWS服务最重要的弹性特征之一就是所AWS谓的静态稳定性。该术语的含义是，系统在静态状态下运行，并且在依赖关系出现故障或不可用期间无需进行更改即可继续正常运行。我们做到这一点的一种方法是防止服务中的循环依赖，因为循环依赖可能会阻止其中一个服务成功恢复。我们这样做的另一种方法是维护现有状态。我们考虑了这样一个事实，即从统计学上讲，控制平面比数据平面更有可能出现故障。尽管数据平面通常依赖于来自控制平面的数据，但即使面对控制平面损坏，数据平面仍会保持其现有状态并继续工作。数据平面对资源的访问一旦配置，就不依赖于控制平面，因此不受任何控制平面损坏的影响。换句话说，即使创建、修改或删除资源的能力受到损害，现有资源仍然可用。这使得AWS数据平面可以静态稳定地抵御控制平面中的损伤。你可以实现不同的模式，以保持静态稳定，抵御不同类型的依赖失败。
可以在 Amazon EC2 中找到静态稳定性的示例。EC2 实例启动后，它与数据中心的物理服务器一样可用。它不依赖任何控制平面 API 来保持运行或在重启后重新开始运行。VPC、Amazon S3 存储桶和对象以及 Amazon EBS 卷等其他AWS资源也具有相同的属性。
静态稳定性是一个在AWS设计其服务时根深蒂固的概念，但它也是一种可供客户使用的模式。实际上，以弹性方式使用不同类型AWS服务的大部分最佳实践指南是为生产环境实现静态稳定性。最可靠的恢复和缓解机制是那些需要最少更改即可实现恢复的机制。预先配置额外容量有助于实现静态稳定性，而不是依赖 EC2 控制平面启动新的 EC2 实例来从出现故障的可用区中恢复。因此，消除恢复路径中对控制平面（实现资源变更的 API）的依赖有助于生成更具弹性的工作负载。有关静态稳定性、控制平面和数据平面的更多详细信息，请参阅 Amazon Builders 库文章[使用可用区的静态稳定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)。
# Summary
AWS在我们的基础架构中利用不同的故障容器来实现故障隔离。核心基础设施故障容器包括分区、区域、可用区、控制平面和数据平面。接下来，我们将研究不同类型的AWS服务，如何在设计中使用这些故障容器，以及如何使用它们构建工作负载以保持弹性。