共享 Transit Gateway：AWS RAM 中的路由归谁所有
通过 RAM 共享可让另一个账户挂载 VPC，但路由表、关联和传播仍归网关所有者所有。边界就在这里。
用 Resource Access Manager 共享 Transit Gateway 只做一件具体的事：允许另一个账户针对自己并不拥有的资源调用一组已定义好的挂载 API。它不会转移网关、网关的路由表，也不会转移决定流量如何转发的权利。人们之所以误以为所有权也转移了，是因为挂载会出现在接收方的控制台里并且立刻生效。底层机制是对共享资源的权限授予，所有子对象都留在所有者账户的边界内。这种拆分解释了围绕共享中转的绝大多数拒绝访问工单。
共享究竟委托了什么
资源共享会指定一个资源、一个主体和一份托管权限。权限列出该主体可以执行的操作；对 Transit Gateway 而言，这份清单涵盖对共享资源的挂载操作。
清单之外的操作会在 API 层失败而不是在控制台失败，所以错误往往在脚本第一次运行时才出现。
路由表、关联和传播仍归所有者
转发由三个子对象决定：挂载关联到哪张路由表、它向哪些表传播，以及这些表里有哪些路由。AWS 的共享文档指出，接收方不能通过共享创建、修改或删除中转网关的路由表及其关联和传播。这些调用属于所有者账户。需要新关联的接收方是在申请一次管理变更，而不是在行使某项忘记开启的权限。
下面这张表是我写进设计文档的职责划分，因为它能经受人员更替。
| Role | What it controls |
|---|---|
| Transit Gateway owner | The gateway, its route tables, associations and propagations; the Site-to-Site VPN attachment is created here. |
| VPC owner using the share | Its own attachment, subnet route tables and security policy for the workloads. |
| Shared-subnet participant | Workload traffic only, following routes the VPC owner already set. |
请仔细读中间一行：VPC 所有者控制自己的子网路由，网关所有者控制中心的转发决策，而一条可用的路径两者都需要。任何一个账户都无法单独完成。
一条路径，两个账户
追踪一个数据包，从 spoke VPC 到本地前缀。spoke 子网路由表必须把该前缀发往中转网关挂载，这一点 VPC 所有者可以更改。随后网关必须在挂载关联的表里有一条指向 VPN 挂载的路由，这一点只有所有者能改。回程流量需要两者的镜像。漏掉任何一侧，你得到的就是一条只装了一半、看起来像防火墙问题的路径。
把两处变更写进同一张工单，并指定两名负责人，否则它们会在不同的周完成。
当位置重要时使用可用区 ID
可用区名称是账户本地的别名。一个账户里的 us-east-1a 并不保证与另一个账户里的 us-east-1a 是同一个物理可用区。当设计需要挂载与工作负载位于同一可用区时，比较 AZ ID 并记录下来。
比较名称会得到一张看起来正确、延迟分布却不正确的图。在画图阶段就检查，而不是等有人测出差异之后。
取消共享不会切断数据路径
移除共享感觉像是撤销，但它并不是立即停止流量。AWS 文档说明，网关被取消共享后，挂载仍会继续工作。管理资源的权限消失了，而已经存在的挂载会继续转发，直到有人删除或禁用它。把撤销规划成两步：先移除共享，再移除挂载，第二步由所有者执行。
如果共享是你唯一的控制手段，那你就没有控制手段。
把共享记录和路由记录放在一起
两份材料回答两个不同的问题。共享记录说明谁可以操作该资源。路由表说明哪些网络真的能通信。把它们和同一份所有者清单存在一起，否则下一次事故会从某人举证一项从来不是问题的权限开始。
然后测试每个方向的一条流，以及一个本应保持不可达的前缀。