DEV Community

Cover image for Deploying an AWS Multi-Region Hub-Spoke Architecture with Terraform
Gergo Vadasz
Gergo Vadasz

Posted on • Originally published at gergovadasz.hu

Deploying an AWS Multi-Region Hub-Spoke Architecture with Terraform

#aws #cloud #terraform #networking

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

AWS Hub-Spoke Transit Gateway 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:

  1. SSH into EU Spoke public server via its public IP
  2. From EU server, SSH into US private server (verifies spoke-to-spoke communication)
  3. From US server, test internet connectivity: 
ping google.com
curl ifconfig.me
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)