This chapter covers AWS Transit Gateway, a critical networking component for building scalable, centralized network architectures in AWS. You will learn how TGW replaces complex VPC peering meshes, its internal routing mechanics, and how to configure it for hybrid connectivity. For the SOA-C02 exam, Transit Gateway appears in approximately 5-8% of questions, typically in scenarios involving multi-VPC connectivity, VPN/Direct Connect integration, and route table design. Mastering this topic is essential for the Networking domain.
Jump to a section
Imagine a large airline hub airport like Atlanta Hartsfield-Jackson. Instead of every city building direct flights to every other city (which would be expensive and inefficient), the airline routes all flights through the hub. Passengers from New York to Los Angeles fly into Atlanta, change planes, and fly out. The hub handles the routing, consolidates traffic, and simplifies operations. In AWS, a Transit Gateway acts as this hub for your VPCs and on-premises networks. Without a Transit Gateway, connecting multiple VPCs would require a mesh of VPC peering connections, each with its own route tables and VPN attachments. This becomes unmanageable as the number of VPCs grows. The Transit Gateway centralizes routing: each VPC attaches to the TGW via a single attachment, and the TGW manages route tables, propagation, and traffic flow. Just as the hub airport can handle flights from many airlines, a TGW can connect thousands of VPCs, VPNs, and Direct Connect gateways. The TGW route table acts like the hub's flight schedule: it decides which attachments can talk to each other. You can isolate traffic by using separate route tables, similar to how different airlines use different concourses. This hub-and-spoke model reduces complexity, improves scalability, and provides centralized control over network traffic.
What is AWS Transit Gateway?
AWS Transit Gateway (TGW) is a regional network transit hub that connects VPCs, VPN connections, and AWS Direct Connect gateways. It acts as a single point of entry for all network traffic, simplifying network architecture and reducing operational overhead. Instead of establishing VPC peering connections between every pair of VPCs (which scales as O(n^2)), you attach each VPC to the TGW once. The TGW then manages routing between all attachments using its own route tables. This hub-and-spoke model supports thousands of VPCs and on-premises networks.
Why Transit Gateway Exists
Before TGW, connecting multiple VPCs required a mesh of VPC peering connections. With N VPCs, you needed N*(N-1)/2 peerings. Each peering required route table entries in both VPCs, and transitive routing was not supported (e.g., VPC A could not reach VPC C via VPC B unless they were directly peered). This approach did not scale beyond a few VPCs. TGW solves this by providing transitive routing: any attachment can reach any other attachment if the route tables permit it. It also centralizes VPN and Direct Connect termination, reducing the number of VPN tunnels and simplifying BGP configuration.
How Transit Gateway Works Internally
Each TGW attachment (VPC, VPN, Direct Connect Gateway, Peering Connection) is associated with a TGW route table. The TGW route table contains static routes and propagated routes from attachments. When a packet arrives at the TGW from an attachment, the TGW performs a route lookup in the route table associated with that attachment. The destination IP is matched against the route table, and the packet is forwarded to the appropriate attachment. If no match is found, the packet is dropped. The TGW does not perform NAT; it forwards packets based on IP headers. It supports multicast (with limitations) and inter-region peering.
Key Components and Defaults
Attachment: A connection between a TGW and a VPC, VPN, Direct Connect Gateway, or another TGW (peering). VPC attachments are created by specifying the VPC and subnets (one subnet per Availability Zone). The TGW creates an elastic network interface (ENI) in each subnet.
Route Table: Each TGW has a default route table. Attachments can be associated with a route table and can propagate routes to it. Propagation means that routes from the attachment's CIDR (or BGP prefixes) are automatically added to the route table.
Association: Each attachment is associated with exactly one TGW route table. This determines which route table is used for incoming traffic from that attachment.
Propagation: An attachment can propagate its routes to one or more TGW route tables. This allows other attachments to learn routes to the attachment's network.
Default Route Table: Created automatically when the TGW is created. By default, all attachments are associated with it and propagate to it. You can disable this behavior.
Multicast: Supported via multicast domains. Not commonly tested on SOA-C02.
Inter-Region Peering: Allows TGWs in different regions to be connected. Traffic stays on the AWS global network. Requires a peering attachment.
Transit Gateway Network Manager: A service that provides a central dashboard to monitor and troubleshoot network connectivity.
Configuration Steps
Create the Transit Gateway in the desired region. Specify Amazon side ASN (default 64512), DNS support, VPN ECMP support, default route table association/propagation.
Attach VPCs: For each VPC, create a VPC attachment. Specify the VPC ID and subnets (one per AZ). The TGW creates ENIs in those subnets.
Configure TGW route tables: Create route tables as needed (e.g., separate route tables for production and development). Associate each VPC attachment with the appropriate route table. Enable propagation from attachments to the route table.
Update VPC route tables: Add routes in the VPC's route tables pointing to the TGW attachment for destination CIDRs that are reachable via the TGW (e.g., other VPC CIDRs, on-premises CIDRs).
For VPN attachments: Create a VPN attachment and configure the customer gateway (CGW) device with the TGW's tunnel endpoints. BGP is recommended for dynamic routing.
For Direct Connect: Attach a Direct Connect Gateway to the TGW. The Direct Connect Gateway must be in the same region (or a different region with inter-region peering).
Verification Commands (AWS CLI)
List TGWs: aws ec2 describe-transit-gateways
List attachments: aws ec2 describe-transit-gateway-attachments
List route tables: aws ec2 describe-transit-gateway-route-tables
View routes: aws ec2 search-transit-gateway-routes --transit-gateway-route-table-id <rtb-id> --filters Name=type,Values=static
View propagated routes: aws ec2 get-transit-gateway-attachment-propagations --transit-gateway-attachment-id <att-id>
Check association: aws ec2 get-transit-gateway-attachment-associations --transit-gateway-attachment-id <att-id>
Interaction with Related Technologies
VPC Peering: TGW can coexist with VPC peering, but TGW is preferred for transitive routing. VPC peering is still useful for direct, low-latency connections between two VPCs that do not need to route through the TGW.
VPN: TGW supports site-to-site VPN attachments. You can terminate multiple VPN tunnels to the same CGW or different CGWs. BGP dynamic routing is recommended. ECMP (Equal Cost Multi-Path) is supported for multiple tunnels to increase bandwidth.
Direct Connect: TGW integrates with Direct Connect Gateway (DXGW). You attach the DXGW to the TGW, and the DXGW connects to your on-premises network via virtual interfaces (VIFs). This allows a single Direct Connect connection to reach multiple VPCs via the TGW.
AWS PrivateLink: TGW does not natively support PrivateLink endpoints. PrivateLink endpoints are attached to VPCs, not TGW. Traffic from a TGW-attached VPC to a PrivateLink endpoint must go through the VPC's route table.
Route Propagation: TGW supports route propagation from VPC attachments (the VPC's CIDRs) and from VPN attachments (BGP prefixes). Static routes can also be added. Propagation simplifies route management but must be controlled to avoid unintended connectivity.
Limits and Defaults
Maximum number of VPC attachments per TGW: 5,000 (default limit can be increased).
Maximum number of route tables per TGW: 20 (default).
Maximum number of routes per route table: 10,000 (static + propagated).
Maximum transmission unit (MTU): 8500 bytes for VPC attachments, 1500 bytes for VPN attachments.
TGW supports jumbo frames for VPC attachments but not for VPN.
TGW does not support IPv6 transit (IPv6 traffic is not forwarded between attachments).
TGW does not support multicast traffic by default; multicast requires a multicast domain.
Pricing
TGW charges per attachment per hour and per GB of data processed. Inter-region peering charges additional data transfer fees. You can reduce costs by consolidating traffic through a single TGW instead of multiple VPC peering connections.
Security and Routing Isolation
By using separate TGW route tables, you can isolate traffic between groups of VPCs. For example, a "Production" route table might contain routes to production VPCs and on-premises, while a "Development" route table only connects development VPCs. Attachments are associated with the appropriate route table. Propagation must be configured carefully to avoid leaking routes between isolated groups.
Create Transit Gateway
In the AWS Management Console or via CLI, create a Transit Gateway. Specify the Amazon side ASN (default 64512), enable DNS resolution support (if needed), enable VPN ECMP support, and configure default route table association and propagation. The TGW is created in a specific region and is initially empty with no attachments. The default route table is created automatically. You cannot change the ASN after creation.
Attach VPCs to TGW
For each VPC you want to connect, create a VPC attachment. Specify the VPC ID and the subnets (one subnet per Availability Zone) where the TGW will place ENIs. The ENIs are used to route traffic between the VPC and the TGW. The attachment state becomes 'pending' and then 'available'. Ensure the VPC's route tables are updated to direct traffic to the TGW attachment for destination CIDRs that should be routed through the TGW.
Configure TGW Route Tables
Create TGW route tables as needed for different traffic domains. Associate each attachment with a route table (each attachment can be associated with only one). Then configure propagation: for each attachment, you can propagate its routes to one or more route tables. For example, a VPN attachment's BGP routes can propagate to the route table associated with VPC attachments. Static routes can also be added directly to a route table.
Update VPC Route Tables
In each VPC, add routes to the VPC route tables for destination CIDRs that are reachable via the TGW. For example, if VPC A needs to reach VPC B (CIDR 10.0.2.0/24) through the TGW, add a route in VPC A's route table with destination 10.0.2.0/24 and target the TGW attachment ID. Without these routes, traffic from the VPC will not be sent to the TGW. Similarly, on-premises CIDRs must be added to VPC route tables.
Connect On-Premises via VPN
Create a VPN attachment to the TGW. Specify the customer gateway (CGW) device's public IP and BGP ASN. The TGW generates two tunnel endpoints with pre-shared keys. Configure the CGW to establish IPsec tunnels. BGP sessions are established over the tunnels, and routes are exchanged. The VPN attachment propagates its BGP routes to the associated TGW route table. Ensure the on-premises network has routes back to the VPC CIDRs via the VPN tunnels.
Enterprise Scenario 1: Multi-VPC Network with Isolated Environments A large enterprise runs hundreds of microservices across 50 VPCs in a single region. They need to separate production, staging, and development environments. They deploy a single Transit Gateway with three route tables: prod-rtb, staging-rtb, and dev-rtb. Each VPC attachment is associated with the appropriate route table. Propagation is configured so that only VPCs within the same environment can communicate. Additionally, a VPN attachment to the corporate data center is associated with all three route tables, allowing on-premises access to all environments. The TGW handles transitive routing, eliminating the need for VPC peering. The network team uses TGW Network Manager to monitor traffic and troubleshoot connectivity issues. Misconfiguration occurs when a developer accidentally propagates a dev VPC's routes to the prod route table, causing cross-environment traffic. This is prevented by using AWS Resource Access Manager to share the TGW and enforcing strict IAM policies.
Enterprise Scenario 2: Hybrid Cloud with Direct Connect A financial services company uses AWS Direct Connect to connect its on-premises data center to AWS. They have 20 VPCs that need to communicate with each other and with on-premises. Instead of creating multiple Direct Connect virtual interfaces (VIFs), they attach a Direct Connect Gateway to a Transit Gateway. The Direct Connect Gateway connects to the on-premises network via a private VIF. All VPCs are attached to the TGW. This setup reduces the number of BGP sessions and simplifies routing. The TGW route table propagates routes from the Direct Connect Gateway (on-premises CIDRs) to all VPC attachments. VPC CIDRs are propagated to the Direct Connect Gateway via the TGW. A common pitfall is not enabling route propagation from the Direct Connect Gateway to the TGW route table, causing on-premises routes to be missing. Additionally, if the TGW route table has overlapping CIDRs, the most specific route wins, which can cause unexpected blackholing.
Scenario 3: Inter-Region Connectivity A global e-commerce company has VPCs in us-east-1 and eu-west-1. They create a Transit Gateway in each region and peer them using a TGW peering attachment. This allows VPCs in different regions to communicate over the AWS global network, avoiding the public internet. The peering attachment is created in the source region and accepted in the destination region. Static routes are added to the TGW route tables to direct inter-region traffic to the peering attachment. The company uses TGW Network Manager to visualize the global network. Performance is good, but latency is higher than intra-region. A common mistake is forgetting to add routes in both directions, causing one-way traffic. Also, TGW peering does not support transitive routing: if TGW A is peered with TGW B, and TGW B is peered with TGW C, traffic from A to C must go through B's TGW route table, which requires proper route propagation.
The SOA-C02 exam tests Transit Gateway under Objective 5.1: 'Implement network connectivity patterns' and 5.2: 'Configure network features'. Expect 3-5 questions on TGW, often in scenario-based formats. Key areas tested: 1. Transitive Routing: The exam emphasizes that TGW enables transitive routing between attachments, unlike VPC peering. A common wrong answer is suggesting VPC peering for multi-VPC connectivity when TGW is the correct choice, especially when the scenario involves more than a few VPCs or requires VPN/Direct Connect integration. 2. Route Table Association and Propagation: Questions often ask which route table is used for incoming traffic (association) and how routes are learned (propagation). A frequent trap: candidates think propagation determines which route table is used for traffic from the attachment. Reality: association determines the route table for incoming traffic; propagation adds routes to the route table. 3. VPN ECMP: The exam tests that TGW supports ECMP for VPN attachments to increase bandwidth. Wrong answer: using multiple VPN tunnels but not enabling ECMP, or assuming ECMP works with static routing (it requires BGP). 4. Default Route Table: By default, all attachments are associated with and propagate to the default route table. The exam may ask how to isolate traffic — answer: create separate route tables and do not attach/propagate to the default. 5. Inter-Region Peering: Know that TGW peering is not transitive and requires explicit routes. A common wrong answer is assuming that peering provides transitive routing across multiple TGWs. 6. Direct Connect Integration: Understand that a Direct Connect Gateway must be attached to the TGW, and the DXGW connects to on-premises via a private VIF. The exam may ask about the number of VIFs needed — answer: one private VIF per DXGW, regardless of the number of VPCs. 7. Limits: Be aware of default limits (e.g., 5000 VPC attachments per TGW, 20 route tables). The exam may present a scenario with a large number of VPCs and ask what service to use — TGW is the answer. 8. Edge Cases: TGW does not support IPv6 transit. If a question involves IPv6 traffic between VPCs, TGW is not the solution (use VPC peering or IPv6-only TGW attachment with limitations). Also, TGW does not support multicast by default. 9. Terminology: Know the difference between association and propagation. The exam may ask: 'Which action allows a VPC's CIDR to be automatically added to a TGW route table?' Answer: propagation. 10. Troubleshooting: Questions may ask why traffic is not flowing. Common causes: missing routes in VPC route tables, incorrect TGW route table association, or propagation not enabled.
To eliminate wrong answers, focus on the underlying mechanism: TGW is a layer 3 router that uses route tables to forward packets. If an answer suggests that TGW performs NAT or is transparent, it is wrong. If an answer claims that TGW supports IPv6 transit, it is wrong. If an answer says that VPC peering is required for transitive routing, it is wrong.
Transit Gateway provides transitive routing between VPCs, VPNs, and Direct Connect gateways, replacing complex VPC peering meshes.
Each attachment is associated with exactly one TGW route table; propagation adds routes to route tables.
TGW does not support IPv6 transit; use VPC peering for IPv6.
Default route table association and propagation enable any-to-any connectivity by default.
VPN ECMP requires BGP and multiple tunnels; it increases bandwidth but not throughput per flow.
Inter-region TGW peering is not transitive; explicit static routes are needed.
Direct Connect Gateway attaches to TGW to provide hybrid connectivity with a single private VIF.
Maximum VPC attachments per TGW is 5,000 (default limit).
TGW does not perform NAT or packet inspection; it forwards based on IP destination.
Always update VPC route tables to point to the TGW attachment for destinations reachable via TGW.
These come up on the exam all the time. Here's how to tell them apart.
Transit Gateway
Supports transitive routing: one attachment can reach any other via the TGW.
Centralized management: single point for VPN/Direct Connect termination.
Scales to thousands of VPCs with a single TGW.
Supports inter-region peering via TGW peering.
Cost: per attachment per hour plus data processing fees.
VPC Peering
No transitive routing: each pair of VPCs requires a direct peering connection.
Decentralized: each peering is managed separately, no central hub.
Does not scale well: N*(N-1)/2 peerings for N VPCs.
Inter-region peering is supported but not transitive.
Cost: no hourly charge, only data transfer fees (usually lower than TGW).
Transit Gateway with VPN
Uses internet-based IPsec tunnels.
Bandwidth limited to VPN tunnel throughput (up to 1.25 Gbps per tunnel with ECMP).
Higher latency and jitter due to internet.
Lower cost for low-bandwidth or backup connectivity.
Quick to provision (minutes).
Direct Connect Gateway with TGW
Uses dedicated private network connection.
Bandwidth up to 10 Gbps per connection (scalable).
Consistent low latency and jitter.
Higher cost due to dedicated circuit.
Longer provisioning time (weeks).
Mistake
Transit Gateway supports transitive routing across peered TGWs automatically.
Correct
TGW peering does not provide transitive routing. If TGW A is peered with TGW B and TGW B is peered with TGW C, traffic from A to C must be explicitly routed through B's route table. You must add static routes in A's route table pointing to the peering attachment to B, and in B's route table pointing to the peering attachment to C. Propagation does not work across peering attachments.
Mistake
A TGW route table can be associated with multiple attachments and each attachment can be associated with multiple route tables.
Correct
A TGW route table can be associated with multiple attachments, but each attachment can be associated with only one route table. The association determines which route table is used for incoming traffic from that attachment. An attachment can propagate its routes to multiple route tables, but it has only one association.
Mistake
TGW supports IPv6 traffic between VPCs.
Correct
TGW does not support IPv6 transit. IPv6 traffic sent to a TGW attachment is dropped. For IPv6 connectivity between VPCs, use VPC peering or an IPv6-only TGW attachment (which is not commonly used). TGW only forwards IPv4 traffic.
Mistake
You can use a single VPN attachment to connect multiple on-premises sites to a TGW.
Correct
A VPN attachment connects a single customer gateway (CGW) to the TGW. To connect multiple on-premises sites, you need multiple VPN attachments (one per CGW) or use a Direct Connect Gateway. Each VPN attachment has its own tunnels and BGP sessions.
Mistake
TGW automatically routes traffic between all attachments without any configuration.
Correct
By default, if you enable default route table association and propagation, all attachments are associated with and propagate to the default route table, which allows any-to-any connectivity. However, you must still update VPC route tables to direct traffic to the TGW. Additionally, if you create custom route tables and do not configure propagation, traffic will not flow.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Association determines which TGW route table is used for incoming traffic from a specific attachment. Each attachment can be associated with only one route table. Propagation determines which routes from an attachment are automatically added to one or more TGW route tables. For example, a VPC attachment can propagate its CIDR to multiple route tables, but its incoming traffic is only evaluated against the associated route table. In short: association = inbound routing lookup; propagation = route advertisement.
Yes, by creating a TGW peering attachment between Transit Gateways in different regions. The peering attachment connects the two TGWs over the AWS global network. You must add static routes in each TGW's route table pointing to the peering attachment for the remote VPC CIDRs. Note that TGW peering does not support transitive routing, so traffic from a VPC in region A to a VPC in region C via region B requires explicit routing.
Yes, Transit Gateway supports multicast traffic but requires a multicast domain. You create a multicast domain within the TGW and add attachments to it. The TGW will forward multicast traffic between group members. However, multicast is not commonly tested on SOA-C02, and the feature has limitations (e.g., no inter-region multicast). For most exam scenarios, assume TGW does not support multicast unless explicitly stated.
First, verify that the VPC route tables have routes pointing to the TGW attachment for the destination CIDR. Second, check the TGW route table associated with the source attachment to ensure it has a route to the destination (either static or propagated). Third, verify that the destination VPC's route table has a return route. Use AWS CloudWatch metrics for TGW attachments to see if packets are being dropped. Also check that security groups and network ACLs allow the traffic. Finally, ensure that the TGW attachment state is 'available'.
The default Amazon side ASN for a Transit Gateway is 64512 (a private ASN). You can specify a different ASN when creating the TGW, but it cannot be changed later. The ASN is used for BGP sessions with VPN attachments and Direct Connect Gateway. If you have existing BGP configurations, you may need to choose a non-default ASN to avoid conflicts.
Yes, you can attach multiple VPCs in the same region to a single Transit Gateway without any VPN or Direct Connect. The TGW provides layer 3 routing between the VPCs. You need to create VPC attachments, configure TGW route tables, and update VPC route tables. This is the primary use case for TGW: simplifying multi-VPC connectivity.
Yes, Transit Gateway supports jumbo frames (MTU 8500) for VPC attachments. However, VPN attachments only support standard MTU (1500 bytes). If you have a mix of attachments, packets may need to be fragmented. TGW does not fragment packets; it drops packets larger than the attachment's MTU. Ensure that the path MTU is consistent across all attachments.
You've just covered Transit Gateway for Network Architecture — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?