Transit Gateway is the AWS-native way to connect your Virtual Private Clouds (VPCs) and on-premises networks. It acts as a central hub, eliminating the need for complex, many-to-many VPC peering connections that become unmanageable as your network grows. Instead of each VPC needing to peer with every other VPC, they simply peer with the Transit Gateway.
Let’s see it in action. Imagine you have three VPCs: vpc-app (10.0.1.0/24), vpc-db (10.0.2.0/24), and vpc-web (10.0.3.0/24). Without Transit Gateway, to allow vpc-app to talk to vpc-db, you’d create a VPC peering connection between them. If vpc-web also needed to talk to vpc-db, you’d create another peering connection. This quickly becomes a sprawling mess.
With Transit Gateway, you create a single Transit Gateway resource. Then, you create "attachments" from each of your VPCs to this Transit Gateway.
# Example CLI commands (conceptual, actual values vary)
# 1. Create the Transit Gateway
aws ec2 create-transit-gateway --options "AmazonSideAsn=64512" --region us-east-1
# 2. Attach VPCs to the Transit Gateway
aws ec2 create-transit-gateway-vpc-attachment \
--transit-gateway-id tgw-0123456789abcdef0 \
--vpc-id vpc-0abcdef1234567890 \
--subnet-ids subnet-0123456789abcdef0 \
--region us-east-1
aws ec2 create-transit-gateway-vpc-attachment \
--transit-gateway-id tgw-0123456789abcdef0 \
--vpc-id vpc-0fedcba9876543210 \
--subnet-ids subnet-0fedcba9876543210 \
--region us-east-1
# 3. Create Transit Gateway Route Tables (often one default, or custom ones)
# The Transit Gateway has its own routing mechanism, separate from VPC route tables.
# 4. Update VPC Route Tables to point traffic to the Transit Gateway
# For vpc-app (10.0.1.0/24) to reach vpc-db (10.0.2.0/24):
aws ec2 create-route \
--route-table-id rtb-0123456789abcdef0 \
--destination-cidr-block 10.0.2.0/24 \
--transit-gateway-id tgw-0123456789abcdef0 \
--region us-east-1
# For vpc-app (10.0.1.0/24) to reach vpc-web (10.0.3.0/24):
aws ec2 create-route \
--route-table-id rtb-0123456789abcdef0 \
--destination-cidr-block 10.0.3.0/24 \
--transit-gateway-id tgw-0123456789abcdef0 \
--region us-east-1
# Repeat for other VPCs to allow them to route to each other via TGW.
The core concept is the Transit Gateway Route Table. When a packet arrives at the Transit Gateway from a VPC attachment, the TGW looks at the destination IP address and consults its own route table to decide which attachment to send the packet to next. This is the central control plane. You associate VPC attachments with specific TGW route tables.
Think of it like a central post office. Instead of every house (VPC) needing a direct mail route to every other house, all mail goes to the post office (Transit Gateway). The post office then sorts the mail based on the destination address and sends it out on the correct outgoing route (attachment).
This model scales because you only add new VPCs as attachments to the single Transit Gateway. The complexity of inter-VPC routing is managed within the Transit Gateway’s route tables, not by a web of direct peering connections. You can also connect VPNs and Direct Connect gateways to the same Transit Gateway, creating a unified network fabric.
The "gateway" in Transit Gateway is significant: it’s not just a router; it’s a network transit point. Each VPC attachment is placed in a specific subnet within that VPC. The Transit Gateway itself spans multiple Availability Zones (AZs) for high availability. When you create an attachment, you select one subnet in one AZ for that attachment. The Transit Gateway then manages the ENIs (Elastic Network Interfaces) for that attachment across AZs.
The most surprising thing about Transit Gateway is how it handles overlapping CIDR blocks. Unlike VPC peering, which strictly forbids overlapping CIDRs between peered VPCs, Transit Gateway can connect VPCs with overlapping CIDRs. This is because the routing decision is made at the Transit Gateway level, and the source/destination IPs are preserved. The TGW doesn’t need to know about the global network’s IP space; it only needs to know which attachment to send traffic to based on the specific VPC it arrived from. This is a massive architectural advantage for mergers, acquisitions, or simply evolving cloud footprints.
You can also configure Transit Gateway Route Propagation. Instead of manually adding routes in the TGW route table for every CIDR block in every attached VPC, you can enable propagation. When propagation is enabled for a VPC attachment, the TGW automatically adds routes for that VPC’s CIDR blocks to the associated TGW route table. This is incredibly useful for dynamic environments.
To manage security and traffic flow, you can use Transit Gateway Network Manager. This allows you to visualize your network topology, monitor traffic, and enforce policies across your connected VPCs and on-premises sites. You can also implement segmentation using separate TGW route tables and associations, controlling which VPCs can communicate with each other.
The next step after mastering basic connectivity is understanding Transit Gateway Route Amplifiers and inter-region peering.