中心辐射型网络拓扑：Azure 和 AWS 架构图

第一个云网络很简单。到了第十个，就会出现一张对等连接织成的网、三条通往办公室且配置各不相同的 VPN 隧道、每个网络里都复制了一份防火墙，而且没人能确定地说出谁能访问谁。中心辐射型（hub-and-spoke）架构是摆脱这种局面的标准做法：用一个中心网络承担共享连接和流量检查，工作负载则放在相互隔离、只能经由中心网络连接的分支（spoke）中。

本文先解释这种拓扑，再借助架构图把它搭建两次：在 Azure 中用中心虚拟网络和对等互连，在 AWS 中用 Transit Gateway。文中还会讨论路由与分段、流量检查、集中出口、让团队意外的成本，以及什么时候托管的中心是更好的选择。

为什么全网状互连会失控

把每个网络都与其他所有网络直接相连，需要 n(n−1)/2 条连接。10 个网络需要 45 条，50 个网络需要 1,225 条，每条都有自己的路由和安全规则。而且在两朵云里，对等互连都不具备传递性：A 与 B 对等、B 与 C 对等，A 仍然无法经由 B 访问 C。中心辐射型设计每个分支只需要一条连接，中心成为路由和安全策略唯一的所在之处。

中心里放什么

工作负载不该放在中心。分支承载应用，通常每个应用、团队或环境一个，这样一个分支里的错误不会蔓延到其他分支。

Azure 中的中心辐射型架构

Microsoft 的中心辐射型参考架构把 Azure Firewall、VPN 或 ExpressRoute 网关以及 Azure Bastion 放在中心虚拟网络中，各自位于专用子网。Azure Firewall 需要至少 /26 的子网。分支通过虚拟网络对等互连连接到中心，Microsoft 将其描述为不可传递：对等的网络可以相互通信，但不能经由彼此转发。

由此带来两个结果：

• 网关共享需要显式配置。 中心一侧的对等互连允许网关传输，每个分支使用远程网关，这样分支就能经由中心的网关访问本地网络。
• 分支之间的流量需要路由。 每个分支中的用户定义路由把发往其他分支的流量（通常还有默认路由）发送到防火墙的私有 IP。防火墙转发策略允许的流量。另一种做法是用 Azure Virtual Network Manager 大规模管理对等互连和连接组；在特殊情况下，两个分支之间直接对等互连也仍是一种选择。

如果想要由 Microsoft 托管的中心，Azure Virtual WAN 提供内置路由、网关和可选防火墙的中心，代价是对细节的控制更少。

AWS 中的中心辐射型架构

在 AWS 中，中心通常是 Transit Gateway，一个区域级路由器，VPC、VPN 连接和 Direct Connect 网关都挂载到它上面：

• 分支是 VPC 挂载。根据 Transit Gateway 配额，一个 Transit Gateway 默认支持 5,000 个挂载，规模远超对等互连的网状结构。
• 分段依靠 Transit Gateway 路由表实现。生产挂载关联一张路由表，开发挂载关联另一张，二者永远学不到对方的路由，但都能访问共享服务 VPC。
• 流量检查在专用的检查 VPC 中进行，里面运行 AWS Network Firewall，或部署在 Gateway Load Balancer 之后的第三方设备。分支的路由表指向 Transit Gateway，Transit Gateway 的路由再把流量送经检查 VPC。
• 在检查 VPC 的挂载上启用设备模式，可以让一个流的往返两个方向保持在同一个可用区，有状态防火墙需要这一点。
• 集中出口：用一个带 NAT 网关的出口 VPC 服务所有分支，而不是在每个 VPC 中各建 NAT 网关。

对于跨越许多区域的全球网络，AWS Cloud WAN 扮演的角色相当于 Azure 中的 Virtual WAN：一个带有基于策略的分段的托管核心网络。

两朵云对比

路由、分段与对称性

三条规则让中心辐射型网络的行为可预测：

1. 默认路由指向中心。 分支把所有非本地流量都发往中心，这样就不会有流量意外绕过检查。
2. 分段要显式定义。 决定哪些分支可以与哪些分支通信：生产和开发通常不能互通，共享服务通常处处可达，访问本地网络则要经过防火墙。
3. 回程流量必须走同一条路径。 有状态防火墙会丢弃它没见过去程的响应。非对称路由是“防火墙规则明明在，可就是不通”最常见的原因。

在第一个分支出现之前就把地址规划写下来。分支之间或分支与本地网络之间重叠的 CIDR 范围无法经由中心路由，事后修复也很痛苦。

成本

穿过中心的每一个字节都会在某处计费。在 AWS，截至撰写本文时（2026 年 11 月），美国东部（弗吉尼亚北部）的 Transit Gateway 定价是每个挂载每小时 $0.05，每处理 1 GB 数据 $0.02。10 个分支挂载在没有任何流量时就大约需要 10 × $0.05 × 730 小时，约合每月 $365。10 TB 的分支间流量会再增加约 10,240 GB × $0.02，约 $205 的处理费用，另外还有防火墙自身的处理费用。在 Azure 中，对等流量在对等连接的两端都按 GB 计费，Azure Firewall 还会另收处理费用。

通常的优化是有针对性的：保留中心来执行策略，只为某一对交换数据量极大且无需检查的分支添加直接对等互连。

什么时候不该用中心辐射型架构

• 只有两三个网络时不需要中心，直接对等互连更简单。
• 对延迟敏感的东西向流量在每个数据包上都要多一跳并经过防火墙。在把一对频繁通信的服务送去检查之前，先测量一下。
• 巨大的内部流量可能让按 GB 计的处理费成为最大的网络成本。为这些流量建立直接对等互连往往是值得的。
• 超大规模的多区域环境，用托管中心（Virtual WAN 或 Cloud WAN）可能比手工搭建路由表更合适。

中心辐射型架构图

这张图的读法如下：

• 顶部的本地网络与每朵云各连接一次：连到 Azure 中心的网关和 AWS 的 Transit Gateway。
• Azure 框架展示带防火墙和 VPN 网关的中心虚拟网络，以及与它对等互连的两个分支。分支之间的流量经过防火墙。
• AWS 框架展示位于中间的 Transit Gateway、带防火墙的检查 VPC，以及挂载到它上面的两个分支 VPC。
• 连线标签标明连接类型：对等互连、挂载、VPN 或专线。
• Markdown 块列出了路由规则和上文的成本数字。

画出经得起评审的网络拓扑图

• 在每个网络上写明 CIDR 范围。 评审者首先检查的就是地址重叠。
• 把防火墙画在流量实际经过的位置，并标出指向它的默认路由。
• 给每条连接标注类型。 对等互连、挂载和 VPN 的行为和费用都不同。
• 每个区域一张图。 把多区域网络画在同一张画布上，往往会把真正重要的跨区域链路淹没。

单个网络的内部结构见 AWS VPC 架构图。网络拓扑图概述了物理和逻辑拓扑，零信任架构图解释了为什么不应仅凭网络位置授予访问权限。多区域设计见 AWS 多区域架构图。

在 Archboard 中构建

1. 使用 Google 或 GitHub 登录，并新建一张图。
2. 在顶部添加一个基础节点包中的 方框，表示本地网络。
3. 为 Azure 添加一个基础 框架。在其中添加一个网络节点包中的 VPC 节点表示中心虚拟网络，并在它里面放一个 防火墙 和一个表示 VPN 网关的 设备 节点；再为两个分支添加两个 VPC 节点，各自写上 CIDR。
4. 为 AWS 添加一个基础 框架。在其中添加一个网络节点包中的 路由器 表示 Transit Gateway，一个内含 防火墙 的 VPC 节点表示检查 VPC，以及两个表示分支的 VPC 节点。
5. 把本地网络连接到 Azure 网关和 Transit Gateway，把各分支连接到各自的中心，并为每条连线标注连接类型。
6. 添加一个基础节点包中的 Markdown 块，写上路由规则和成本。

这个示例共用 14 个图表节点，在 Free 套餐的限制之内。

常见问题

什么是中心辐射型网络拓扑？ 一种设计：一个中心网络承载共享的连接、安全和服务，每个工作负载网络（分支）只连接到中心。分支之间以及通往本地网络的流量都经过中心。

虚拟网络对等互连具有传递性吗？ 没有，Azure 和 AWS 都是如此。与同一个中心对等的两个分支无法经由中心互访，除非路由把它们的流量发送到中心里的防火墙或路由器。

Transit Gateway 和 VPC 对等互连有什么区别？ VPC 对等互连直接连接两个 VPC，不具备传递性。Transit Gateway 是一个区域级路由器，许多 VPC 和本地连接都挂载到它上面，并用路由表实现分段。

我应该用 Azure Virtual WAN 代替中心虚拟网络吗？ Virtual WAN 适合希望由 Microsoft 管理中心路由和网关的大型或多区域环境。自管的中心控制力更强，在一两个区域、少量分支的场景中很常见。

中心辐射型架构的成本如何？ 中心连接和处理的流量按小时和按 GB 计费，另加防火墙处理费用。在 AWS，截至撰写本文时，美国东部的 Transit Gateway 挂载每小时 $0.05，数据处理每 GB $0.02。

免费开始 — 1 个席位，无需信用卡。