📚 课程目录第2章 AWS全球基础设施与网络拓扑

2. AWS全球基础设施与网络拓扑

做多区域灾备，第一步不是画切换流程，而是把 AWS 全球基础设施的“层级”和“连接方式”看清楚。因为不同组件在灾备中承担的角色完全不同：有的决定故障域边界，有的决定用户接入路径，有的决定 VPC 之间怎么互通，有的决定专线流量怎么进出。选错层级，后面所有 RTO/RPO 设计都会失真。

一、五个核心对象的灾备角色

Region（区域）是最高层级的故障域，也是数据驻留和合规边界。每个 Region 由多个 AZ 组成，Region 之间默认网络隔离，跨 Region 通信必须显式建立连接（如 VPC Peering、Transit Gateway Peering、Direct Connect 或公网）。灾备中 Region 通常承担“主站点 / 备站点”角色，决定 RTO 的量级：同 Region 多 AZ 切换通常是分钟级，跨 Region 切换通常是十分钟到小时级。

AZ（可用区）是 Region 内的独立供电、制冷和网络故障域，AZ 之间通过低延迟光纤互联。AZ 是“高可用”的基本单位，而不是“灾难恢复”的基本单位——因为同一 Region 内多个 AZ 仍可能因区域级事件（如控制面故障、大范围网络问题）同时受影响。因此 AZ 用于抵御单机房故障，Region 用于抵御区域级灾难，两者是互补而非替代关系。

Edge Location（边缘站点）是 CloudFront、Global Accelerator、Route 53 等服务的接入点，靠近用户侧。它不承载业务数据，但决定用户“从哪个入口进来”。灾备中 Edge 层的价值在于：通过 Anycast IP 和健康检查，把用户流量快速导向健康 Region，而不依赖 DNS 缓存过期。Global Accelerator 的静态 Anycast IP 尤其适合需要固定入口 IP 的切换场景。

Transit Gateway（TGW）是区域级的网络枢纽，用于集中连接 VPC、VPN、Direct Connect。它的灾备角色是“连接编排中心”：通过 TGW Peering 可以把两个 Region 的 TGW 连起来，让跨 Region 的 VPC 互通不必逐对建 Peering。TGW 还支持路由表隔离和多播，适合多账号、多 VPC 的复杂拓扑。注意 TGW 本身是区域级资源，跨 Region 需要 Peering 或通过 Direct Connect 中转。

Direct Connect（DX）是专线接入，提供从本地数据中心到 AWS 的私有连接。灾备中 DX 的关键是“冗余”：单条 DX 在端口、设备、接入点、运营商链路上都可能故障。推荐至少两条 DX，且尽量落在不同接入点、不同运营商，并在 AWS 侧终结到不同设备。DX Gateway 可以把一条专线关联到多个 Region 的 VPC，是混合云灾备的常用形态。

二、选型原则：先定故障域，再定连接方式

选型时建议按以下顺序判断，而不是先挑服务：

先确定要抵御哪一级故障。只防单机房故障，多 AZ 即可；要防区域级灾难，必须跨 Region。这一步决定架构骨架，也决定成本量级。
再确定用户入口策略。如果用户遍布全球且要求快速切换，优先 Global Accelerator + 健康检查；如果只是静态内容加速，CloudFront 更合适；如果切换容忍 DNS TTL，Route 53 故障转移路由成本最低。
然后确定 VPC 间连接。VPC 数量少（2～3 个）可用 Peering；数量多、多账号、需要集中路由策略时用 Transit Gateway；跨 Region 互通优先 TGW Peering，而不是逐对 VPC Peering。
最后确定混合云专线。有本地 IDC 且要求稳定带宽、低延迟、数据不走公网时用 Direct Connect；需要连接多个 Region 时用 DX Gateway；对成本敏感或临时需求可用 Site-to-Site VPN 作为补充或备份。

选型口诀：AZ 管高可用，Region 管灾难恢复，Edge 管用户入口，TGW 管 VPC 互联，DX 管混合云专线。五者各司其职，不能互相替代。

三、一个可参考的灾备拓扑示例

假设某企业主业务部署在 ap-southeast-1（新加坡），灾备站点在 ap-northeast-1（东京），本地 IDC 在香港。一个合理的拓扑是：

两个 Region 各建 2 个 AZ 的业务 VPC，Region 内用 TGW 集中连接；
两个 TGW 之间建立 TGW Peering，用于跨 Region 的管控流量和数据库复制；
香港 IDC 通过两条不同运营商的 Direct Connect 接入，分别终结到不同接入点，再通过 DX Gateway 关联两个 Region 的 TGW；
用户入口使用 Global Accelerator，配置两个 Region 的端点组，健康检查失败时自动切换；
Route 53 作为辅助，用故障转移路由处理非 GA 覆盖的域名。

这个拓扑中，AZ 故障由 Region 内多 AZ 吸收；Region 故障由 GA 切换 + 跨 Region 数据复制吸收；专线故障由双 DX + VPN 备份吸收。每一层都有明确的故障域和恢复手段，RTO/RPO 才能被逐层估算。

四、常见误区

误区一：把多 AZ 当成多 Region 灾备。多 AZ 解决的是单机房故障，Region 级事件（如控制面异常、大范围网络抖动）仍会影响整个 Region。真正的灾难恢复必须跨 Region。

误区二：只建一条 Direct Connect。单条 DX 在端口、设备、接入点、运营商链路上都是单点。至少两条，且尽量不同接入点、不同运营商，否则“专线冗余”只是纸面冗余。

误区三：跨 Region 用 VPC Peering 逐对连接。VPC 数量增长后 Peering 数量呈平方级上升，路由管理复杂。多 VPC 场景应优先 TGW + TGW Peering。

误区四：忽略 Edge 层的切换速度。DNS 切换受 TTL 和递归解析缓存影响，实际生效可能远超预期。对切换速度敏感的业务，应优先 Global Accelerator 的 Anycast IP 方案。

注意：Transit Gateway 和 Direct Connect 都是区域级资源，跨 Region 使用需要显式建立 Peering 或通过 DX Gateway 关联。设计时务必确认资源所在 Region，避免把区域级资源误当成全球资源。

把 Region、AZ、Edge Location、Transit Gateway、Direct Connect 五者的故障域和连接关系理清后，后续的切换流程、数据复制和验证方案才有稳定的设计基础。选型的本质不是选“最好的服务”，而是选“与业务 RTO/RPO 和故障域匹配的组合”。