I recently tested a multi-region hub-and-spoke architecture in AWS using Transit Gateways. While this architecture may not suit all production scenarios, it effectively demonstrates Transit Gateway functionality and scalable multi-region networking principles.
High-Level Architecture
Components:
- 1 Hub VPC in eu-west-1
- 1 Spoke VPC in eu-central-1
- 1 Spoke VPC in us-east-1
Key features:
- Dedicated Transit Gateways per region facilitate inter-region routing
- Spoke TGWs connect to Hub TGW, enabling spoke-to-spoke traffic through the hub
- Hub VPC provides internet outbound access via NAT gateways
- Deployment includes test Ubuntu servers: one in EU spoke public subnet, one in US spoke private subnet
Setup Walkthrough
1. Deploying VPCs and Subnets
Three VPCs deployed across regions with public/private subnets and route tables. These require later modifications for proper cross-region routing.
2. Setting Up Internet Access
Internet Gateways deployed in Hub and EU spoke VPCs to enable SSH access for testing.
3. Deploying Transit Gateways and Attachments
Three Transit Gateways created with two attachment types:
- VPC Attachments: Connect VPCs to regional TGWs
- Peering Attachments: Connect Transit Gateways across regions
Communication flow: VPC 1 → VPC Attachment → Transit GW 1 → Peering Attachment → Transit GW 2 → VPC Attachment → VPC 2
4. Configuring Transit Gateway Route Tables
Spoke TGW Route Tables:
- Default route (
0.0.0.0/0) directs traffic to peering attachment connecting spoke to hub
Hub TGW Route Table:
- EU Spoke VPC CIDR → EU Spoke Peering Attachment
- US Spoke VPC CIDR → US Spoke Peering Attachment
- Default Route (
0.0.0.0/0) → Hub VPC Attachment with NAT Gateways
5. Modify VPC Route Tables
Spoke VPCs: Add default route (0.0.0.0/0) to local Transit Gateway
Hub VPC: Add routes for spoke VPC CIDRs (10.0.0.0/16 and 192.168.0.0/16) to local Hub TGW
6. Deploying NAT Gateways for Internet Access
NAT Gateways deployed in Hub VPC public subnets route spoke VPC internet traffic. Hub private subnet route tables configured with 0.0.0.0/0 pointing to NAT Gateways.
7. Deploying and Testing Servers
Testing procedure:
- SSH into EU Spoke public server via its public IP
- From EU server, SSH into US private server (verifies spoke-to-spoke communication)
- From US server, test internet connectivity:
ping google.com
curl ifconfig.me
The public IP should match the Hub NAT Gateway IP, confirming correct outbound routing through the hub.
Summary
This architecture demonstrates how Transit Gateways enable scalable multi-region networking in AWS. Terraform automates the entire deployment, ensuring consistency and repeatability versus manual configuration.
The complete Terraform code provisions everything — VPCs, Transit Gateways, peering attachments, route tables, NAT Gateways, and test servers across all three regions.
Check out the full code at gergovadasz.hu.
Originally published on gergovadasz.hu. I write hands-on cloud networking guides with production-ready Terraform code for AWS, Azure, and GCP. Subscribe for more.
