Shared Transit Gateway: Who Owns the Routes in AWS RAM

Sharing a Transit Gateway with Resource Access Manager does one specific thing: it lets another account call a defined set of attachment APIs against a resource it does not own. It does not transfer the gateway, its route tables, or the right to decide how traffic is forwarded. People assume otherwise because the attachment shows up in the recipient's console and works immediately, which feels like ownership. The mechanism underneath is a permission grant on a shared resource, and every child object stays inside the owner's account boundary. That split explains most of the access-denied tickets around shared transit.

What the share actually delegates

A resource share names a resource, a principal and a managed permission. The permission lists the actions that principal may perform, and for a Transit Gateway that list covers attachment operations on the shared resource.

Anything outside the list fails at the API rather than in the console, which is why the error often appears the first time a script runs.

Route tables, associations and propagations keep the owner

Forwarding is decided by three child objects: which route table an attachment is associated with, which tables it propagates into, and what routes those tables hold. AWS's sharing documentation states that a recipient cannot create, modify or delete transit gateway route tables or their associations and propagations through the share. Those calls belong to the owner account. A recipient that needs a new association is requesting an administrative change, not exercising a permission it forgot to enable.

The table below is the split I put in design documents, because it survives staff changes.

Read the middle row carefully: the VPC owner controls its subnet routes, the gateway owner controls the central forwarding decision, and a working path needs both. Neither account can complete it alone.

One path, two accounts

Trace a packet from a spoke VPC to an on-premises prefix. The spoke subnet route table must send that prefix to the transit gateway attachment, which the VPC owner can change. The gateway must then have a route in the attachment's associated table pointing at the VPN attachment, which only the owner can change. Return traffic needs the mirror of both. Miss either side and you get a path that is half-installed and looks like a firewall problem.

Write both changes into one ticket with two assignees, or they will be finished in different weeks.

Use Availability Zone IDs when placement matters

Zone names are account-local aliases. us-east-1a in one account is not guaranteed to be the same physical zone as us-east-1a in another. When the design needs an attachment and a workload in the same zone, compare AZ IDs and record them.

Comparing names produces a diagram that looks right and a latency profile that is not. Check it while the diagram is still being drawn, not after someone measures the difference.

Unsharing does not cut the data path

Removing the share feels like revocation, and it is not an immediate traffic stop. AWS documents that an attachment remains functional when the gateway is unshared. The permission to manage the resource disappears, while the attachment that already exists keeps forwarding until someone deletes or disables it. Plan revocation as two steps: remove the share, then remove the attachment, with the owner performing the second.

If the share is your only control, you do not have a control.

Keep the share record and the routing record together

Two artefacts answer two different questions. The share record says who may work with the resource. The route tables say which networks can actually talk. Store them together with the same owner list, or the next incident starts with someone proving a permission that was never the problem.

Then test one flow in each direction and one prefix that should stay unreachable.