Connecting Networks Across Regions with Infrastructure as Code 🚀
As part of my 30 Days of AWS Terraform challenge, Day 15 marked a major milestone: reaching the halfway point and stepping into one of the most practical areas of cloud engineering — AWS networking with VPC Peering.
Until now, much of my Terraform journey focused on provisioning resources and learning Terraform concepts. But today’s project shifted from deploying isolated services to solving a real-world networking challenge: securely connecting two private AWS VPCs across different regions using Terraform.
This project was a strong reminder that Infrastructure as Code is not just about automation — it’s about understanding architecture, networking principles, and system design.
Why VPC Peering Matters
In real-world cloud environments, applications and services often live in different VPCs:
- Separate environments (Dev / Staging / Prod)
- Multi-account setups
- Regional redundancy architectures
- Shared services and private APIs
To allow these isolated networks to communicate securely over private IP addresses, AWS provides VPC Peering.
What VPC Peering Does
VPC Peering creates a private connection between two VPCs, enabling resources in each network to talk to each other as if they were on the same local network.
Benefits include:
✅ Private communication (no internet exposure)
✅ Low latency
✅ Better security
✅ Simplified architecture
Project Overview 🏗️
For this mini-project, I provisioned:
- VPC 1 in US East (N. Virginia)
- VPC 2 in US West (Oregon)
- EC2 instances in both VPCs
- VPC Peering connection between them
- Route table updates for bidirectional traffic
The goal was simple:
👉 Allow private communication between instances in both regions.
And yes — successfully testing cross-region private connectivity felt amazing. 🎯
Key Learnings from Day 15
1. Multi-Region Terraform with Provider Aliases 🌍
One of the biggest learnings today was managing resources across multiple AWS regions in a single Terraform project.
Using provider aliases, I configured:
-
aws.primary→ US East 1 -
aws.secondary→ US West 2
This made it possible to:
- Deploy resources cleanly in separate regions
- Keep code structured and maintainable
- Avoid duplicated configurations
Why This Matters
In enterprise cloud environments, multi-region deployments are common for:
- Disaster recovery
- High availability
- Geo-distributed applications
Understanding provider aliases is essential for scalable Terraform projects.
2. CIDR Planning is Critical 🧠
One of the first rules of VPC Peering:
❌ CIDR ranges must NOT overlap
If both VPCs share the same IP range:
- Route tables conflict
- Traffic breaks
- Connectivity fails
This reinforced an important lesson:
👉 Good networking starts with good IP planning.
Even with Terraform, automation cannot fix poor architecture.
3. VPC Peering is NOT Transitive ⚠️
A major cloud networking concept I learned:
If:
- VPC A ↔ VPC B
- VPC B ↔ VPC C
That does NOT mean:
- VPC A can talk to VPC C
This is called non-transitive peering.
Why This Matters
For larger enterprise setups:
- VPC Peering can become hard to manage
- Mesh architectures get complex quickly
This is where services like:
- AWS Transit Gateway
- Hub-and-spoke networking
Become important.
Understanding this limitation was one of today’s biggest takeaways.
4. Route Tables Make the Magic Happen 🛣️
Creating the peering connection is only half the setup.
The real work is in routing.
For both VPCs, I had to:
- Update route tables
- Add peer VPC CIDR blocks
- Point traffic to the peering connection ID
Without correct routes:
Terraform may succeed… but traffic will still fail.
This taught me a practical lesson:
👉 Cloud networking is as much about traffic flow as it is about resource creation.
Hands-On Testing & Validation 🔍
The most satisfying part of today’s project was testing connectivity.
After setup, I verified:
- Ping between instances
- Curl requests to private IPs
- Cross-region communication over private network
Seeing an EC2 instance in Oregon reach a web server in Virginia privately was an exciting milestone.
This was one of the clearest demonstrations so far of how powerful Terraform + AWS can be together.
Key Takeaways 💡
Day 15 taught me more than just Terraform syntax.
It reinforced:
✔️ Cloud networking fundamentals matter
✔️ Architecture decisions impact scalability
✔️ Debugging builds confidence
✔️ Terraform is powerful when paired with strong design principles
What’s Next? 🔥
Reaching the halfway point feels great, but there’s still a lot ahead:
- Security hardening
- Modules & reusable architecture
- Advanced state management
- Production deployment workflows
Excited for the second half of this challenge.
Final Thoughts
Day 15 was one of the most practical and rewarding days of my Terraform journey so far.
If you’re learning Terraform, don’t stop at basic resource creation. Start exploring networking, debugging routes, and understanding how systems communicate.
That’s where real cloud engineering begins.
Top comments (0)