Transit Gateway

🚇 What is AWS Transit Gateway?¶

AWS Transit Gateway (TGW) is a highly available, fully managed AWS service that acts as a central router to connect:

Multiple VPCs
Site-to-Site VPNs
AWS Direct Connect
Third-party appliances (via EC2 or partners)

✅ Think of it as a hub-and-spoke architecture to reduce complexity, cost, and management overhead.

🎯 Why Use Transit Gateway?¶

Use Case	Benefit
Connect 100s of VPCs securely	Centralized routing
Hybrid cloud with VPN and Direct Connect	Unified connectivity hub
Multi-region application communication	Cross-region peering
Replace VPC peering (complex at scale)	Simpler, scalable alternative

🧱 Key Components¶

Component	Description
Transit Gateway (TGW)	The core routing hub (like a virtual router)
Attachment	Connects a VPC, VPN, or DX to TGW
Route Table	Determines how traffic is routed through TGW
Propagation	Auto-learns routes from attachments
TGW Peering	Used to connect TGWs across regions

🎨 Architecture (Hub-and-Spoke)¶

                 +----------------+
                 | On-prem (VPN)  |
                 +----------------+
                        │
                        ▼
                  +-------------+              +-------------+
                  |   VPC-A     |◀────┐   ┌────▶   VPC-B     |
                  +-------------+     │   │     +-------------+
                                      ▼   ▼
                                +------------------+
                                |  Transit Gateway |
                                +------------------+
                                      ▲   ▲
                  +-------------+     │   │     +-------------+
                  |  Direct CX  |─────┘   └─────▶   VPC-C     |
                  +-------------+                     |
                                                   +-------------+
                                                   |  VPC-D (DR) |
                                                   +-------------+

🛠️ How to Create and Use a Transit Gateway¶

✅ Step 1: Create a Transit Gateway¶

Go to VPC > Transit Gateways > Create
Choose:
- Auto-accept shared attachments (optional)
- Default route table association/propagation
- DNS support
- Multicast support (if needed)
- ASN (for BGP if used)

aws ec2 create-transit-gateway \
  --description "Central TGW" \
  --options AmazonSideAsn=64512

✅ Step 2: Attach a VPC to TGW¶

Go to Transit Gateway Attachments > Create
Select:
- TGW ID
- VPC ID
- Subnets (in each AZ for HA)

aws ec2 create-transit-gateway-vpc-attachment \
  --transit-gateway-id tgw-abc123 \
  --vpc-id vpc-xyz456 \
  --subnet-ids subnet-aaa111 subnet-bbb222

⚠️ You must select at least one subnet per AZ to allow traffic through.

✅ Step 3: Update Route Tables¶

VPC Route Table:

Add a route for destination CIDR to TGW

Transit Gateway Route Table:

Associate and propagate attachments
Control what attachment can reach what destination

✅ Step 4: Add Other Attachments¶

You can attach:

VPN Connections
Direct Connect Gateways
Other VPCs
Peered TGWs (cross-region)

🧠 Route Table Strategy¶

You can create multiple TGW route tables for isolation.

Use Case	Strategy
Shared services	VPCs propagate to TGW shared route table
Dev/Prod isolation	Use separate TGW route tables
East-West routing	Use one table or custom ones

📦 Transit Gateway Peering¶

Enables TGW-to-TGW connection across AWS Regions
Fully private and uses AWS backbone
Supports IPv4 & IPv6, inter-region VPC communication

aws ec2 create-transit-gateway-peering-attachment \
  --transit-gateway-id tgw-123 \
  --peer-transit-gateway-id tgw-456 \
  --peer-region us-west-2

🧪 Monitoring and Logging¶

Feature	Use
CloudWatch Metrics	Packet count, bytes in/out, attachment status
VPC Flow Logs	Inspect traffic per interface
Transit Gateway Logging	Optional logging to CloudWatch or S3 (flow log-like)

🔐 Security Tips¶

Recommendation	Reason
Use IAM policies + Resource Access Manager (RAM)	Control who shares/attaches to TGW
Use separate route tables	Enforce segmentation/isolation
Tag attachments & route tables	Easier auditing
Log and monitor traffic	Troubleshooting and compliance

🆚 Transit Gateway vs VPC Peering vs PrivateLink¶

Feature	Transit Gateway	VPC Peering	PrivateLink
Pattern	Hub-and-spoke	Point-to-point	Service exposure
Transitive routing	✅ Yes	❌ No	❌ No
# of connections	1000+ VPCs	125 per VPC	50+ endpoints
Multi-account support	✅ Yes (via RAM)	✅ Yes	✅ Yes
Use case	Network hub	Simple 1:1 VPC link	SaaS or internal service exposure

✅ Best Practices¶

Tip	Why it Matters
Enable auto-propagation carefully	Avoid unintended route sharing
Use tags for attachments	Easier cost tracking and filtering
Create route tables per environment	Better isolation for Dev, Prod, Shared
Use with AWS Resource Access Manager	For cross-account VPC attachments
Monitor regularly	Avoid route conflicts and ensure HA

⚖️ Cost Overview¶

Component	Pricing
Transit Gateway	Per GB of data processed
Attachments	No charge to create, only for usage
Peering	Per GB (cross-region is more expensive)

⚠️ Ingress and egress traffic through TGW is charged.

🔚 TL;DR Summary¶

Feature	Value
What is it?	Central router for VPCs, VPNs, DX
Replaces?	Complex VPC peering meshes
Supports?	Transitive routing, multi-region peering
Max VPCs?	5000+ per TGW (practically scalable)
Uses route tables?	✅ Yes — per attachment routing policies
Can isolate networks?	✅ Yes — by route table separation