AWS Networking & CDN
Transit Gateway
Central network hub connecting thousands of VPCs and on-premises networks
AWS Transit Gateway acts as a regional network hub that connects VPCs and on-premises networks through a central point, eliminating the need for complex VPC peering meshes. It supports thousands of attachments, enables transitive routing, and provides centralized control over inter-VPC and hybrid network traffic flows.
Transit Gateway Architecture and Components
Transit Gateway (TGW) replaces a web of VPC peering connections with a hub-and-spoke model. Each spoke attaches to the TGW, and routing tables on the TGW control which spokes can communicate.
| Component | Description | Key Limit |
|---|---|---|
| TGW | Regional virtual router; one per region per account (shareable via RAM) | Up to 5,000 attachments |
| Attachment | Connects a VPC, VPN, DX, or TGW peer to the hub | One subnet per AZ per VPC attachment (recommend all AZs) |
| TGW Route Table | Controls which attachments can route to which targets | Multiple route tables enable segmentation |
| Route Propagation | Attachments can propagate their CIDRs to TGW route tables | Automatic vs static routes |
| Association | Links an attachment to a specific TGW route table | Each attachment associated with exactly one route table |
| Peering | Connect TGWs across regions or accounts | Static routes only; no route propagation across peers |
Always attach a subnet in every AZ you use for each VPC. If you only attach us-east-1a, traffic from resources in us-east-1b must cross AZs to reach the TGW attachment, incurring data transfer charges and adding latency.
Routing and Network Segmentation
TGW's multiple route tables enable network segmentation without complex firewall rules. Common patterns include separating production from development and inspecting traffic centrally.
| Pattern | Route Table Design | Use Case |
|---|---|---|
| Full mesh (simple) | One route table, all attachments associate and propagate | Small environments; all VPCs can talk to each other |
| Segmented (prod vs dev) | Separate route tables per tier; no cross-propagation | Prevent dev VPCs from reaching prod; compliance isolation |
| Centralized inspection | All VPCs default route to security VPC with firewall | Inline inspection via Network Firewall or third-party NVA |
| Shared services | Shared services VPC propagates to all; others propagate to shared only | DNS, AD, monitoring VPCs accessible by all |
For centralized egress inspection, route VPC default routes (0.0.0.0/0) through the TGW to a centralized security VPC that contains a Network Firewall or NAT Gateway. This reduces NAT Gateway costs (one instead of one per VPC) and provides a single inspection point.
# Create a Transit Gateway
aws ec2 create-transit-gateway \
--description "Central hub" \
--options AmazonSideAsn=64512,AutoAcceptSharedAttachments=disable,DefaultRouteTableAssociation=disable,DefaultRouteTablePropagation=disable
# Attach a VPC to Transit Gateway
aws ec2 create-transit-gateway-vpc-attachment \
--transit-gateway-id tgw-xxxx \
--vpc-id vpc-xxxx \
--subnet-ids subnet-aaa subnet-bbbTransit Gateway vs VPC Peering
| Aspect | VPC Peering | Transit Gateway |
|---|---|---|
| Transitive routing | No | Yes |
| Number of connections | N*(N-1)/2 for full mesh | N connections to one TGW |
| Management complexity | Increases quadratically with VPC count | Linear; centrally managed |
| Bandwidth | No limit (uses AWS backbone) | 50 Gbps per VPC attachment |
| Cost | Data transfer only ($0.01/GB cross-AZ) | Attachment ($0.05/hr) + data ($0.02/GB) |
| Cross-account/region | Yes (both) | Yes (peering for cross-region) |
| Routing control | Route table per VPC only | Centralized TGW route tables |
| Best for | 2-3 VPCs; simple connectivity | 4+ VPCs; complex routing; hybrid networks |
For fewer than 3-4 VPCs with simple connectivity needs, VPC Peering is cheaper and simpler. TGW overhead ($36/month per attachment) only pays off when you have many VPCs or need centralized routing control.
Multicast, Inter-Region Peering, and Pricing
TGW supports multicast traffic delivery and inter-region TGW peering for global architectures.
| Component | Cost | Notes |
|---|---|---|
| VPC attachment | $0.05/hr (~$36/month) | Per attachment regardless of traffic |
| VPN attachment | $0.05/hr | Per VPN connection |
| Direct Connect attachment | $0.05/hr | Via Transit VIF |
| Data processing | $0.02/GB | All traffic through TGW |
| Peering attachment | $0.05/hr per attachment | Cross-region data transfer also charged |
| Multicast | Additional per-hour + per-GB rates | Opt-in feature |
TGW data processing charges apply to ALL traffic - including VPC-to-VPC traffic that would be free with VPC Peering. For high-bandwidth workloads (e.g., big data pipelines between VPCs), calculate whether TGW data costs outweigh peering complexity.
Interview Focus Points
- 1When would you use Transit Gateway instead of VPC Peering? What is the break-even point?
- 2Explain how TGW route tables enable network segmentation between production and development.
- 3How would you design centralized egress with inspection using Transit Gateway and Network Firewall?
- 4What is the difference between route table association and route propagation in Transit Gateway?
- 5How does TGW handle cross-region connectivity? What are the limitations?
- 6Explain how you would migrate from a VPC Peering mesh to Transit Gateway with zero downtime.
- 7What happens to traffic routing when a TGW attachment subnet is in only one AZ?
- 8How does Transit Gateway connect to on-premises via Direct Connect?