两个 AWS 账户，一个本地网络：选哪条路？
共享 Transit Gateway、两条独立 VPN，还是一条窄代理：按归属和爆炸半径来选，而不是按今天哪条路由最容易加。
显而易见的框架是 peering 与 VPN 之争，而这是错误的框架。对等连接的 VPC 无法借用邻居的 VPN 连接来做边缘到边缘的路由，所以无论路由表怎么暗示，这个选项从来就不在桌面上。你真正要选的是共享网络中枢、两条独立 VPN 路径和一条窄应用入口。三者各自回答的是「路由归谁所有」这个问题的不同侧面。
三个选项，以及那个并不成立的选项
先把 peering 这个念头删掉，再按归属而非按图面简单程度来比较剩下的选项。下表是压缩后的决定。
| Option | Who owns the path | Main cost |
|---|---|---|
| Shared transit gateway | Hub owner, used by both VPC owners | Shared blast radius, attachment and data-processing charges |
| Separate VPNs per account | Each account independently | Peer capacity, duplicated tunnels, overlapping prefixes to coordinate |
| Application proxy | The account that hosts the intermediary | New auth, logging and availability surface, and only one service |
如果账户 A 需要到达整个本地网络，代理这一行就选错了。如果账户 A 只需要一个 API，前两行就比需求所要求的网络更多。
共享 Transit Gateway 何时胜出
Transit Gateway 把每个 VPC 和 VPN 作为各自独立的网络接入，跨账户共享让 VPC 所有者无需合并账户即可使用中枢。吸引力就在于此：本地前缀与 AWS 网络相遇的地方只有一处，判断哪个接入学到哪条路由的地方也只有一处。
全部接入并不意味着全部放行。关联与传播决定哪个接入使用哪张路由表，因此两个 VPC 前缀可以各自到达一个本地服务，而彼此的访问仍被中枢的设计排除在外。本地一侧仍需为 AWS 前缀配置回程路由，那是另一个团队的变更工单。
成本既是财务上的，也是组织上的。中枢所有者掌管着其他团队依赖的路由关系，所以改动一个接入，就可能搬动某个中枢所有者从未听说过的服务的流量。接入时长和数据处理随着每接入一个网络而累加，这也是中枢往往比运维它的团队增长更快的原因。
独立 VPN 或窄代理何时胜出
两条独立 VPN 适合有真实运维边界的小型部署：每个账户改自己的隧道，谁也改不了路由表害了对方。限制在本地一侧。对端网关要有容纳额外隧道的容量，地址规划不能重叠，两份宣告相同前缀的配置需要刻意设定的优先级，而不是靠运气。
代理是最窄的接口。如果账户 A 只需要账户 B 里的一个数据库或一个 API，一个划定范围的中间层就能给出明确的入口，并自带认证、日志和可用性方案。它也是最容易被误用的选项：一个把所有流量转发到任意私有目标的中间层，就变成多绕几步的无限中继，对别的东西不会像 VPC 到本地的透明过境那样表现。
在此之前值得先读VPC peering 的限制，因为它们解释了第四个念头为何反复出现、为何行不通。
选最能满足需求的最窄接口
把问题排好序：A 需要的是一张网络、一组网络，还是一个服务？本地团队想要的是一条路还是多条？谁有权改另一个团队流量的路由？第一个能给出最窄接口的答案就是架构，之后的一切都是实施。
把答案与地址前缀规划、路由归属、隧道或接入清单，以及双方预期的故障模式一起记录下来。日后有人问为什么账户 A 不能直接用账户 B 的 VPN，那份记录就是答案，也能让你在下一个项目里不必重新争论同样的三个选项。