可用区的意思是「建筑物不一样」

一句话总结

Region是彼此相隔的地理区域，**可用区（AZ）**则是其中供电、制冷和网络相互独立的一组数据中心。准确区分这两个词，就解决了可用性设计的一半问题。

为什么需要它

打开一份标着“已经冗余”的架构图，经常会发现两台服务器其实位于同一个机架。在本地数据中心里，这一点肉眼可见；在云上却看不见——启动两个实例时，如果我们不指定放置位置，它们可能落在同一处。

因此，云平台会明确命名并公开隔离单位，这就是 AZ。

单位	哪些部分相互独立	哪些部分共享
可用区（AZ）	供电、制冷、物理网络、建筑物	Region 内的低延迟骨干网
Region	地理位置、法律管辖区，通常还包括电网	无（完全分离）
Edge Location	缓存节点	源站位于 Region 中

AZ 之间的延迟约为 1～2ms，因此同步复制是实用的。Region 之间的延迟则为数十到数百 ms，同步复制实际上不可行。仅这一组数字，就形成了“多 AZ 是基础配置，多 Region 是重大决策”这条实践规则。

选择 Region 的比较标准

各厂商的名称

概念	AWS	Azure	GCP
Region	Region	Region	Region
可用区	Availability Zone	Availability Zone	Zone
Region 内分组	—	Region Pair（不同概念）	—

Azure 的部分 Region 没有 AZ，只提供可用性集。这意味着“采用多 AZ”的决定可能会限制 Region 的选择。

根据什么选择 Region

1. 法律与监管——如果存在个人信息不得传出境外的要求，到这里就已经决定了选择。这是韩国公共与金融项目最先遇到的条件。
2. 延迟——与用户的物理距离越近越好。首尔 Region 与东京 Region 的延迟相差约 30～40ms。
3. 服务可用性——并非所有 Region 都提供所有服务。新服务通常会先在弗吉尼亚（us-east-1）上线。
4. 价格——不同 Region 的价格不同，同一种实例的价格差距有时会超过 20%。

每个账户中的 AZ 名称并不相同

AWS 的 ap-northeast-2a 在不同账户中可能指向不同的物理 AZ。这是为了均匀分散负载；因此，即使双方都说“我们使用 2a”，也未必是同一地点。需要跨账户对齐物理位置时，应使用 AZ ID（apne2-az1）。

实际工作中的表现

• 已部署为多 AZ，却在一个 AZ 故障时停止服务 → 数据库仍是单 AZ。
• 整个 Region 故障 → 多 AZ 无法防止。Region 故障很少见，但确实会发生。
• 因该 Region 没有某项服务而被迫修改设计 → 应在选择 Region 前确认。

接下来阅读什么

责任共担模型——一张用来确定在这套基础设施中哪些部分由我们负责的图。