Definition
- Transit Gateway (TGW) – A regional hub that connects multiple VPCs, VPNs, and Direct Connect gateways, acting as a central router.
- TGW Route Table – One of potentially many route tables on the Transit Gateway, each containing its own set of routes.
- Association – Links an attachment to exactly one TGW route table, determining which routes that attachment consults when sending traffic.
- Propagation – Adds an attachment's CIDR as a route into a chosen TGW route table, making that destination reachable from attachments associated with that table.
- Environment Isolation – Using separate TGW route tables to prevent non-production from having any route to production.
The Transit Gateway is National Bank of India's central transport hub, and it can keep several different route maps. Each building is handed exactly one map (association), and that map lists only the destinations that have been written onto it (propagation). You give both production buildings a map that shows each other, so they can travel between themselves. You give the non-production building a different map that does not show any production destination at all, so even though it is connected to the same hub, it has no directions to production.
Understanding the Concepts
What is a Transit Gateway?
A Transit Gateway (TGW) is a regional hub that connects multiple VPCs, VPN connections, and Direct Connect gateways. Instead of building a full mesh of peering connections between every pair of VPCs, each VPC creates one attachment to the Transit Gateway. By default, with a single route table, all attachments can reach all others – which is not what a bank wants.
# Create a Transit Gateway
aws ec2 create-transit-gateway \
--description "NBI central hub" \
--options DefaultRouteTableAssociation=disable,DefaultRouteTablePropagation=disable
# Disable defaults so we control association and propagation explicitly
What is association?
Association answers: when this attachment sends traffic, which route table does it consult? Each attachment is associated with exactly one TGW route table. That table is the attachment's view of the network – it can only reach destinations that have a route in the table it is associated with.
# Associate production VPC attachment with the production route table
aws ec2 associate-transit-gateway-route-table \
--transit-gateway-route-table-id tgw-rtb-production \
--transit-gateway-attachment-id tgw-attach-prod-pca
aws ec2 associate-transit-gateway-route-table \
--transit-gateway-route-table-id tgw-rtb-production \
--transit-gateway-attachment-id tgw-attach-prod-nonpca
# Associate dev VPC attachment with the non-production route table
aws ec2 associate-transit-gateway-route-table \
--transit-gateway-route-table-id tgw-rtb-nonprod \
--transit-gateway-attachment-id tgw-attach-dev
What is propagation?
Propagation answers: which destinations get written into a route table? When you propagate an attachment into a route table, that attachment's CIDR becomes a route in that table. Any attachment associated with that table can now reach the propagated destination. You can also add static routes for precise control.
# Propagate both production CIDRs into the production route table
aws ec2 enable-transit-gateway-route-table-propagation \
--transit-gateway-route-table-id tgw-rtb-production \
--transit-gateway-attachment-id tgw-attach-prod-pca
aws ec2 enable-transit-gateway-route-table-propagation \
--transit-gateway-route-table-id tgw-rtb-production \
--transit-gateway-attachment-id tgw-attach-prod-nonpca
# Propagate only dev into the non-production route table
aws ec2 enable-transit-gateway-route-table-propagation \
--transit-gateway-route-table-id tgw-rtb-nonprod \
--transit-gateway-attachment-id tgw-attach-dev
# NO production routes propagated here → dev cannot reach production
How does this isolate environments?
Production-PCA and production-non-PCA are both associated with the production route table, and both their CIDRs are propagated into it, so they can reach each other. The development attachment is associated with a separate non-production route table that has no production routes propagated into it, so development has no path to production – and the production route table has no development route either, so even if a packet somehow left development, production could not route a reply.
# Transit Gateway route table: PRODUCTION # Associated: prod-pca, prod-nonpca # Propagated: prod-pca CIDR, prod-nonpca CIDR 10.1.0.0/16 → tgw-attach-prod-pca 10.2.0.0/16 → tgw-attach-prod-nonpca # (no non-production route → dev unreachable from production) # Transit Gateway route table: NON-PRODUCTION # Associated: dev # Propagated: dev CIDR only 10.9.0.0/16 → tgw-attach-dev # (no production routes → dev cannot reach production at all)
Why does association + propagation together determine visibility?
Association selects the map you read. Propagation fills in what is on the map. Routing only works when both sides can see each other, so to connect two attachments you associate them with a shared table and propagate both into it. To isolate them you keep them in different tables that do not carry each other's routes.
public class AssociationPlusPropagation {
// Association: which route table does this attachment USE?
// Propagation: which route table does this attachment's CIDR APPEAR IN?
// To connect A and B:
// Associate both with table X
// Propagate both into table X
// A sees B's route, B sees A's route → connected
// To isolate A from C:
// Associate A with table X, C with table Y
// Do NOT propagate A into Y or C into X
// A has no route to C, C has no route to A → isolated
}
Why is routing-layer isolation stronger than firewall-only isolation?
With Transit Gateway route table isolation, the network path literally does not exist. The development VPC has no route to production, so even if a security group were misconfigured, packets cannot reach production because there is no routing path for them. With firewall-only isolation (Security Groups/NACLs), the path exists but is blocked by a rule, which means a single misconfiguration or rule change could open it.
For a bank's PCI or regulatory segmentation, proving that no route exists is far stronger and more auditable than proving a firewall rule denies traffic.
# Firewall-only isolation: # Path: dev → TGW → production ROUTE EXISTS # Security Group: deny from dev CIDR # Risk: one misconfigured SG opens the path # Audit: must prove every SG in production denies dev # Routing-layer isolation: # Path: dev → TGW → production NO ROUTE # Even with SG misconfiguration: no route = no traffic # Audit: show the TGW route table has no production routes
What are common mistakes?
The first mistake is using a single TGW route table for all attachments. This connects everything to everything, violating environment isolation requirements.
The second mistake is propagating production routes into the non-production route table, accidentally giving development a path to production.
The third mistake is forgetting that isolation is bidirectional. The production route table must also lack development routes, or production could accidentally send traffic to development.
# Verify isolation: check that non-production route table has no production routes
aws ec2 search-transit-gateway-routes \
--transit-gateway-route-table-id tgw-rtb-nonprod \
--filters "Name=route-search.exact-match,Values=10.1.0.0/16"
# Should return: no routes found → isolation confirmed
What about shared services?
Often both production and non-production need access to shared services like DNS, logging, or artifact repositories. You propagate the shared-services VPC into both route tables, and propagate both production and non-production into the shared-services route table. This gives everyone access to shared services without giving non-production access to production.
# Shared services topology
Production RT: prod-pca, prod-nonpca, shared-services
Non-Production RT: dev, shared-services
Shared Services RT: prod-pca, prod-nonpca, dev
# Dev can reach shared services ✓
# Dev can reach production ✗ (no route)
# Production can reach shared services ✓
# Production can reach dev ✗ (no route)
What should a senior engineer know?
A senior engineer uses Transit Gateway route tables as the primary segmentation mechanism and layers Security Groups and NACLs on top for defense in depth. They know that TGW supports up to 20 route tables, which is enough for most environment-isolation patterns, and that static routes in a TGW route table take precedence over propagated routes.
They also automate the TGW configuration with CloudFormation or Terraform to prevent manual errors in association and propagation, and they use TGW flow logs to audit that no traffic crosses the isolation boundary.
# Enable TGW flow logs for audit
aws ec2 create-flow-logs \
--resource-type TransitGateway \
--resource-ids tgw-0abc \
--traffic-type ALL \
--log-destination-type s3 \
--log-destination arn:aws:s3:::nbi-flow-logs/tgw/
Visual Overview
┌──── Transit Gateway Environment Isolation ────┐ │ │ │ Transit Gateway Hub │ │ ┌──────────────────────────────────────┐ │ │ │ │ │ │ │ Production Route Table: │ │ │ │ ┌────────────────────────────────┐ │ │ │ │ │ 10.1.0.0/16 → prod-pca │ │ │ │ │ │ 10.2.0.0/16 → prod-nonpca │ │ │ │ │ │ (no dev routes) │ │ │ │ │ └────────────────────────────────┘ │ │ │ │ Associated: prod-pca, prod-nonpca │ │ │ │ Result: production ↔ production ✓ │ │ │ │ │ │ │ │ Non-Production Route Table: │ │ │ │ ┌────────────────────────────────┐ │ │ │ │ │ 10.9.0.0/16 → dev │ │ │ │ │ │ (no production routes) │ │ │ │ │ └────────────────────────────────┘ │ │ │ │ Associated: dev │ │ │ │ Result: dev → production BLOCKED ✗ │ │ │ │ │ │ │ └──────────────────────────────────────┘ │ │ │ │ Attachments: │ │ prod-pca (10.1.0.0/16) ←→ prod-nonpca │ │ dev (10.9.0.0/16) ←→ (nothing in prod) │ │ │ │ Isolation: no route = no path = no traffic │ │ Stronger than SG-only (path does not exist) │ └────────────────────────────────────────────────┘
Key Takeaway
A Transit Gateway can have multiple route tables, and that is the mechanism I use to isolate environments. The two controls per attachment are association and propagation. Association answers which route table an attachment consults when it sends traffic, and propagation answers which destinations appear in a route table. Together they determine each attachment's entire view of the network.
To implement the rule that production cardholder and production non-cardholder systems can talk to each other but non-production can reach neither, I associate both production attachments with a production route table and propagate both their routes into it, so they see each other. I associate the development attachment with a separate non-production route table that has no production routes propagated into it. The result is that development has no route to production, and the production table has no route back to development, so isolation holds in both directions.
The reason association and propagation together determine visibility is that they are two halves of one decision. Association chooses the map you read, and propagation fills in what is written on that map. To connect two attachments I associate them with a shared table and propagate both; to isolate them I keep them in different tables that do not carry each other's routes. Nothing about being attached to the same Transit Gateway grants connectivity – connectivity comes only from shared, propagated routes.
At National Bank of India we used exactly this for regulatory segmentation. Production environments share a route table, while development sits on its own route table with no production routes. The senior point I always make is that this is a stronger control than isolating with Security Groups alone, because the path does not exist at the routing layer rather than existing but being blocked by a firewall – and for a PCI or regulatory audit, proving that no route exists is far cleaner than proving a firewall rule denies it.
Remember one sentence: Association picks which route table an attachment uses, propagation fills that table with destinations, and keeping environments on separate tables with no cross-propagation isolates them at the routing layer.
---