为什么 AWS VGW 的子网路由不能只指定一条 VPN 隧道

两条 Site-to-Site VPN 连接都终结在同一个虚拟私有网关上，并宣告同一个分支前缀。子网路由表里只有一条指向该网关的条目，没有任何字段能点名某一条隧道。因此两条连接之间的优先级，发生在控制台并不把它叫作路由的地方。搞清哪一层拥有这个决定，就是可用备份与白改一场的分界。

两层在同时起作用：说明走哪个网关的 VPC 路由，以及网关自己对隧道的选择。把两者搅在一起，只会得到在路由表里看着正确、却一个包也搬不动的改动。

看着像一层的两层

子网路由只回答一个问题：这个目标走哪个连接。它的目标是虚拟私有网关，度量只与同一张表里的其他路由竞争。这条条目里没有任何东西区分隧道一与隧道二，也没有区分连接 A 与连接 B。更具体的前缀是另一个目标匹配，而不是更细的选路。

网关回答下一个问题：它为这个前缀持有的隧道中，当前哪一条在承载流量。这个决定来自隧道健康状态和从客户网关收到的 BGP 属性，从不出现在子网路由表里。

网关实际比较的是什么

健康状态优先。隧道断了，或者 BGP 会话没起来，在任何属性被查看之前就已经输了。这就是为什么在已经失效的连接上前置路径毫无作用。

同一前缀的可用路径中，网关偏好更短的 AS_PATH。两条路径等长时它比较 MED，并受文档中关于路径首个 AS 的条件约束。请读公开的判定顺序，而不是口口相传的版本，因为口口相传通常省略了健康状态这一步和静态路由的例外。一个推论：在备用连接上做三次前置，主连接就严格更短，而这正是表达偏好的常用手法。

前置，以及它何时不起作用

前置发生在客户网关的出向通告上，而不在网关内部。你把自己的 ASN 加两到三次到希望网关避开的前缀上，网关就会看到那条连接的路径更长。主连接保持不加前置的通告。如果两条连接从同一个 ASN 通告、前置次数也相同，那你就没有表达任何偏好。

改动之后，去网关侧核对收到的路径。一次从没离开客户设备的添加，看起来和一次被网关忽略的添加一模一样。

静态路由无视整套论证

如果连接使用静态路由，就没有可拉长的 AS_PATH。文档写明，对同一前缀，静态 VPN 路由优先于通过 BGP 学到的路由；所以混合设计不会表现得像全动态设计。先定路由类型，再选该类型下存在的偏好机制。

两条静态连接宣告同一前缀时，可用的杠杆就是前缀本身：在希望使用的那条连接上宣告更具体的一段，并接受你改变的是哪个目标被匹配，而不是哪条路径胜出。

为什么中转网关是另一个答案

中转网关支持跨 VPN 连接的等代价多路径，所以两条连接可以分担流量，而不是一条干等。那种设计的故障面不同：流会分散到各条隧道上，一条隧道挂掉只搬走一部分负载。把上面的做法照搬到中转网关上，或者反过来，都会造出两个平台都不满足的期待。

先选模型，再选机制：带固定偏好的主备，或者用 ECMP 的双活。

设好之后要验证什么

按顺序确认四件事。子网表仍然把该前缀解析到预期的网关。网关把两条隧道都列为可用。希望避开的那条连接上，收到的 AS_PATH 比另一条更长。并且，从该子网里一台实例发出的真实流量确实走了预期的那条隧道，在两端都观察到，而不是靠一个绿灯推断。

然后跑一次经过批准的切换测试，看着存活的那条路径继续承载业务。只存在于配置差异里的偏好，还不算偏好。