2. AWS多区域架构基础
要设计好多区域高可用与灾备架构，第一步不是画箭头，而是把 AWS 的“地理层级”和“网络接入层级”分清楚。很多架构事故并非出在服务选型，而是把不同层级的概念混用：把边缘站点当成可部署计算资源的位置，把本地区域当成独立区域，或者误以为波长区域可以承载通用工作负载。本章先建立一张清晰的地理与接入地图，再讨论多区域架构的常见模式与反模式。
一、五个核心概念：它们各自解决什么问题
区域（Region）是 AWS 的独立地理集群，例如 us-east-1、ap-southeast-1、eu-west-1。每个区域拥有独立的电力、冷却、网络和故障域，区域之间默认通过 AWS 骨干网互联。区域是“故障隔离”和“数据驻留”的基本单位，也是多区域架构的主战场。选择区域时通常看四件事：合规与数据主权、与用户或数据源的网络时延、区域内服务与实例类型的可用性、以及成本差异。
可用区（Availability Zone, AZ）是区域内的一个或多个物理数据中心，具备独立供电、冷却和网络。同一区域内多个 AZ 之间通过低时延链路互联，典型往返时延在 1～2 ms 量级（示例值，实际以区域为准）。AZ 是“高可用”的基本单位：把无状态服务跨 2～3 个 AZ 部署，可以抵御单机房故障。注意 AZ 名称在不同账号间可能映射到不同物理机房，跨账号做 AZ 对齐时应使用 AZ ID（如 use1-az1）而非 AZ 名称。
边缘站点（Edge Location）是 CloudFront、Route 53、Global Accelerator、AWS Shield 等全球接入服务的落地点，数量远多于区域。它不用于部署 EC2 或 RDS，而是承担内容缓存、DNS 解析、Anycast 入口和 DDoS 清洗。边缘站点解决的是“用户到入口的第一跳”问题，而不是“计算放在哪里”的问题。
本地区域（Local Zone）是区域的一种延伸，把计算、存储等资源放到更靠近特定大都市的位置，但仍归属于某个父区域。它适合对时延极敏感的场景，例如实时渲染、视频转码、游戏服务器、工业质检。使用本地区域时要注意：它通常只提供部分实例类型和服务，且需要显式在 VPC 中创建子网并关联；跨本地区域与父区域之间仍有网络时延，不能当作同一 AZ 使用。
波长区域（Wavelength Zone）是把 AWS 计算和存储嵌入到电信运营商的 5G 网络边缘，主要面向超低时延的移动边缘应用，例如车联网、AR/VR、云游戏。它同样归属于某个父区域，通过运营商网络接入，适合把计算下沉到离终端最近的位置。波长区域不是通用区域，服务覆盖和实例类型都更受限。
二、选型原则：先定约束，再定层级
选型不要从“哪个区域便宜”开始，而应从约束出发。第一层约束是合规与数据主权：如果数据必须留在境内，可选区域就被限定。第二层是时延目标：若要求端到端 50 ms 以内，需要计算用户与入口的距离，边缘站点负责第一跳，本地区域或波长区域负责近端计算，区域负责集中数据与全局服务。第三层是可用性目标：RTO/RPO 决定是否需要多区域热备、温备还是冷备。第四层才是成本：跨区域数据传输、跨区域复制、重复资源都会显著增加账单。
一个实用的判断顺序是：先问“数据能不能出区域”，再问“用户离哪里近”，再问“故障时允许多久不可用”，最后问“预算能承受多少冗余”。例如面向东南亚用户的电商系统，主区域选 ap-southeast-1，灾备选 ap-southeast-3；对新加坡本地时延敏感的游戏服务，可在新加坡本地区域部署对战服务器，而账号与订单数据仍放在父区域。
三、常见多区域模式
主动-被动（Active-Passive）：主区域承载全部流量，灾备区域保持数据复制和最小资源，故障时通过 Route 53 健康检查切换。适合 RTO 分钟级、预算有限的场景。关键是定期演练切换，否则灾备区域容易“配置漂移”。
主动-主动（Active-Active）：两个或多个区域同时承载流量，通过 Route 53 延迟路由或 Global Accelerator 分流。它提供更高的可用性和更低的用户时延，但要求数据层支持多主写入或冲突解决，例如 DynamoDB Global Tables、Aurora Global Database 的写转发。成本最高，复杂度也最高。
读写分离与就近读取：写请求集中到主区域，读请求分发到多个区域的只读副本。适合读多写少的业务，例如内容平台、商品目录。要注意副本延迟带来的“读己之写”问题，必要时在会话层做粘性路由。
分区隔离（Cell-Based）：把用户按地理或租户切分到不同区域，每个区域独立服务一部分用户。它天然限制故障爆炸半径，但需要处理跨区用户迁移和全局唯一性约束。
四、反模式：看起来合理，实际会埋雷
- 把本地区域当独立区域用：本地区域归属父区域，父区域故障时它未必能独立存活，且服务覆盖有限。
- 用边缘站点承载计算：边缘站点只做缓存、DNS 和入口，不能部署 EC2/RDS，误用会导致架构无法落地。
- 多区域但共享单点数据库：计算分散到多区域，数据库仍只有一个主库，跨区域写时延和故障域反而被放大。
- 只做备份不做切换演练：备份存在不等于能恢复，未演练的灾备切换往往在真实故障中失败。
- 忽略跨区域数据传输成本：主动-主动模式下，跨区域复制和同步写入可能成为账单大头。
- AZ 名称跨账号对齐：不同账号的 us-east-1a 可能对应不同物理机房，跨账号部署应使用 AZ ID。