Transit Gateway route tables and segmentation

A transit gateway (TGW) replaces a mesh of VPC peering links with one regional hub. The exam tests how you control which attachments can talk to each other.

Attachments and route tables

A TGW has attachments: VPC, Site-to-Site VPN, Direct Connect gateway, peering, and Connect (GRE/BGP for SD-WAN). Each attachment is associated with exactly one TGW route table. That table decides where traffic arriving from the attachment goes.

An attachment can also propagate its routes into one or more route tables. Propagation is how a table learns the CIDR of a VPC or the BGP prefixes of a VPN.

Concept	Meaning
Association	Which table is used for traffic coming in from the attachment (one only)
Propagation	Which tables learn the attachment’s routes (many allowed)
Static route	Manually added route, wins over propagated routes for the same prefix

By default a TGW has one default route table, and every attachment is associated with and propagates to it, so everything reaches everything.

Segmentation with several tables

To isolate environments, turn off default association and propagation, then build tables:

• Production table: contains routes for production VPCs and shared services.
• Non-production table: contains routes for non-production VPCs and shared services.
• Shared-services table: contains routes for all VPCs.

Production and non-production never learn each other’s routes, so traffic is dropped. The question “fewest route tables” usually resolves to two or three tables, not one per VPC.

A blackhole route drops traffic for a prefix explicitly. Use it when a more specific route would otherwise leak traffic.

VPC route tables still matter

Each VPC subnet route table needs a route to the TGW, for example 10.0.0.0/8 to the TGW ID. Without it, traffic never reaches the TGW. Each VPC attachment needs one subnet per Availability Zone it uses; traffic only reaches the TGW through an AZ that has an attachment subnet.

Inter-Region peering

A peering attachment links two TGWs in different Regions or accounts over the AWS backbone. Traffic is encrypted and does not use the internet. Propagation is not supported, so add static routes on both sides pointing to the peering attachment. A TGW to on-premises path in another Region is commonly built this way.

Other features worth knowing

• ECMP across multiple VPN tunnels raises bandwidth beyond 1.25 Gbps per tunnel. It works only with BGP-based VPNs on a TGW.
• Appliance mode keeps both directions of a flow on the same AZ for a firewall VPC. Without it, asymmetric routing breaks stateful inspection.
• Multicast needs a multicast-enabled TGW and a multicast domain; instances register with IGMP.
• Resource Access Manager shares a TGW across accounts in an organization.

Exam traps

• Association is one per attachment; propagation can be many. People swap them.
• Peering attachments need static routes; propagation is not available.
• Updating TGW tables is not enough; the VPC subnet route tables need a TGW route too.
• Stateful inspection through a TGW needs appliance mode, or flows may take different AZs.
• ECMP is for VPN attachments, not for Direct Connect transit VIFs or VPC attachments.

Practice questions

Choose an answer, then review the explanation to check your understanding.

1. A transit gateway connects production VPCs, non-production VPCs and a shared-services VPC. Production and non-production must not reach each other, but both must reach shared services. What is the simplest design?

1. A.One route table with all attachments associated and propagating to it
2. B.Separate route tables for production and non-production; shared services propagates to both, and each environment propagates to the shared-services table
3. C.Security groups that deny the other environment
4. D.A separate transit gateway per environment

Show answer

Answer: B.Segmentation is done with multiple TGW route tables using association and propagation. A single table lets every attachment reach every other one.

2. Two transit gateways in different Regions are connected with a peering attachment. How do you make the VPC in one Region reach the VPC in the other?

1. A.Enable route propagation on the peering attachment
2. B.Add static routes in each transit gateway route table that point to the peering attachment
3. C.Nothing, peering learns the routes automatically
4. D.Use BGP between the two transit gateways

Show answer

Answer: B.Peering attachments do not support propagation. You must create static routes that target the peering attachment.

3. What decides which route table a transit gateway uses to forward a packet that arrives from a VPC attachment?

1. A.The route table propagated to by that attachment
2. B.The route table associated with that attachment
3. C.The VPC main route table
4. D.The default route table of the Region

Show answer

Answer: B.Each attachment is associated with exactly one route table, and that table is used for traffic coming in from the attachment.