This chapter covers AWS Transit Gateway, a central hub for interconnecting VPCs, VPNs, and Direct Connect. Transit Gateway is a high-impact topic for the SAA-C03 exam, appearing in approximately 10-15% of questions, often in scenarios requiring scalable network connectivity. You will learn its architecture, routing mechanisms, and how to design multi-VPC and hybrid networks using Transit Gateway. Mastery of this service is essential for designing secure, efficient, and cost-effective network topologies at scale.
Jump to a section
Think of AWS Transit Gateway as a major airline hub airport, like Atlanta Hartsfield-Jackson. Your VPCs are individual cities (e.g., New York, Los Angeles, Chicago) that each have their own local airport. Without a hub, flying between New York and Los Angeles would require a direct flight, which is expensive and hard to manage as more cities join — you'd need a direct route between every pair (full mesh). With the hub, all flights go through Atlanta. A passenger flying from New York to Los Angeles takes a flight from New York to Atlanta, then a connecting flight from Atlanta to Los Angeles. The hub handles all the routing, security checks, and baggage transfers. Similarly, Transit Gateway acts as the central hub: each VPC connects to the Transit Gateway via a single attachment, and the Transit Gateway routes traffic between all attached VPCs and on-premises networks. Just as the hub can handle flights to many cities simultaneously, Transit Gateway can scale to thousands of VPC attachments. The hub also inspects and controls traffic — like a security checkpoint — using route tables and network firewall policies. If a new city (VPC) joins, it only needs one connection to the hub, not connections to every other city. This eliminates complex peering relationships and reduces operational overhead.
What is AWS Transit Gateway and Why Does It Exist?
AWS Transit Gateway (TGW) is a fully managed service that acts as a network transit hub to interconnect Virtual Private Clouds (VPCs), AWS VPN connections, and AWS Direct Connect gateways. Before Transit Gateway, connecting multiple VPCs required either VPC peering (which is a 1:1 relationship, not transitive) or complex VPN setups. VPC peering does not support transitive routing — if VPC A is peered with VPC B and VPC B is peered with VPC C, traffic from A to C cannot flow through B. This forced architects to create either a full mesh of peering connections (O(n²) complexity) or use a third-party virtual appliance (e.g., a router in an EC2 instance) to act as a hub. Transit Gateway solves this by providing a single, scalable hub that supports transitive routing between all attachments, reducing network complexity and operational overhead.
Transit Gateway is a Regional resource. You can attach up to 5000 VPCs per Transit Gateway (default limit, adjustable), and each VPC attachment supports up to 50 Gbps of bandwidth per Availability Zone. The service uses a routing table per Transit Gateway, with separate route tables for attachments to control traffic flow.
How Transit Gateway Works Internally
Transit Gateway operates at Layer 3 (IP) of the OSI model, routing packets based on destination IP addresses. When a packet arrives from an attachment (e.g., a VPC), the Transit Gateway performs the following: 1. Receives the packet on the attachment interface. 2. Looks up the destination IP in the Transit Gateway route table associated with that attachment. 3. If a matching route is found, forwards the packet to the target attachment (another VPC, VPN, or Direct Connect). 4. If no match exists, the packet is dropped (no default route unless explicitly configured).
Each attachment has an associated route table. By default, all attachments are associated with the default route table, which can be modified. You can create multiple route tables to isolate traffic — for example, a production route table for prod VPCs and a development route table for dev VPCs. Routes can point to other attachments or to a blackhole (to drop traffic).
Transit Gateway supports multicast (using a Transit Gateway multicast domain) and inter-Region peering (connecting Transit Gateways in different AWS Regions). Inter-Region peering uses AWS’s global network backbone, providing high bandwidth and low latency.
Key Components, Values, Defaults, and Timers
Transit Gateway: The hub itself. Default limits: 5000 VPC attachments, 1000 route tables, 10,000 routes per route table (all adjustable via service quotas).
Attachments: Each VPC, VPN connection, Direct Connect Gateway, or Transit Gateway peering connection is an attachment. VPC attachments require subnets in each Availability Zone where the Transit Gateway will be used (at least one subnet per AZ).
Route Tables: Each attachment is associated with exactly one route table. A route table can have multiple associations. Routes have a destination CIDR and a target attachment. The most specific route (longest prefix match) wins.
Propagation: Attachments can propagate their routes into a route table automatically. For VPC attachments, the VPC’s CIDR is propagated. For VPN attachments, the BGP-advertised routes are propagated. You control which route tables receive propagated routes.
Transit Gateway Peering: Connects two Transit Gateways in different Regions. Requires a peering attachment on each side. Routes must be manually added or propagated.
Default Route Table: Created automatically. All new attachments are associated with it unless specified otherwise. You can modify it or create custom ones.
Multicast: Supports IGMPv2. Requires a multicast domain and multicast group associations.
Flow Logs: Capture IP traffic information for Transit Gateway attachments. Logs can be sent to CloudWatch Logs or S3.
Network Manager: A service that provides a global view of your network, including Transit Gateway, on-premises devices, and VPCs.
Cost: Charged per attachment per hour, plus data processing per GB. Inter-Region peering adds data transfer costs.
Configuration and Verification Commands
Using AWS CLI to create a Transit Gateway:
aws ec2 create-transit-gateway --description "My TGW" --options AmazonSideAsn=64512To attach a VPC:
aws ec2 create-transit-gateway-vpc-attachment --transit-gateway-id tgw-0abcd1234 --vpc-id vpc-12345678 --subnet-ids subnet-11111111 subnet-22222222To create a route table:
aws ec2 create-transit-gateway-route-table --transit-gateway-id tgw-0abcd1234To associate an attachment with a route table:
aws ec2 associate-transit-gateway-route-table --transit-gateway-route-table-id tgw-rtb-0abcd1234 --transit-gateway-attachment-id tgw-attach-0abcd1234To propagate routes:
aws ec2 enable-transit-gateway-route-table-propagation --transit-gateway-route-table-id tgw-rtb-0abcd1234 --transit-gateway-attachment-id tgw-attach-0abcd1234Verification commands:
aws ec2 describe-transit-gateways
aws ec2 describe-transit-gateway-attachments
aws ec2 describe-transit-gateway-route-tables
aws ec2 search-transit-gateway-routes --transit-gateway-route-table-id tgw-rtb-0abcd1234 --filters "Name=route-search.exact-match,Values=10.0.0.0/16"Interaction with Related Technologies
VPC Peering: Transit Gateway does not replace VPC peering for all use cases. VPC peering is still useful for simple 1:1 connections where transitive routing is not needed, or when you want to avoid data processing costs (VPC peering has no per-GB charge, while Transit Gateway charges for data processing). However, VPC peering does not support transitive routing, so for more than two VPCs, Transit Gateway is usually better.
VPN: Transit Gateway can terminate VPN connections (Site-to-Site VPN) from on-premises. You attach a VPN attachment to the Transit Gateway, and routes from the VPN (via BGP) propagate into the Transit Gateway route table. This enables hybrid connectivity.
Direct Connect: Transit Gateway integrates with Direct Connect Gateway (DXGW). You create a Direct Connect Gateway and associate it with a Transit Gateway via a Direct Connect Gateway attachment. This allows on-premises networks connected via Direct Connect to reach VPCs attached to the Transit Gateway.
AWS PrivateLink: Transit Gateway can route traffic to VPC endpoints (e.g., VPC Endpoint services) but does not natively integrate with PrivateLink. However, you can use Transit Gateway to route traffic to a VPC that hosts a PrivateLink endpoint.
Network Firewall: AWS Network Firewall can be deployed in a VPC attached to Transit Gateway to inspect traffic between VPCs. You can also use Transit Gateway route tables to send traffic to a firewall VPC for inspection.
AWS RAM (Resource Access Manager): You can share a Transit Gateway with other AWS accounts within your organization, allowing centralized management of network connectivity.
Create Transit Gateway
Use the AWS Management Console, CLI, or CloudFormation to create a Transit Gateway. Specify options like Amazon side ASN (default 64512), DNS support (enables DNS resolution via the Transit Gateway), VPN ECMP support (for load balancing across multiple VPN tunnels), and default route table association/propagation. The Transit Gateway is created in a specific AWS Region. Once created, it appears as a resource with a unique ID (e.g., tgw-0abcd1234). No attachments are present yet.
Attach VPCs
For each VPC you want to connect, create a VPC attachment. Specify the Transit Gateway ID, VPC ID, and at least one subnet per Availability Zone (the Transit Gateway uses these subnets to route traffic). The attachment state transitions from 'pending' to 'available'. During this process, AWS creates an elastic network interface (ENI) in each specified subnet. These ENIs are the endpoints through which traffic enters/exits the Transit Gateway. The VPC's route tables are not automatically updated; you must manually add routes to direct traffic to the Transit Gateway.
Configure Route Tables
Create one or more route tables in the Transit Gateway. By default, a default route table exists. Associate each attachment with a route table. If you want transitive routing between all VPCs, associate all VPC attachments with the same route table. For isolation, use separate route tables. Also, enable route propagation for attachments that should advertise their routes. For VPC attachments, propagation automatically adds the VPC CIDR to the route table. For VPN attachments, BGP-advertised routes are propagated.
Update VPC Route Tables
In each VPC, add routes to the VPC route tables pointing to the Transit Gateway attachment. For example, to send traffic from VPC A to VPC B (10.0.2.0/24), add a route in VPC A's route table with destination 10.0.2.0/24 and target the Transit Gateway attachment ID (e.g., tgw-attach-0abcd1234). Similarly, add routes for other VPCs and on-premises networks. Without these routes, traffic from the VPC will not enter the Transit Gateway.
Verify Connectivity
Test connectivity between instances in different VPCs using ping or traceroute. Verify that traffic flows through the Transit Gateway by checking flow logs or using trace tools. Use the AWS CLI command `aws ec2 search-transit-gateway-routes` to confirm that the Transit Gateway route table contains the expected routes. Also, check VPC route tables for correct entries. Common issues: missing routes in VPC route tables, incorrect association/propagation, or security group/network ACL blocking traffic.
Enterprise Scenario 1: Multi-VPC Application Architecture
A large e-commerce company runs a three-tier application across multiple VPCs: a web tier VPC, an application tier VPC, and a database tier VPC. They also have separate VPCs for development, staging, and production environments. Initially, they used VPC peering, resulting in a complex mesh of over 30 peering connections. Troubleshooting connectivity issues was painful because VPC peering is not transitive — if a new VPC was added, they had to create peering connections to every other VPC. They migrated to Transit Gateway by creating a single Transit Gateway and attaching all VPCs. They configured three route tables: one for production VPCs, one for non-production, and one shared route table for common services (e.g., Active Directory). Route propagation was enabled for each VPC attachment. Production VPCs could communicate with each other but not with non-production VPCs. The migration reduced the number of connections from 30 to 10 (one per VPC plus a few VPN attachments). They also used Transit Gateway Network Manager to visualize the network topology and monitor traffic.
Enterprise Scenario 2: Hybrid Cloud with Direct Connect
A financial services firm has a data center connected to AWS via Direct Connect. They need to connect multiple VPCs to the data center and allow VPC-to-VPC communication. They set up a Direct Connect Gateway and associated it with a Transit Gateway. The Transit Gateway acts as the hub for all VPCs and the on-premises network. They created a VPN attachment as a backup for Direct Connect. Route propagation from the Direct Connect Gateway and VPN attachment injected on-premises routes into the Transit Gateway route table. VPC attachments propagated their CIDRs. They used BGP communities to control route propagation — for example, tagging routes from the data center with a community that only propagates to production VPCs. They also implemented AWS Network Firewall in a dedicated inspection VPC attached to the Transit Gateway to inspect traffic between VPCs and the data center. The setup handles 10 Gbps of traffic with low latency. A common misconfiguration was forgetting to update VPC route tables to point to the Transit Gateway for on-premises destinations, causing asymmetric routing.
Enterprise Scenario 3: Mergers and Acquisitions
A company acquires another company that already has AWS infrastructure. The two organizations have overlapping IP addresses (e.g., both use 10.0.0.0/16). They need to connect their networks for integration but cannot change IPs immediately. They use Transit Gateway with separate route tables and network address translation (NAT) in a shared services VPC. Each VPC is attached to the Transit Gateway but associated with different route tables. They deploy NAT instances in a shared VPC to translate overlapping IPs. The Transit Gateway routes traffic to the NAT VPC, which performs translation and forwards to the destination. This allows gradual migration without downtime. The challenge is managing route tables and ensuring that traffic does not loop. They use blackhole routes to drop unwanted traffic. This solution is complex but avoids costly re-IP efforts.
What SAA-C03 Tests on Transit Gateway
The SAA-C03 exam focuses on understanding when to use Transit Gateway versus VPC peering, how to design for transitive routing, and how to integrate with hybrid connectivity (VPN, Direct Connect). Key objectives in Domain 1.1 (Secure Architectures) include designing a network topology that scales, is secure, and cost-effective. Specific exam topics:
Transitive routing: The exam expects you to know that VPC peering does not support transitive routing, while Transit Gateway does.
Route tables and propagation: You may be asked how to isolate traffic between VPCs using separate route tables.
Inter-Region peering: Questions may test that Transit Gateway peering connects Transit Gateways in different Regions and requires manual route propagation.
Integration with Direct Connect: You should know that Direct Connect Gateway can be associated with a Transit Gateway to connect on-premises networks.
Cost implications: Transit Gateway has per-attachment and data processing costs; VPC peering has no data processing charge.
Common Wrong Answers and Why Candidates Choose Them
"Use VPC peering because it is simpler and cheaper." While VPC peering is simpler for two VPCs, it does not scale beyond a few VPCs due to lack of transitive routing. Candidates often forget that VPC peering is not transitive. The exam will present a scenario with 10+ VPCs needing full connectivity; the correct answer is Transit Gateway.
"Transit Gateway supports transitive routing by default without route tables." Actually, Transit Gateway uses route tables to control traffic flow. Without proper configuration, traffic may be dropped. Candidates might assume that attaching all VPCs to the same Transit Gateway automatically allows all-to-all communication, but you must associate attachments with the same route table and enable propagation.
"Transit Gateway can replace Direct Connect Gateway." Transit Gateway integrates with Direct Connect Gateway but does not replace it. Direct Connect Gateway is still needed to connect Direct Connect connections to multiple Transit Gateways or VPCs. Candidates may confuse the roles.
"Transit Gateway peering automatically propagates routes between Regions." Route propagation is not automatic for peering attachments. You must manually add static routes or enable propagation from the peering attachment. The exam may test this nuance.
Specific Numbers and Terms
Default ASN for Transit Gateway: 64512
Maximum VPC attachments per Transit Gateway: 5000 (default)
Maximum routes per route table: 10,000
Data processing cost: per GB (varies by Region)
Inter-Region peering: data transfer charges apply (higher than intra-Region)
VPN ECMP support: up to 4 tunnels (equal-cost multi-path)
Edge Cases and Exceptions
Overlapping CIDRs: If two VPCs have overlapping IP ranges, Transit Gateway cannot route between them without NAT. The exam may ask how to handle this (e.g., use NAT in a shared VPC or use separate route tables with blackhole routes).
Transit Gateway in a different account: You can share a Transit Gateway via AWS RAM. The exam may test that the Transit Gateway must be in the same Region as the VPC attachments (unless using inter-Region peering).
Multicast: Transit Gateway supports multicast, but only within a single Region and requires a multicast domain. This is a less common topic but may appear.
How to Eliminate Wrong Answers
If the question mentions "transitive routing" or "hub-and-spoke," the answer is likely Transit Gateway.
If the question involves many VPCs (more than 3-4) needing full connectivity, eliminate VPC peering.
If the question involves hybrid connectivity (on-premises), consider Transit Gateway with VPN or Direct Connect Gateway.
Look for keywords like "centralized management," "scalable," "reduced complexity."
Pay attention to cost: if the scenario emphasizes low cost and only two VPCs, VPC peering may be correct.
Transit Gateway provides a hub-and-spoke model for transitive routing between VPCs, VPNs, and Direct Connect.
VPC peering does not support transitive routing; use Transit Gateway for more than two VPCs needing full connectivity.
Each Transit Gateway attachment must be associated with a route table; propagation must be enabled for automatic route injection.
Transit Gateway supports inter-Region peering, but routes must be manually configured or propagated.
Default Transit Gateway ASN is 64512; maximum VPC attachments is 5000 (adjustable).
Transit Gateway costs include hourly attachment fees and data processing per GB; VPC peering has no data processing fee.
Use AWS RAM to share a Transit Gateway across accounts in the same organization.
For overlapping CIDRs, use NAT or separate route tables with blackhole routes.
These come up on the exam all the time. Here's how to tell them apart.
AWS Transit Gateway
Supports transitive routing between all attachments
Scales to thousands of VPCs with a single hub
Charges per attachment and data processing
Integrates with VPN and Direct Connect
Centralized management with route tables
VPC Peering
No transitive routing (1:1 relationship only)
Complex full mesh for many VPCs (O(n^2) connections)
No data processing charges (only inter-AZ/Region transfer)
Cannot connect to on-premises directly
No central routing control; each peering has its own route table
Mistake
Transit Gateway automatically allows all VPCs to communicate with each other once attached.
Correct
No. You must associate VPC attachments with the same route table and enable route propagation. Without these steps, traffic will not flow between VPCs.
Mistake
Transit Gateway supports transitive routing across VPC peering connections.
Correct
Transit Gateway does not use VPC peering; it uses its own attachments. VPC peering is a separate feature and does not integrate with Transit Gateway for transitive routing.
Mistake
Transit Gateway can be used across AWS accounts without AWS RAM.
Correct
To share a Transit Gateway with another account, you must use AWS Resource Access Manager (RAM). You cannot simply attach a VPC from another account without sharing.
Mistake
Transit Gateway replaces the need for Direct Connect Gateway.
Correct
Transit Gateway works with Direct Connect Gateway but does not replace it. Direct Connect Gateway is still required to connect a Direct Connect connection to multiple Transit Gateways or VPCs.
Mistake
Inter-Region Transit Gateway peering automatically propagates routes.
Correct
No. You must manually add static routes or enable propagation for the peering attachment. Route propagation is not automatic for peering attachments.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Transit Gateway provides transitive routing between multiple VPCs and on-premises networks via a central hub, while VPC peering is a direct 1:1 connection between two VPCs without transitive routing. For more than two VPCs, Transit Gateway reduces complexity. VPC peering has no data processing charges, but Transit Gateway charges per attachment and per GB. Use VPC peering for simple, low-cost connections between a few VPCs; use Transit Gateway for larger, more complex networks.
Each VPC attachment is associated with a Transit Gateway route table. When a packet arrives from a VPC, the Transit Gateway looks up the destination IP in the route table associated with the source attachment. If a route matches, the packet is forwarded to the target attachment (e.g., another VPC). Routes can be static or propagated from attachments. The most specific route (longest prefix match) is used. Without a matching route, the packet is dropped.
Yes, via Transit Gateway inter-Region peering. You create a peering attachment between two Transit Gateways in different Regions. Traffic flows over the AWS global network. Routes must be manually added or propagated in the route tables. Data transfer charges apply for inter-Region traffic. Note that Transit Gateway itself is Regional; peering connects two separate Transit Gateways.
You can connect via VPN (site-to-site VPN) or Direct Connect. For VPN, create a VPN attachment to the Transit Gateway and configure the on-premises VPN device. For Direct Connect, create a Direct Connect Gateway and associate it with the Transit Gateway via a Direct Connect Gateway attachment. Routes from on-premises are propagated into the Transit Gateway route table via BGP.
Transit Gateway cannot distinguish between overlapping IPs. Traffic destined to an overlapping CIDR will be routed to only one VPC (based on route table entries). To handle overlapping CIDRs, you must use separate route tables for each VPC and configure NAT in a shared VPC to translate addresses, or use blackhole routes to prevent unwanted traffic. This is a complex scenario often tested on the exam.
Yes, using AWS Resource Access Manager (RAM). You can share the Transit Gateway with other accounts within your AWS Organization or with individual accounts. The shared Transit Gateway can then be used by the recipient account to attach their VPCs. The Transit Gateway remains in the owner account, and the owner manages route tables.
Yes, Transit Gateway supports multicast using IGMPv2. You create a multicast domain, associate multicast groups, and attach VPCs that need multicast. Only VPCs in the same Region can participate. This is a niche feature but may appear on the exam.
You've just covered AWS Transit Gateway — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?