2. AWS全球基础设施与灾备拓扑

要设计可靠的灾备架构，第一步不是选服务，而是把 AWS 的“地理层级”看清楚。AWS 全球基础设施由若干彼此隔离的地理层级组成，每一层解决不同的故障域问题。理解这些层级之间的包含关系与隔离边界，才能判断一次故障会波及多大范围，以及灾备方案需要跨越哪一层。

四个关键层级及其故障域

区域（Region）是最高层级的地理隔离单元，例如 ap-northeast-1（东京）、ap-southeast-1（新加坡）、us-east-1（弗吉尼亚北部）。每个区域是独立的地理位置，拥有独立的电力、网络和冷却设施。区域之间默认不共享任何资源，一个区域整体不可用不会影响其他区域。区域是灾备的“最后一道防线”，也是跨区域复制的边界。

可用区（Availability Zone，AZ）是区域内部的隔离单元。一个区域通常包含 3 个或更多 AZ，每个 AZ 拥有独立的供电、冷却和物理网络，AZ 之间通过低延迟、高带宽的私有光纤互联。AZ 之间的距离通常在数十公里量级，足以避免同一场火灾、洪水或电网事故同时影响两个 AZ，又足够近以支持同步复制。AZ 是“高可用”的主战场：多 AZ 部署可以抵御单 AZ 故障，但无法抵御区域级故障。

边缘站点（Edge Location / Point of Presence）是面向终端用户的内容分发与接入层，全球有数百个。它承载 CloudFront 缓存、Route 53 解析、AWS Global Accelerator 接入点、Shield 防护等。边缘站点不运行业务计算，它的价值在于把内容与连接入口推到离用户更近的位置，降低延迟并吸收流量型攻击。边缘站点不是灾备的“计算承载层”，但它是流量切换与用户接入路径上的关键一环。

本地扩展区（Local Zone）是把区域内的计算、存储、数据库等服务延伸到更靠近特定城市的位置，通常部署在大型都市圈。它隶属于某个父区域，是父区域的延伸而非独立区域。Local Zone 适合对延迟极敏感的场景（如实时渲染、游戏、媒体处理、工业质检），也可作为区域内的补充部署点。需要注意：Local Zone 与父区域之间仍有网络依赖，不能当作独立的区域级灾备目标。

多 AZ 与多 Region 的分工

多 AZ 与多 Region 解决的是两类不同的问题，不能互相替代。

多 AZ 解决高可用（HA）。把应用同时部署在至少两个 AZ，配合 ELB 跨 AZ 分发流量、RDS 多 AZ 同步备库、S3 自动跨 AZ 冗余，可以在单个 AZ 失效时保持服务不中断。多 AZ 的目标是 RTO 接近零、RPO 接近零，但它假设区域本身仍然可用。典型做法是：子网按 AZ 划分，Auto Scaling 组跨 AZ 分布，数据库开启多 AZ 部署，S3 使用标准存储类（本身已跨 AZ 冗余）。

多 Region 解决灾难恢复（DR）。当整个区域不可用时，只有把业务切换到另一个区域才能恢复。多 Region 的核心是数据复制与流量切换：数据层用 S3 跨区域复制（CRR）、Aurora 全局数据库、DynamoDB 全局表或 RDS 跨区域只读副本；流量层用 Route 53 故障转移路由或 Global Accelerator 做健康检查与切换。多 Region 的 RTO/RPO 取决于复制方式——异步复制通常有秒级到分钟级 RPO，同步复制成本高且受距离限制。

四种常见灾备拓扑

按成本与恢复能力递增，可以归纳为四类拓扑：

• 备份与恢复（Backup & Restore）：灾备区域只存备份数据，不运行计算。故障时用 AMI、快照、S3 备份重建环境。成本最低，RTO 通常数小时，RPO 取决于备份频率。
• 指示灯（Pilot Light）：灾备区域保留最小核心（如数据库副本、复制好的 AMI），计算资源平时关闭或极小。故障时快速扩容。RTO 数十分钟，成本较低。
• 温备（Warm Standby）：灾备区域运行一套缩小版但可用的完整环境，持续接收数据复制。故障时把流量切过去并扩容。RTO 数分钟，成本中等。
• 多区域主动-主动（Active-Active）：两个区域同时承载生产流量，数据双向或单向同步。RTO 接近零，成本最高，且需要处理数据冲突与一致性。

设计时的关键判断

选择拓扑时，先明确业务要求的 RTO 与 RPO，再反推需要哪一层冗余。若 RTO 要求分钟级以内，多 AZ 是底线，多 Region 是必要补充；若 RTO 允许数小时，备份与恢复即可满足。同时要检查依赖链：数据库复制方向、DNS TTL、证书与密钥是否在灾备区域可用、IAM 与安全组是否已同步、第三方依赖是否也具备区域冗余。很多灾备失败并非计算资源没起来，而是这些“看不见的依赖”没有跨区域准备。

一个可参考的拓扑选择表

把这张表与前面的层级图结合使用：先确定业务能承受的 RTO/RPO，再决定是只做多 AZ、还是必须跨 Region，最后选择对应的拓扑与复制技术。这样灾备设计才有明确的依据，而不是凭感觉堆资源。