AWS 可用区设计 - 物理隔离与故障隔离带来的可靠性差异
解析 AWS 可用区作为物理独立数据中心群的设计理念，与 Azure 和 GCP 的可用区对比，结合公开的设计标准和实际故障案例进行解析。
可用区各云都有，但并不相同
AWS、Azure 和 GCP 都提供「可用区」（Availability Zone）的概念。通过将资源分布在多个区域来消除单点故障、实现高可用性的基本思路是共通的。然而，其实现细节存在巨大差异。AWS 于 2008 年 3 月开始提供可用区，这是 2006 年 EC2 推出两年后与 Elastic IP 地址等一同追加的功能。在此后到 2026 年的运营中，隔离的设计标准和以多可用区为前提的服务群逐步成形。Azure 于 2018 年正式发布 Availability Zones，起步时间相差 10 年。不过，起步早并不直接意味着设计上的优劣。本文依据各公司公开的设计标准和实际发生故障的一手信息，整理哪些差异是可以确认的。
AWS 的可用区设计 - 彻底的物理隔离
AWS 的每个可用区由一个或多个物理独立的数据中心组成。AWS 公开了关于物理隔离的具体设计标准。每个可用区拥有独立的电力供应源，从不同变电站供电。冷却系统和网络连接也各自独立。可用区之间的距离在维持低延迟通信的范围内（通常 100km 以内），同时保证足够远以使洪水、地震、火灾等局部灾害不会同时影响多个可用区。这一设计的核心是「故障域的完全隔离」。某个可用区发生电力故障时，设计上要使相邻可用区不受影响。对于网络设备故障、冷却系统异常、建筑级别的灾害，把影响封锁在该可用区内也是设计目标。AWS 的一手描述同样写成「每个可用区被设计为与其他可用区的故障相隔离」这一设计目标的形式，并不保证任何事件都不会波及其他可用区。在可用性设计中，需要基于「设计目标」与「保证」的差别来决定冗余范围。AWS 将此称为「blast radius（爆炸半径）最小化」，物理限制故障影响范围的设计哲学始终一贯。
Azure 的 Availability Zones - 引入的经过与需要确认的要点
Azure 于 2018 年正式发布 Availability Zones。可用区被说明为「拥有独立电力、冷却和网络的一个或多个数据中心」，把资源分布到多个可用区以消除单点故障的思路与 AWS 相同。不同的是经过。Azure 最初以 Availability Sets（通过故障域和更新域进行逻辑隔离）作为可用性的基本单位，可用区是后来追加的概念，在与现有服务保持一致的同时逐步展开。因此在设计时，需要通过 Microsoft 的官方区域列表和各服务文档确认目标区域是否支持可用区、所用服务如何处理可用区（区域冗余还是固定到特定可用区）。支持范围在不断扩大，最好不要以某一时点的支持表为前提固定判断。此外，各公司对可用区间距离、电力和冷却隔离标准的公开程度并不相同。即使都用「可用区」这个词，用户能够验证的粒度并不一致，比较时需要以此为前提。
GCP 的区域设计 - 不同的方式
GCP 的区域在概念上与 AWS 的可用区类似，但设计方式不同。GCP 在每个区域通常配置 3 个区域，构建在 Google 大规模全球网络之上。GCP 的优势在于 Google 多年运维大规模分布式系统的经验反映在区域设计中。Spanner 等全球分布式数据库以区域间复制为前提设计，对区域故障具有较高的容错能力。另一方面，GCP 以 3 个区域构成的地区居多，像 AWS 东京区域（4 个可用区）那样可选择 4 个以上区域的地区有限。不过并非不存在 4 个区域的地区，us-central1 就拥有 4 个区域。区域数越多，资源分布配置的选择越多，也更容易在某个区域不可用时由其余区域承接。设计时要确认的不是各公司的区域总数，而是想用的地区实际可选的区域数，以及能否把容量分散配置到这些区域。
从实际故障案例看可用区隔离的实效性
可用区设计的真正价值在实际发生故障时才能体现。AWS 过去经历了多次大规模故障，但大多数情况下可用区隔离按设计正常运作。2017 年的 S3 故障（us-east-1）虽因输入错误的操作失误引起，但影响仅限于特定子系统，其他区域和可用区的服务继续正常运行。2019 年 us-east-1 的电力故障中，事件被封锁在单个可用区内。不过，只在该可用区放置资源的环境仍会受到影响。多可用区架构并不会自动毫发无损，能否作为单个可用区的事件渡过，取决于应用端是否配置为可在其余可用区继续处理。AWS 对部分大规模故障公开了事后摘要，但并非所有事件都会公开。设计的前提应放在设计目标和各服务的动作规格上，而不是个别公开报告。其他公司也发生过同类事件。2023 年 8 月澳大利亚东部区域的故障中，电压下降导致冷却装置停机，Microsoft 公开的事后审查将影响范围界定为 3 个可用区中 1 个可用区内的一部分。无法从一家公司的故障案例中读出其他公司隔离程度的优劣。可作为判断依据的是各公司公开的设计标准，以及事后审查以何种粒度公开的运营姿态。
多可用区设计最佳实践
即使可用区隔离再优秀，如果应用端未以多可用区为前提设计，也无法获得其益处。AWS 提供了丰富的服务和工具来简化多可用区设计。RDS 的多可用区部署自动将主实例和备用实例放置在不同可用区，故障时自动故障转移。ELB（Elastic Load Balancing）将流量分发到已启用的多个可用区。跨可用区分发的 cross-zone load balancing 默认值因负载均衡器类型而异，Application Load Balancer 默认启用，Network Load Balancer 默认禁用。若要避免 NLB 因目标数量不均导致负载不均，需要显式启用该设置，或在每个可用区放置相同数量的目标。Auto Scaling 组将实例分布在多个可用区，当特定可用区不可用时在剩余可用区自动补充容量。不过，这些服务同样以「启用多个可用区」「为每个可用区确保足够容量」等用户侧设置为前提。若子网只建在一个可用区、Auto Scaling 组的最小实例数仍为 1、使用单可用区配置的 RDS，服务端的分散功能就不会发挥作用。多可用区设计不是选择支持的服务，而是有意识地选定各服务与可用区相关的每一项设置。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。