3. 多 VPC 网络拓扑设计原则

当企业从两三个 VPC 扩展到几十个 VPC 时，Transit Gateway（TGW）的拓扑选择就不再是"连上就行"，而是决定了后续路由复杂度、安全审计能力、故障爆炸半径和成本结构。本节先对比三种典型拓扑，再落到最容易被忽视、却最难补救的一环：CIDR 规划与地址重叠治理。

三种拓扑的本质差异

集中式（Hub-and-Spoke）：所有 VPC 只与一个（或一组）共享 TGW 建立附件，VPC 之间不直接互联。流量路径是 Spoke VPC → TGW → 目标 Spoke VPC。它的核心优势是策略集中：安全检测 VPC、出口 VPC、共享服务 VPC 都挂在同一个 TGW 上，路由表可以按"生产/开发/沙箱"分段隔离。代价是 TGW 成为逻辑单点，且跨 VPC 流量必须经过中心，可能带来额外的跨 AZ 数据处理费用。

分布式（Mesh / 多 TGW 对等）：每个业务域或每个区域拥有自己的 TGW，域内 VPC 就近接入，域间通过 TGW Peering 互联。它把爆炸半径限制在单个域内，适合组织边界清晰（如按子公司、按业务线）的大型企业。代价是路由表数量随域数量增长，Peering 是全互联还是部分互联需要提前规划，否则会出现"路由可达但策略不可控"。

混合式：主干用集中式 TGW 承载共享服务与安全检测，边缘按业务域部署分布式 TGW，两者通过 Peering 或共享附件连接。这是多数中大型企业的实际落地形态——既保留集中审计，又避免所有流量绕行中心。

选型判断：先看约束，再看偏好

不要先问"哪种拓扑最好"，而应先确认四个约束：合规是否要求所有跨 VPC 流量经过检测点；组织边界是否与网络边界一致；是否存在大量 VPC 间东西向流量；TGW 附件与数据处理费用是否敏感。若合规要求集中检测，集中式或混合式几乎是唯一选择；若东西向流量巨大且业务域之间几乎不互通，分布式能显著降低绕行成本。混合式的常见触发条件是：总部需要统一出口和审计，但各区域业务域之间不希望流量跨区绕行。

CIDR 规划：从"够用"到"可扩展"

TGW 本身不强制 CIDR 不重叠，但一旦两个 VPC 使用相同或包含关系的网段，路由就会产生歧义：TGW 路由表中最具体（最长前缀）的路由优先，若两条路由前缀长度相同，则无法确定性地选择，最终表现为"部分子网可达、部分不可达"这类极难排查的问题。因此 CIDR 规划的目标不是"现在不冲突"，而是"未来三年新增 VPC 时仍不冲突"。

推荐做法是采用分层地址块，把 RFC 1918 空间按"区域 → 环境 → 业务域 → VPC → 子网"逐级切分。例如企业总地址池为 10.0.0.0/8，可按如下方式分配：

按此规则，每个 VPC 固定占用一个 /24，预留 16 个 /24 给同一业务域，预留 64 个 /24 给同一环境。这样即使业务域从 1 个扩展到 10 个，也不会与既有地址冲突。注意 AWS 会保留每个子网的前 4 个和后 1 个 IP，因此 /26 子网实际可用 59 个地址，规划时不要按 64 计算。

避免地址重叠的四种手段

1. 建立 IPAM 或地址台账：在创建 VPC 之前先登记 CIDR，由网络团队统一分配，禁止业务团队自行选择网段。AWS VPC IPAM 可以把地址池与 TGW 组织绑定，从源头阻止重叠分配。
2. 预留"未来区"：把 10.0.0.0/8 中暂时不用的块标记为保留，例如 10.200.0.0/13 留给并购或临时项目，避免后期无地址可用。
3. 重叠后的补救：若两个 VPC 已经重叠且必须互通，可选方案包括：使用 PrivateLink 暴露具体服务而非整网互通；在重叠 VPC 前加 NAT 做地址转换；或重建其中一个 VPC 的网段。前两种能快速缓解，但都会增加架构复杂度，因此优先在规划阶段避免。
4. 与本地网络对齐：通过 VPN 或 Direct Connect 接入的本地数据中心网段必须纳入同一台账，否则会出现"云上不冲突、云下冲突"的情况。

一个可执行的规划检查清单

在 TGW 拓扑与 CIDR 方案定稿前，建议逐项确认：所有 VPC 与本地网段的 CIDR 是否已登记且无包含关系；TGW 路由表是否按环境或业务域分段，避免默认全通；集中式拓扑下安全检测 VPC 是否已加入所有需要检测的路由表；分布式拓扑下 TGW Peering 是否只连接必要的域；混合式拓扑下主干 TGW 与边缘 TGW 的路由传播方向是否明确；是否为未来 12 个月的新增 VPC 预留了连续地址块。完成这些确认后，再进入 TGW 附件与路由表的实际创建，可以显著减少后期返工。