AWS 可用区设计 - 物理隔离与故障隔离带来的可靠性差异
解析 AWS 可用区作为物理独立数据中心群的设计理念，与 Azure 和 GCP 的可用区对比，通过实际故障案例阐述故障隔离成熟度的差异。
可用区各云都有，但并不相同
AWS、Azure 和 GCP 都提供「可用区」（Availability Zone）的概念。通过将资源分布在多个区域来消除单点故障、实现高可用性的基本思路是共通的。然而，其实现细节存在巨大差异。AWS 从 2006 年 EC2 推出之初就引入了可用区概念，此后 18 年以上持续完善设计。Azure 于 2018 年正式提供 Availability Zones，GCP 将区域概念整理为当前形态也是相对较近的事。这一时间差直接关系到设计成熟度和运维经验的积累。
AWS 的可用区设计 - 彻底的物理隔离
AWS 的每个可用区由一个或多个物理独立的数据中心组成。AWS 公开了关于物理隔离的具体设计标准。每个可用区拥有独立的电力供应源，从不同变电站供电。冷却系统和网络连接也各自独立。可用区之间的距离在维持低延迟通信的范围内（通常 100km 以内），同时保证足够远以使洪水、地震、火灾等局部灾害不会同时影响多个可用区。这一设计的核心是「故障域的完全隔离」。某个可用区发生电力故障时，相邻可用区不受影响。网络设备故障、冷却系统异常，甚至建筑级别的灾害，影响都被封锁在该可用区内。AWS 将此称为「blast radius（爆炸半径）最小化」，物理限制故障影响范围的设计哲学始终一贯。
Azure 的 Availability Zones - 后发者的课题
Azure 于 2018 年引入 Availability Zones，但并非所有区域都支持可用区。截至 2025 年，仍有多个区域不支持可用区。在日本，西日本区域不支持可用区，仅东日本区域提供可用区。此外，关于 Azure 可用区的物理隔离程度，未像 AWS 那样公开详细信息。Azure 说明为「拥有独立电力、冷却和网络的一个或多个数据中心」，但未明示可用区间距离或具体隔离标准。Azure 的历史背景也有影响。Azure 最初以 Availability Sets（通过故障域和更新域进行逻辑隔离）作为可用性的基本单位。可用区是后来追加的概念，在与现有服务和架构保持一致的同时逐步展开。在这一过渡过程中，部分服务的可用区支持滞后，或可用区间故障转移行为不如 AWS 成熟。
GCP 的区域设计 - 不同的方式
GCP 的区域在概念上与 AWS 的可用区类似，但设计方式不同。GCP 在每个区域通常配置 3 个区域，构建在 Google 大规模全球网络之上。GCP 的优势在于 Google 多年运维大规模分布式系统的经验反映在区域设计中。Spanner 等全球分布式数据库以区域间复制为前提设计，对区域故障具有较高的容错能力。另一方面，GCP 每个区域标准为 3 个区域，不像 AWS 东京区域（4 个可用区）那样拥有 4 个以上可用区。区域数越多，资源分布配置的选择越多，特定区域发生故障时的影响也越小。此外，GCP 未像 AWS 那样公开区域物理隔离程度的详细信息，用户难以评估隔离程度。
从实际故障案例看可用区隔离的实效性
可用区设计的真正价值在实际发生故障时才能体现。AWS 过去经历了多次大规模故障，但大多数情况下可用区隔离按设计正常运作。2017 年的 S3 故障（us-east-1）虽因输入错误的操作失误引起，但影响仅限于特定子系统，其他区域和可用区的服务继续正常运行。2019 年 us-east-1 的电力故障中，受影响的仅是单个可用区内的实例，采用多可用区架构的工作负载无中断地继续运行。AWS 在这些故障后发布详细的事后分析报告，透明地说明发生了什么、为何可用区隔离发挥了作用（或未按预期运作时的原因）。这种透明性本身就是可用区设计可靠性的佐证。Azure 也发生过故障，但 2023 年澳大利亚东部区域的故障中，报告了冷却系统问题波及多个区域的案例。这暗示可用区间的物理隔离可能不如 AWS 彻底。
多可用区设计最佳实践
即使可用区隔离再优秀，如果应用端未以多可用区为前提设计，也无法获得其益处。AWS 提供了丰富的服务和工具来简化多可用区设计。RDS 的多可用区部署自动将主实例和备用实例放置在不同可用区，故障时自动故障转移。ELB（Elastic Load Balancing）默认将流量分发到多个可用区。Auto Scaling 组将实例分布在多个可用区，当特定可用区不可用时在剩余可用区自动补充容量。这些服务之所以具有可用区感知设计，是因为 AWS 从一开始就将可用区概念作为核心来构建服务。后来才添加可用区的 Azure 中，部分服务的可用区支持作为「选项」提供，默认不启用多可用区的情况存在。这一差异源于设计初期是否以可用区为前提这一架构根本性的不同。