TGW basics

 

1. Architecture Objective 

We designed this to isolate application environments (App1, App2) into separate VPCs while centralizing all internet-bound traffic and inter-VPC routing via a Transit Gateway (TGW). It keeps our network modular, scalable, and secure. 

📌 Key Concepts: 

Concept	Meaning
TGW	Central hub that connects multiple VPCs
Attachment	A connection between TGW and a VPC or VPN
TGW Route Table	A table that holds routes (destination → attachment)
Association	Binds an attachment to a specific TGW route table
Propagation	Automatically adds a route to a TGW route table from an attachment

 

2. Why We Use TGW (Over VPC Peering) 

VPC Peering creates point-to-point connections, which work for a few VPCs. But once you scale beyond 5–10, it becomes a full mesh nightmare. TGW lets us plug all VPCs into a single hub and control traffic centrally, making it cleaner and future-proof. 

3. Subnet Routing Design 

We use three TGW Route Tables: 

TGW Route Table	Attached VPC	Propagated Routes
tgw-rt-app1	App1	Egress only
tgw-rt-app2	App2	Egress only
tgw-rt-egress	Egress VPC	App1, App2

• App VPCs route to Egress via TGW 

• Egress VPC handles internet via IGW (public subnets), and routes return traffic to App VPCs (private subnets) 

 

CIDR Setup for Route Tables 

Let’s assume your CIDRs are: 

VPC	CIDR
App1	10.0.0.0/16
App2	10.1.0.0/16
Egress	192.168.0.0/16

 

1. 🔁 App1 VPC - Private Subnet Route Table 

Destination	Target
10.0.0.0/16	local
192.168.0.0/16	Transit Gateway (TGW)

✅ This allows App1 to send traffic to the Egress VPC only (for internet access), and not to App2. 

 

2. 🔁 App2 VPC - Private Subnet Route Table 

Destination	Target
10.1.0.0/16	local
192.168.0.0/16	Transit Gateway (TGW)

✅ This allows App2 to reach the Egress VPC only. 

 

3. 🚪 Egress VPC - Private Subnet Route Table 

Destination	Target
192.168.0.0/16	local
10.0.0.0/16	Transit Gateway (TGW) – App1
10.1.0.0/16	Transit Gateway (TGW) – App2

✅ This allows return traffic from Egress to App1 and App2. 

 

4. 🌍 Egress VPC - Public Subnet Route Table 

Destination	Target
0.0.0.0/0	Internet Gateway (IGW)
192.168.0.0/16	local

✅ This enables actual egress to the internet. 

 

🚫 No App1 ↔ App2 Routing 

You must not add the following CIDRs in either App1 or App2 route tables: 

• 10.1.0.0/16 in App1 

• 10.0.0.0/16 in App2 

This ensures App1 and App2 cannot communicate directly, even through TGW. 

 

4. Security Practices 

• App1 & App2 have no direct internet access 

• TGW route tables ensure App1 ≠ App2 isolation 

• IAM + SCPs segment account-level control 

• Security groups/NACLs restrict east-west traffic further 

5. Preventing Inter-App Communication 

App1 and App2 use separate TGW route tables and are not propagated to each other. This means even though they’re on the same TGW, they cannot talk unless explicitly allowed, ensuring tenant/workload isolation. 

6. Disaster Recovery (DR) Plan 

• Each VPC spans multiple AZs for redundancy 

• TGW cross-region peering will connect to a mirrored setup in the DR region 

• We use Terraform/CDK to automate and replicate infra if needed 

7. Operational Considerations 

• Route table planning is crucial — one wrong propagation and traffic can break 

• Debugging TGW is not as straightforward as peering — use AWS Reachability Analyzer and tagging 

• TGW charges for both data and attachments — cost visibility is key 

• Scale adds complexity — document all routes and associations 

8. Cost Optimization 

• Only allow inter-VPC traffic when needed (e.g., no chatty logs over TGW) 

• Remove idle TGW attachments in lower environments 

• Avoid TGW inter-region peering unless truly necessary (adds hourly + GB charges) 

• Monitor TGW bytes in/out with CloudWatch + Cost Explorer 

9. Enhancement Opportunities 

• Add NAT to Egress for App VPCs to pull updates 

• Introduce WAF + NLB in public subnet  to secure inbound traffic 

• Use VPC PrivateLink for finer-grained service access between apps 

• Enable VPC Flow Logs & TGW CloudWatch metrics for observability 

10. Scaling to More VPCs 

• Use for_each in Terraform to create scalable VPCs, attachments, and routes 

• Tag-based logic can automate route propagation 

• Watch AWS TGW limits: 

• Max 5000 attachments 

• Max 10,000 routes/table 

• Max 20 route tables 

11. Risks & Mitigations 

Weakness	Suggested Solution
No Internet in App VPCs	Route via NAT in Egress VPC (via TGW)
No east-west firewall	Add 3rd-party firewall via TGW attachment
Misrouting risk	Use separate TGW route tables per environment
Single-region only	Enable cross-region TGW peering
No visibility	Add logs, metrics, alarms for TGW & VPCs

 

What Is a Blackhole Route in AWS Transit Gateway (TGW)? 

A blackhole route in AWS Transit Gateway is a route in a TGW route table that matches a destination CIDR but has no target (attachment)—and instead, intentionally drops traffic that matches it. 

Think of it as a traffic sink: the traffic reaches the TGW, finds the CIDR in the route table, but is dropped immediately. 

 

🎯 Goal: 

• App1 and App2 should not talk to each other (isolation) 

• Both App1 and App2 can reach the internet via the Egress VPC 

• Use TGW route tables to achieve this, and blackhole routes to block unwanted communication. 

 

✅ Setup: 3 TGW Route Tables 

TGW Route Table	Associated Attachment	Propagated Attachments	Routes
tgw-rt-app1	App1 VPC	Egress VPC
			192.168.0.0/16 → Egress Attachment
			10.1.0.0/16 → blackhole
tgw-rt-app2	App2 VPC	Egress VPC
			192.168.0.0/16 → Egress Attachment
			10.0.0.0/16 → blackhole
tgw-rt-egress	Egress VPC	App1, App2
			10.0.0.0/16 → App1 Attachment
			10.1.0.0/16 → App2 Attachment

 

🔁 Traffic Flow 

• App1 → Internet ✅ via 192.168.0.0/16 → Egress VPC 

• App2 → Internet ✅ via 192.168.0.0/16 → Egress VPC 

• App1 ❌ cannot reach App2 (10.1.0.0/16 is blackholed) 

• App2 ❌ cannot reach App1 (10.0.0.0/16 is blackholed)