AWS Transit Gateway：为何要向两个路由表传播路由？

首先纠正一个核心误解：附件关联路由表，仅决定该附件发起的出站流量使用哪个路由表选路，而非限制它只能和同路由表的附件互通。能不能和其他附件通信，是由双向的路由条目是否存在决定的。

关键概念拆解 #

• 关联路由表：是附件的“出站路由表”——当这个附件发起访问时，TGW会用这个路由表来查找目标前缀的下一跳。
• 路由传播：是把附件的前缀（比如VPC的CIDR）复制到指定的路由表里，让关联该目标路由表的附件能通过这个路由条目访问到当前附件。

你的实验结果解析 #

你假设“关联A但向A、B传播路由的附件X，可被B的附件Y访问但无法访问Y”，但实验结果并非如此，大概率是因为你的实验中，附件Y也把路由传播到了A路由表：

• 当Y把路由传播到A，X的关联路由表A里就有了Y的前缀，所以X发起访问Y时，能通过A路由表找到Y的路径，实现互通。
• 如果Y只把路由传播到B，没有传播到A，那么X的A路由表里没有Y的条目，X发起访问Y时会找不到路径，此时才会出现“Y能访问X，但X不能访问Y”的单向场景。

为什么支持向非关联路由表传播路由 #

这个设计是为了实现受控的跨隔离域访问，典型场景包括：

• 单向访问控制：比如生产VPC（关联Prod路由表）只把路由传播到Test路由表，测试VPC（关联Test路由表）的流量能访问生产，但生产VPC的Prod路由表里没有测试VPC的路由，生产无法主动访问测试，避免测试环境影响生产。
• 多隔离域共享资源：比如一个共享的存储VPC（关联Shared路由表），把路由传播到Prod、Dev两个路由表，那么Prod和Dev的VPC都能访问存储，但Prod和Dev之间因为路由表隔离（互相不传播路由），无法直接通信，实现资源共享同时保持业务域隔离。

内容的提问来源于stack exchange，提问作者YoavKlein