AWS 的 Availability Zone 设计 - 物理隔离与故障隔离带来的可靠性差异
对照 Azure / GCP 的可用区，结合公开的设计标准和实际的故障案例，解说 AWS 的 AZ 是物理上相互独立的数据中心群这一设计思想。
每个云都有可用区，但并不相同
AWS、Azure、GCP 都提供“可用区”（Availability Zone）这一概念。通过将资源分散到多个可用区来消除单点故障、实现高可用性，这一基本思路是共通的。但是，其实现细节存在很大差异。AWS 开始提供 AZ 是在 2008 年 3 月，这是在 2006 年 EC2 发布 2 年后，与 Elastic IP 地址等同时添加的功能。此后直到 2026 年的运营中，隔离的设计标准和以多 AZ 为前提的服务群逐步得到完善。Azure 正式提供 Availability Zones 是在 2018 年，开始提供的时间相差 10 年。不过，起步早并不直接意味着设计上的优劣。本文将结合各公司公开的设计标准和实际发生的故障的一手信息，梳理哪些差异是可以确认的。
AWS 的 AZ 设计 - 彻底的物理隔离
AWS 的每个 AZ 由 1 个或多个物理上相互独立的数据中心组成。AWS 公开了关于这种物理隔离的具体设计标准。每个 AZ 拥有独立的电力供应源，由不同的变电站供电。冷却系统和网络连接也各自独立。AZ 之间的距离在能够维持低延迟通信的范围内（通常 100km 以内），同时又相距足够远，使洪水、地震、火灾等局部灾害不会同时影响多个 AZ。这一设计的核心是“故障域的完全隔离”。其设计使得即使某个 AZ 发生电力故障，也不会波及相邻的 AZ。对于网络设备故障、冷却系统异常、建筑级别的灾害，设计目标也是将影响控制在该 AZ 之内。AWS 的一手描述也是以“每个 AZ 被设计为与其他 AZ 的故障相隔离”这样的设计目标的形式书写的，并不保证所有事件都不会波及其他 AZ。在可用性设计中，需要基于这种“设计目标”与“保证”的区别来决定冗余的范围。AWS 将这种隔离表述为“blast radius（爆炸半径）的最小化”，在物理上限制故障影响范围的设计理念始终如一。
Azure 的 Availability Zones - 引入的经过与应确认的要点
Azure 于 2018 年正式提供了 Availability Zones。可用区被说明为“拥有独立的电力、冷却和网络的 1 个或多个数据中心”，将资源分散到多个可用区以消除单点故障的思路与 AWS 共通。不同的是经过。Azure 最初以 Availability Sets（基于故障域和更新域的逻辑隔离）作为可用性的基本单位，可用区是后来添加的概念，在保持与现有服务一致性的同时分阶段推出。因此在设计时，需要通过 Microsoft 的官方区域列表和各服务的文档，确认目标区域是否支持可用区，以及所用服务如何处理可用区（是可用区冗余，还是固定到特定可用区）。由于支持情况在不断扩大，不以特定时间点的支持表为前提来固定判断会更安全。此外，AZ 之间的距离以及电力 / 冷却的隔离标准公开到什么程度，各公司各不相同。即使用的是同一个“可用区”的说法，也需要以用户能够验证的粒度并不一致为前提来进行比较。
GCP 的可用区设计 - 不同的方法
GCP 的可用区在概念上与 AWS 的 AZ 类似，但设计方法不同。GCP 通常在每个区域配置 3 个可用区，构建在 Google 大规模的全球网络之上。GCP 的优势在于，Google 多年来运营大规模分布式系统的经验反映在了可用区设计中。像 Spanner 这样的全球分布式数据库以可用区间复制为前提进行设计，被认为对可用区故障有很高的耐受性。另一方面，GCP 以 3 个可用区构成的区域居多，像 AWS 东京区域（4 AZ）那样可以选择 4 个以上可用区的区域很有限。不过，并不是不存在 4 个可用区的区域，us-central1 就拥有 4 个可用区。可用区数量越多，资源分散配置的选择就越多，在 1 个可用区无法使用时，也更容易确保由其余可用区承接的余力。设计时要确认的不是各公司的可用区总数，而是在想使用的区域实际可选的可用区数量，以及能否将容量分散配置到这些可用区。
从实际故障案例看 AZ 隔离的实效
AZ 设计的真正价值，在实际发生故障时才会受到检验。AWS 过去经历过多次大规模故障，但其中多数情况下 AZ 的隔离都按设计发挥了作用。2017 年的 S3 故障（us-east-1）是由输入错误导致的操作失误引起的，但影响仅限于特定的子系统，其他区域和 AZ 的服务继续正常运行。在 2019 年 us-east-1 的电力故障中，事件被控制在单个 AZ 之内。不过，只在该 AZ 放置了资源的环境会受到影响。并不是采用多 AZ 架构就会自动毫发无损，能否作为单个 AZ 的事件挺过去，取决于应用程序一侧是否采用了能在其余 AZ 继续处理的架构。AWS 会公开部分大规模故障的事后总结，但并非所有事件都会公开。设计的前提应当放在设计目标和各服务的行为规范上，而不是个别的公开报告上。其他公司也发生过同类事件。在 2023 年 8 月澳大利亚东部区域的故障中，电压下降导致冷却装置停止。根据 Microsoft 公开的事后审查，影响范围被认定为 3 个可用区中 1 个可用区内的一部分。无法从 1 家公司的故障案例中判断其他公司隔离程度的优劣。可以作为判断依据的，是各公司公开的设计标准，以及事后审查以什么粒度公开这一运营态度。
多 AZ 设计的最佳实践
即使 AZ 的隔离很出色，如果应用程序一侧没有以多 AZ 为前提进行设计，也无法获得其好处。AWS 提供了丰富的服务和工具，使多 AZ 设计更加容易。RDS 的多 AZ 部署会自动将主实例和备用实例配置在不同的 AZ，并在故障时自动进行故障转移。ELB（Elastic Load Balancing）会将流量分散到已启用的多个 AZ。跨 AZ 分配流量的 cross-zone load balancing 的默认值因负载均衡器类型而异。Application Load Balancer 默认启用，Network Load Balancer 默认禁用。如果想在 NLB 中避免因目标数量不均导致的负载不均，就显式启用该设置，或在各 AZ 配置相同数量的目标。Auto Scaling 组将实例分散配置在多个 AZ，当特定 AZ 无法使用时，会在其余 AZ 自动补充容量。不过，这些服务也都以“启用多个 AZ”“为每个 AZ 确保足够的容量”这样的用户侧设置为前提。在只在 1 个 AZ 创建了子网、Auto Scaling 组的最小数量仍为 1 台、使用 single-AZ 架构的 RDS 等状态下，服务一侧的分散功能不会起作用。多 AZ 设计不是选择支持的服务，而是有意识地把各服务与 AZ 相关的设置逐一选定。即使采用了多 AZ，如果不用数字确定承诺的可用性，就无法判断架构是否足够。Datadog 的 SLO 可以从基于指标 / 基于监控器 / 时间切片 3 种类型创建（截至 2026 年 10 月）。目标比例决定了允许的不稳定量（错误预算）。告警可以按已用比例或消耗速度（燃烧率）2 种方式发出，但根据 Datadog 的 SLO 官方文档，错误预算及其告警需要低于 100% 的目标。
AZ 间通信的低延迟 - 兼顾隔离与连接
在物理隔离的同时保持 AZ 间通信的低延迟，直接关系到多 AZ 架构的实用性。AWS 用专用的高带宽 / 低延迟网络连接各 AZ，AZ 间的往返延迟通常在 1～2 毫秒以内。凭借这种低延迟，同步复制（RDS 多 AZ、EFS）和实时故障转移以实用的速度运行。隔离与连接本来是权衡关系，但 AWS 通过投资专用的暗光纤网络，在很高的水平上解决了这一权衡。AZ 间的通信会产生数据传输费用，这反映了 AZ 间专用网络基础设施的维护成本，需要在理解与同一 AZ 内免费通信之间的成本差异的基础上纳入设计。
总结
AWS 的 AZ 设计自 2008 年 3 月开始提供以来，通过公开物理隔离的设计标准、基于故障案例的改进，以及以多 AZ 为前提的服务设计的积累而逐步完善。Azure 于 2018 年正式提供可用区，GCP 拥有反映了 Google 大规模分布式系统经验的可用区设计。之所以难以横向比较，是因为公开的设计标准的粒度和故障事后审查的公开范围各公司都不相同。因此在选择云时，务实的做法不是看有没有可用区这个说法，而是逐一确认在想使用的区域实际可选的可用区数量、所用服务如何默认处理跨可用区的行为，以及故障时的事后审查公开到什么程度。在此基础上，最终起作用的是应用程序一侧能否以多 AZ 为前提进行构建，以充分利用所选云的隔离设计。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。