A transit gateway joins many VPCs through one hub. Joining them is easy. Keeping some of them apart is where the design work is, and it comes down to two settings that sound alike and do different jobs: association and propagation. Follow one packet and the difference becomes obvious.
The hub and its tables
The Transit Gateway guide describes a transit gateway as “a Regional virtual router for traffic flowing between your virtual private clouds (VPCs) and on-premises networks”. Each VPC connects through an attachment, and “A transit gateway attachment is both a source and a destination of packets.”
Routing happens in transit gateway route tables, and one transit gateway can hold several. The guide compares them to a feature of traditional routers: separate tables let you “create isolated networks inside a transit gateway similar to virtual routing and forwarding (VRFs) in traditional networks”.
Two settings connect attachments to tables:
- Association picks the one table a packet arriving from the attachment is looked up in. “Each VPC or VPN attachment is associated with a single route table. That route table decides the next hop for the traffic coming from that resource attachment.”
- Propagation installs the attachment’s routes in a table. “For a VPC attachment, the CIDR blocks of the VPC are propagated to the transit gateway route table”, and “An attachment can propagate its routes to one or more route tables.”
One association per attachment. As many propagations as you need. Neither implies the other.
One packet, two lookups
Picture dev-server in dev-vpc (10.20.0.0/16) sending to orders-server in orders-vpc (10.10.0.0/16).
- The VPC route table sends it to the hub. Attaching a VPC does not change its subnets’ routing: “you must add a route to your subnet route table in order for traffic to route through the transit gateway”. Here dev-vpc’s table sends
10.0.0.0/8to the transit gateway. - The transit gateway picks a table by association. The packet arrived on dev-vpc’s attachment, so it is looked up in the table that attachment is associated with. Not the destination’s table, and not the default table unless that is the association.
- That table needs a route to the destination. The route is there only if orders-vpc’s attachment propagated into this table, or someone added a static route. If not, the packet stops here.
- The reply repeats the process from the other side. orders-server’s reply enters through orders-vpc’s attachment and is looked up in that attachment’s table, which needs a route back to dev-vpc.
So for every flow, ask two questions: which table is the sender’s attachment associated with, and is the receiver propagated into it? Then ask them again for the reply.
Defaults that join everything
When you create a transit gateway, AWS creates a default route table and uses it “as the default association route table and the default propagation route table”. Two options control what happens to new attachments. Default route table association will “automatically associate transit gateway attachments with the default route table”. Default route table propagation will “automatically propagate transit gateway attachments to the default route table”.
Leave both on and you get the guide’s centralised router: every attachment is associated with the default table and propagates to it, “Therefore, all attachments can route packets to each other”. That is right for a flat network and wrong for one that must be segmented.
Segmenting with shared services
The guide’s example of isolated VPCs with shared services uses two tables. In its words: “Each isolated VPC is associated with the isolated route table and propagated to the shared route table. Each shared services VPC is associated with the shared route table and propagated to both route tables.” Packets from one isolated VPC to another are “blocked because there is no route for them in the transit gateway route table”.
Landing zones often have more than one environment. With production, development and shared services, the same idea becomes three tables:
| Table | Attachments associated | Propagated into it |
|---|---|---|
| Production | production VPCs | production VPCs, shared services |
| Development | development VPCs | shared services only |
| Shared services | shared services VPC | every VPC |
Development’s table has no route to production, so development cannot send a packet into production. Production’s table has no route to development either, so the isolation does not depend on a missing return route. Shared services can answer everyone, because their own table holds everyone’s routes.
The tempting shortcut is to associate shared services with the production table. Then that table must also hold development’s routes for the replies, and production gains a path into development.
Two more tools complete the set. When a static route and a propagated route have the same destination, “the static route has the higher priority”. And “You can create a blackhole route in your transit gateway route table that drops traffic that matches the route.”
What the exam guides ask
The SAP-C02 guide covers this in Task 1.1 “Architect network connectivity strategies” and Task 1.2 “Prescribe security controls”. The SCS-C03 guide has Skill 3.3.4 “Design network segmentation based on security requirements”, and the SOA-C03 guide has Skill 5.3.1 “Troubleshoot VPC configurations”.
Scenario questions on the topic describe several environments on one hub, a rule that some of them must never talk, and often several AWS accounts. A transit gateway “works across AWS accounts, and you can use AWS RAM to share your transit gateway with other accounts”. The wrong answers follow a pattern:
- A second transit gateway per environment. It works, but one transit gateway with separate route tables already segments. The guide calls its isolated-router design “similar to using multiple transit gateways, but provides more flexibility in cases where the routes and attachments might change”.
- VPC peering between some of the VPCs. It joins them outside the hub’s route tables.
- Security groups that refuse development. “You can specify allow rules, but not deny rules”, and the requirement is about what can be routed at all.
- One table for everything. Every attachment associated with it can then reach every attachment propagated into it, so nothing is segmented.
- An attachment associated with two tables. An attachment has one association.
Play it
In Routing Domains, Halcyon Health runs a multi-account landing zone. The network account owns core-tgw and shares it through AWS Resource Access Manager. The production account owns orders-vpc and payments-vpc, the development account owns dev-vpc, and shared-vpc runs monitoring and package mirrors. Every VPC is attached and every VPC route table already sends 10.0.0.0/8 to core-tgw. Default association is on and default propagation is off, so all four attachments sit in core-rtb, which has no routes yet. Production must reach itself and shared services, development must reach shared services, and a compliance review rejects any design in which one environment’s table can reach the other’s. You create tables and set associations and propagations in the Inspector, then follow each packet through its lookups. Routing Domains is part of the paid Networking domain. The free first stage, Open for Business, is a Network build too and plays the same way.