Designing and provisioning multi-region AWS network infrastructure with Terraform — connecting Mumbai and Hyderabad VPCs via Transit Gateway, with private SSM access and a modular IaC pattern built to scale.
RoleCloud Infrastructure Architect
PlatformAWS ap-south-1 & ap-south-2
DomainNetwork Infrastructure / IaC
TypeTerraform Infrastructure Module
The Problem
Two regional workloads that needed to talk — privately, without a public internet hop
Production workloads in Mumbai (ap-south-1) needed private communication with the DR tier in Hyderabad (ap-south-2). EC2 instances in private subnets also needed SSM Session Manager access without public IPs or a bastion host.
Constraint: 100% Terraform-managed. Adding a third region must require only a new module call — no changes to existing code.
Architecture
Hub-and-spoke Transit Gateway topology
1
VPC Module — reusable per regionProvisions complete VPC: CIDR block, public/private subnets across 2 AZs, IGW, NAT Gateway per AZ, route tables. Called once per region with different CIDRs to avoid overlap.
2
Transit Gateway per regionOne TGW in Mumbai, one in Hyderabad. VPC attachments connect regional VPCs to their local TGW. Route propagation enabled so VPC routes are automatically shared.
3
Inter-region TGW Peeringaws_ec2_transit_gateway_peering_attachment connects Mumbai to Hyderabad TGW. Acceptance handled via cross-region provider alias (provider = aws.hyderabad).
4
VPC Endpoints for SSM on private subnetsThree Interface endpoints per VPC: ssm, ssmmessages, ec2messages. EC2 instances in private subnets accessible via SSM without public IP or bastion.
5
Least-privilege Security GroupsApplication SGs allow traffic only from TGW attachment CIDRs. SSM endpoint SG allows HTTPS inbound from VPC CIDR only.
Key Challenges
Cross-region Terraform is non-trivial
🌍
Cross-region provider aliasingTGW peering acceptance lives in ap-south-2 but is triggered from ap-south-1. Required careful use of provider = aws.ap_south_2 and explicit depends_on to sequence creation correctly.
🛣️
Route propagation not covering all subnetsOnly the main route table received propagated routes. Private subnets used a custom route table excluded from propagation. Fixed by explicitly associating the custom table with TGW propagation.
⏳
TGW peering async acceptance delayInter-region TGW peering has an async acceptance step. Added explicit timeouts and a terraform refresh step in CI to handle the propagation delay.