为什么需要Transit Gateway来打通跨账号多VPC？
在单账号单VPC阶段，网络结构简单，直接用VPC Peering或VPN就能连通。但当业务扩张到数十个甚至上百个VPC，且分散在多个AWS账号中时，VPC Peering的网状连接数量呈O(n²)增长，路由表维护变成噩梦。Transit Gateway（以下简称TGW）作为中心辐射型（Hub-and-Spoke）的云上路由器，天然解决了这个问题——只需在每个VPC侧创建一个Attachment连到同一个TGW，由TGW负责路由分发。跨账号场景下，TGW还支持Resource Access Manager（RAM）共享，让网络管理员在一个中心账号下管理所有VPC的互联。
Transit Gateway核心概念与跨账号机制
TGW本身是一个逻辑路由器
它不依赖物理设备，具备高可用性（每个AZ部署一个Endpoint）。你需要在TGW上创建“Transit Gateway Attachment”来连接VPC、VPN、Direct Connect Gateway或另一个TGW（Peering）。每个Attachment关联一个VPC的子网（每个AZ至少一个），TGW会自动将子网路由注入到VPC路由表中（需启用“自动传播”）。
跨账号共享：通过AWS RAM
假设中心账号A创建了TGW，账号B、C需要将自己的VPC挂载到该TGW上。账号A需要在RAM中创建一个资源共享，将TGW的ID共享给账号B、C（或整个组织）。账号B、C接受共享后，即可在自己的账号内创建Attachment（选择共享的TGW），后续由中心账号统一管理路由表。注意：Attachment本身属于创建者账号，但路由传播和策略由TGW所有者控制。
全互联架构设计：路由表与隔离策略
“全互联”意味着任意两个VPC之间都能直接通信，但这往往带来安全风险：生产环境通常需要部分隔离（如开发VPC不能访问生产数据库）。TGW通过“路由表（Route Table）”和“关联（Association）/传播（Propagation）”机制实现灵活隔离：
- 关联（Association）：每个Attachment必须关联到一个TGW路由表，决定该Attachment发出的流量如何路由。
- 传播（Propagation）：Attachment可以将自己的网段信息传播到指定的TGW路由表，让其他Attachment知道如何到达它。
实现全互联的标准做法：创建一个TGW路由表（例如名为“Full-Mesh”），将所有VPC的Attachment都关联到该路由表，并且每个Attachment都将其路由传播到该路由表。这样，每个Attachment发出的流量都能到达所有其他传播了路由的Attachment。如果某些VPC需要隔离，只需将它们分配到不同的TGW路由表，且不互相传播即可。
实践操作：分步骤搭建跨账号全互联网络
前提条件
- 两个或以上AWS账号，已启用AWS Organizations（可选，但推荐）。
- 每个账号至少有一个VPC，且VPC的CIDR不重叠（重叠CIDR会导致路由冲突，TGW不支持NAT或重映射）。
- 确认各VPC内有至少两个子网（公网或私网均可），每个子网在一个可用区内。
步骤一：在中心账号创建TGW
登录中心账号（网络管理员账号），进入VPC控制台 → Transit Gateway → 创建。关键配置：
- Amazon side ASN：建议使用默认64512或其他私有ASN，若需要与on-premise BGP互连则需规划。
- DNS support：启用后TGW会自动转发DNS查询到VPC的Resolver，跨账号场景下注意安全组配置。
- VPN ECMP support：如果未来需要多个VPN隧道负载均衡，可开启。
创建完毕后记录TGW ID（tgw-0xxxxxxxx）。
步骤二：通过RAM共享TGW
在中心账号中，打开RAM控制台 → 资源共享 → 创建资源共享。指定TGW资源，选择“允许外部账号”或“仅限组织内”。输入目标账号ID（或OU）。每个目标账号需要手动接受共享邀请（也可通过RAM自动接受组织级策略）。
步骤三：每个目标账号创建VPC Attachment
登录目标账号（如账号B），在VPC控制台 → Transit Gateway Attachments → 创建。选择“VPC”类型，在“Transit Gateway ID”下拉框中选择共享过来的TGW（注意：只有账号B接受了共享才会出现）。选择要连接的VPC和子网（每个AZ至少选一个子网，TGW会在这些子网中创建ENI）。其余默认即可。创建后等待状态变为“Available”。
步骤四：中心账号配置路由表与传播
回到中心账号的TGW控制台，找到刚创建的TGW。操作路由表：
- 创建路由表（例如“Full-Mesh”）。
- 将步骤三中创建的所有Attachment（包括中心账号自己的Attachment）都关联到该路由表。
- 对于每个Attachment，在其传播选项卡中添加向该路由表的传播。也就是说，每个Attachment都向“Full-Mesh”路由表传播自己的VPC CIDR。
此时TGW路由表中会动态学习到所有VPC的网段，自动形成全互联。
步骤五：调整VPC路由表
每个VPC子网的路由表需要指向TGW才能将流量发送到其他VPC。手动或自动（启用TGW自动传播时，TGW会向VPC路由表中添加指向自身Attachment的路由条目，目标为其他VPC的CIDR，下一跳为TGW Attachment ID）。如果子网内还有Internet Gateway或NAT Gateway，需要保证路由优先级正确（TGW路由优先级高于默认路由但低于特定前缀）。
验证：从账号A的VPC中一台EC2 ping账号B的VPC内私有IP，应能通。
关键注意事项与常见陷阱
CIDR不能重叠
TGW不提供地址转换，如果两个VPC使用相同CIDR（例如都是/16），则TGW路由表中只能保留一条，导致另一个VPC不可达。唯一的解决方法是重新规划IP或使用TGW Peering配合NAT，但极其复杂。建议在初始阶段统一规划IP段。
安全组和网络ACL
跨账号通信时，两端VPC的安全组仍需允许对方流量。由于TGW不修改IP，源IP为发送方VPC的实例IP，因此安全组规则需根据实际源CIDR开放。另外，每个VPC的子网中TGW创建的ENI会分配IP，这些IP不会影响安全组。
流量经过TGW的带宽与成本
TGW本身有最大吞吐（每个Attachment默认10 Gbps，可申请提升）。跨AZ流量会收取TGW处理费（每GB一定费用）以及跨AZ数据传输费。对于高流量应用，需评估成本并考虑在同一AZ内通信。
自动化与IaC
手动创建多个Attachment和路由传播容易出错。建议使用Terraform或AWS CloudFormation模板，配合RAM共享，实现一键部署。例如，中心账号定义TGW和路由表，子账号通过StackSet创建Attachment和传播。
监控与故障排查
开启VPC Flow Logs on all VPC to trace traffic via TGW. Use TGW Network Manager (part of AWS Network Manager) to visualize topology and monitor routes. If ping fails, check: 1) Attachment state (should be Available); 2) Route propagation (is the remote CIDR present in TGW route table and in VPC route table?); 3) Security groups and NACLs; 4) Source/Destination check on EC2 instances (should be disabled if instance does NAT).
扩展：混合云与多Region场景
如果有on-premise数据中心需要与跨账号VPC全球互联，可以通过Direct Connect Gateway或Site-to-Site VPN连接到TGW。多Region之间可以使用TGW Peering（跨区域TGW对等连接），但注意TGW Peering不支持通过RAM共享，必须在两个Region分别创建TGW并手动建立Peering。全互联愿景下，可以搭建全球TGW拓扑，但路由条目数量有限制（默认每个TGW路由表最多5000条，可提额）。
总结：跨账号多VPC全互联的理想方案是TGW + RAM + 统一路由表。它让网络从混乱的Peering网格变成清晰的中心辐射模型，运维成本大幅降低。但前提是IP规划、安全策略、成本评估都要提前做好。动手前先画拓扑图，用Terraform落地，并加上持续监控，才能让云网络真正稳定、可控。
延伸阅读