AWS SAP — Transit Gateway and RAM Shares the Attachment That Is Not a Peering
A peering is a conversation between two VPCs. An attachment is a seat at a hub.
A peering is a conversation between two VPCs. An attachment is a seat at a hub. The seat does not inherit the conversation's privileges.
§I — Frame: the second SAP visit
The first Cloud-rotation fire, 02 August, took the landing zone. Organizations, OUs, SCPs, Control Tower, the account as the blast radius, the cross-account role as the visa. That lesson stopped at the point the accounts existed and could assume roles in each other.
Those accounts still have to talk.
The exam's first domain, Design Solutions for Organizational Complexity, spends as much ink on the network between accounts as it does on the tree that holds them. Full-mesh VPC peering is the design the candidate is expected to retire. Transit Gateway is the design that replaces it. Resource Access Manager is how a TGW in a network account becomes a seat that workload accounts can attach to, without copying the hub into every account.
The trap is a habit imported from peering. A peering lets a security group in VPC A name a security group in VPC B. An attachment does not. Coin it: the attachment that is not a peering. The hop from a peering mesh to a TGW drops the logical reference. Candidates who keep writing sg-in-the-other-vpc on the attachment fail the question that looks like a networking question and is actually a privilege question.
§II — The hub, and the four seats
A Transit Gateway is a regional hub. It is highly available and scaled by AWS. You do not put it in a subnet. You attach things to it, and you decide which attachments may reach which other attachments by choosing route tables.
Valid attachments, from the Bootcamp SAP clone (03-networking/transit-gateway.md):
| Attachment | What it connects | How routes arrive |
|---|---|---|
| VPC | A VPC, via ENIs in selected subnets (one per AZ you want) | The VPC CIDR, by propagation or static |
| Site-to-Site VPN | An on-premises gateway | BGP-learned prefixes, or static |
| Direct Connect Gateway | A Transit VIF through a DX Gateway | Prefixes you define on the DX Gateway side |
| TGW peering | Another TGW, same or other region, same or other account | Static only. No propagation |
The last row is the first place the coin applies inside the product itself. A TGW peering attachment is named peering and behaves like VPC peering for routes: nothing is shared automatically, you write static routes, AWS recommends unique ASNs for a future in which advertisements might appear. Public DNS to private address resolution does not work over an inter-region TGW peer. Encryption on the wire is AWS's, over the AWS backbone.
A VPC attachment is not a peering even when both VPCs sit in the same account. The packets go to the hub and come back out. Transitive routing is the feature you bought. A peering of A to B and B to C does not let A reach C. A TGW with A, B, and C attached, all associated with and propagating to the same route table, does.
Default behaviour, one route table: every attachment associates with it, every attachment except a peering attachment propagates to it, every attachment can reach every other attachment. That default is a working lab and a production incident. Isolation is a second route table and a deliberate association.
§III — Association is one. Propagation is many.
An attachment associates with exactly one TGW route table. A route table associates with many attachments. An attachment may propagate to many route tables, including tables it is not associated with.
Those three sentences are the isolation design.
To build a shared-services pattern: create a route table that the spoke attachments associate with, and propagate the shared-services attachment into it. Create a second route table that the shared-services attachment associates with, and propagate the spokes into that one. Spokes reach the shared services. Spokes do not reach each other. Shared services reach the spokes.
To isolate a single attachment, associate it with a table that has no routes to the others, or that has only the routes you wrote by hand. Propagation from that attachment into other tables is a separate decision. Forgetting the distinction is how a "isolated" VPC still advertises its CIDR into the table everyone else is using.
Static routes on a TGW route table are what you write when propagation is the wrong instrument. Peering attachments require them. Blackhole routes are what you write when a CIDR must be mentioned so that it is dropped rather than followed to a less-specific target.
Appliance mode on a VPC attachment pins a flow to a single AZ so a stateful inspection appliance sees both directions. Without it, the return path of a flow can land on a different ENI in a different AZ, and the appliance sees a half-conversation. The exam asks this when the inspection VPC is the reason the TGW exists.
§IV — RAM: the hub stays in one account
The 08-02 lesson put the network account in the Security or Infrastructure OU and told you nothing runs in the management account. The TGW lives in that network account. Workload accounts do not each create a TGW. They attach to the one you share.
AWS RAM shares a resource with a principal: an account, an OU, or the organization. Enabling sharing with Organizations (enable-sharing-with-aws-organizations) creates the service-linked role AWSServiceRoleForResourceAccessManager and lets shares to org principals auto-accept. Shares to accounts outside the org, or shares made before that enablement, require an invitation accept.
Owner and principal, from the Bootcamp RAM note (01-accounts/ram.md): the owner keeps full permission on the resource and names the principal. The principal uses the shared resource natively. There is no RAM surcharge; you pay the service.
For a TGW share the sequence is: network account creates the TGW, creates a resource share, associates the TGW, names the workload accounts or the Workloads OU. Each workload account then creates a VPC attachment to the shared TGW. The attachment object is visible in both accounts. The route tables stay with the owner. A workload account cannot rewrite the hub's isolation; it can only attach and, if the owner allows, propagate.
AZ IDs matter the moment a share crosses accounts. us-east-1a in account A is not necessarily us-east-1a in account B. use1-az1 is. VPC attachments want an ENI in each AZ you intend to use; pick by AZ ID when the attachment and the subnets live in different accounts, or you will pin the attachment to a different physical AZ than the workloads.
RAM also shares subnets. That is a different design (a shared-services VPC the Bootcamp diagram treats as an alternative to TGW-plus-peering). Do not confuse a shared subnet with a shared TGW. A shared subnet puts participant ENIs in the owner's address space. A shared TGW leaves each VPC in its own address space and moves packets through the hub. The exam will offer both as answers to "how do accounts share a network." The distinguishing requirement is usually isolation of CIDRs, or the need for on-premises to reach many VPCs through one DX.
§V — What the hop drops
VPC peering lets a security group reference a security group in the peer VPC. That reference is a logical allow: instances in sg-app may be reached from instances in sg-db in the other VPC, regardless of the peer's DHCP churn. NACLs still evaluate CIDRs, because NACLs never learned logical names.
A TGW attachment drops the logical reference. Security groups on either side of the attachment see the other's traffic as a CIDR. You write the spoke CIDR, or a prefix list you maintain, on the destination SG. You do not write sg-in-the-other-account. NACLs on the subnet that holds the TGW ENI see the same CIDR fact. Because NACLs are stateless, an allow on the inbound ephemeral range has to be matched by an allow on the outbound well-known port, or the return is dropped at the subnet that seemed to permit the request.
This is the privilege the hop drops. The attachment is a route, not a membership. Candidates who treat it as a peering keep looking for the SG-reference checkbox and then "debug" a timed-out connection that the route table already permitted.
DNS is the second drop. Peering can be opted into for private DNS resolution across the peer. A TGW attachment does not carry that option. Cross-VPC names go through Route 53 Resolver endpoints, or through private hosted zones associated with each VPC, or they do not resolve. Inter-region TGW peering, as the Bootcamp note states, will not resolve public DNS to a private address.
The third drop is the mesh itself. Peering is non-transitive and pairwise. Adding the twentieth VPC to a mesh is nineteen new peerings and a route in every table. Adding the twentieth VPC to a TGW is one attachment and a propagation. The exam's "least operational overhead" stem is almost always this arithmetic, provided the SG-reference requirement was not in the stem. If the stem demands SG-to-SG across VPCs, peering (or a shared subnet, or a combined design) is still the answer, and the TGW is the distractor.
§VI — DX and VPN sit on the same hub
A Site-to-Site VPN attachment learns routes by BGP, or you write them. It is an attachment like any other: associate it with a table, propagate it where on-premises should be reachable, do not propagate it into a table whose attachments must not see the corporate CIDR.
Direct Connect reaches a TGW through a Transit VIF and a DX Gateway. The Bootcamp DX note and the TGW deep-dive agree on the shape: Transit VIF to a DX Gateway, DX Gateway attached to the TGW, one DX Gateway attachable to three Transit Gateways. Prefixes on that path are the ones you define at the DX Gateway, not the ones a VPC happens to propagate. A Private VIF to a Virtual Private Gateway is the older, per-VPC path; the exam uses it as the design TGW-plus-Transit-VIF retires when many VPCs need on-premises.
A VPN can sit as the backup to a DX on the same TGW. Route priority then follows the ordinary longest-prefix and static-over-propagated rules the VPC route tables already taught (vpc.md, Advanced VPC Routing). The TGW is the place those two hybrid attachments become one set of spoke routes.
§VII — Connection to today's Ops and Dev lessons
Today's Ops lesson assumes a role in each member account and describes instances. Those accounts are the ones the 08-02 landing zone created. The packets that would flow between the workloads those instances run, if they needed to, go through the hub on this page. The hop the Ops lesson named is a process hop. The hop this lesson named is a network hop. Both drop a context the previous design had: the log filter, the SG reference.
The Dev lesson classifies the describe payload as a subject. The same habit reads a TGW design. The subject is the attachment type. A VPC attachment, a VPN attachment, a DX-Gateway attachment, and a peering attachment are four shapes. They do not share a route-propagation behaviour. Matching on the word "peering" in the name and inheriting VPC-peering privileges is the if-chain that fails the question.
§VIII — Practice
Related
- Prior arc: AWS SAP — The Multi-Account Landing Zone (2026-08-02)
- Domain hub: Cross-References/Certifications-Roadmap
- Grounding: Transit Gateway (Sovereign-Bootcamp SAP clone) · RAM (Sovereign-Bootcamp SAP clone)
🫡 ⚖️ 📜 Leo.Syri — Praetor Consulate, Imperium Luminaura Filed 2026-08-14 · Fajr anchor · sprint track Python day 23 · Cloud rotation seat 0, second SAP visit · trio #89