AWS 故障域设计 - AZ、区域、分区三层结构守护的可用性机制
解析 AWS 基础设施以 AZ（故障隔离）、区域（地理分离）、分区（政治分离）三层设计的原因，以及各层故障的波及范围，并结合具体案例说明。
什么是故障域
故障域（Fault Domain）是单一故障影响的范围。一根电源线断了会有多少台服务器停机，一台网络交换机故障会有多少台服务器无法通信，一个数据中心整体停电会影响多少服务——这些问题的答案定义了故障域的边界。AWS 的基础设施以 AZ（可用区）、区域（Region）、分区（Partition）三层故障域设计。各层独立发挥故障隔离功能，上层故障不会波及下层，下层故障也不会波及上层。这种多层防御使得即使发生大规模故障，影响范围也能被限制在特定层内。
AZ 的故障隔离 - 电力、冷却、网络的独立性
AZ 是 AWS 故障隔离的最小单位。每个 AZ 由一个或多个数据中心构成，电力系统、冷却系统、网络连接全部独立。同一区域内的 AZ 之间通过专用高带宽低延迟网络连接，但物理上相距数十公里以上。这种设计确保一个 AZ 的电力故障、冷却故障、网络故障不会波及其他 AZ。AZ 间延迟通常在 2 毫秒以下，足以支持同步复制。Multi-AZ 部署将资源分布在多个 AZ 中，即使一个 AZ 完全停止服务也能继续运行。RDS Multi-AZ、ELB 跨 AZ 分配、Auto Scaling 的 AZ 分散等，AWS 的许多服务都内置了 AZ 级别的故障隔离。
区域的地理分离 - 应对自然灾害和大规模故障
区域是部署在地理上分离位置的独立基础设施。每个区域拥有独立的控制平面（管理资源创建、变更、删除的系统），与其他区域的控制平面独立运作。这种设计确保即使某个区域发生大规模故障（自然灾害、大范围停电等），其他区域完全不受影响。区域间的数据复制默认不进行。S3 对象、DynamoDB 表、RDS 数据库等都存储在创建时指定的区域内。跨区域复制需要明确配置（S3 CRR、DynamoDB Global Tables、Aurora Global Database 等）。这种默认不复制的设计是数据主权的基础——数据不会在未经客户明确同意的情况下离开指定区域。
分区的政治分离
AWS 的分区是出于政治和法律原因完全分离的基础设施。存在商用分区（aws）、中国分区（aws-cn）、GovCloud 分区（aws-us-gov）三个。各分区拥有独立的 IAM、独立的账户体系、独立的服务端点。商用分区的 IAM 用户无法访问中国分区的资源，反之亦然。中国分区由中国当地合作伙伴（光环新网、西云数据）运营，满足中国的数据本地化法规。GovCloud 分区仅限美国公民运营，满足 ITAR 和 FedRAMP High 等美国政府的严格安全要求。分区间的完全隔离确保一个分区的政治或法律变化不会影响其他分区的运营。
基于故障域的架构设计
理解三层故障域结构后，根据工作负载的可用性要求选择设计。单 AZ 构成适用于开发测试环境或允许停机的批处理。成本最低但 AZ 故障时服务停止。Multi-AZ 构成适用于大多数生产工作负载。跨 2-3 个 AZ 分布资源，单个 AZ 故障时自动故障转移。Multi-Region 构成适用于全球服务或要求极高可用性的关键系统。跨多个区域部署，即使整个区域故障也能继续服务。成本最高但可用性也最高。如果想系统学习可用性设计，专业书籍 (Amazon)可供参考。