AWS with Terraform (Day 15)

AWS VPC Peering Using Terraform

Today I completed Day 15 of the #30DaysOfAWSTerraform challenge, and this was one of the most meaningful and practical lessons so far:

Building a fully functional AWS VPC Peering setup between two regions using Terraform, protected with routing, security rules, and private connectivity across networks.

As DevOps engineers, we often need multiple VPCs for environment isolation such as dev, staging, and prod, or multi-region deployments for latency reduction and high availability. VPC Peering helps us enable private communication without exposing traffic to the public internet.

What is VPC Peering?

VPC Peering allows private, low-latency, encrypted communication between two VPCs using private IP addresses. It’s useful when deploying:

  • Multi-region microservices

  • Shared services like monitoring, logging, authentication

  • Hybrid cloud or cross-VPC database access

It’s important because it improves:

✔ Security

(no internet traversal, no exposure)

✔ Performance

(low latency internal routing)

✔ Cost

(no NAT Gateway or Transit Gateway required for small scale)

Key Rules to Remember

RuleDescription
CIDR must not overlap    Peering fails if IP ranges clash
Peering is non-transitive    A ←→ B and B ←→ C doesn’t mean A ←→ C
Requires requester & accepter    Both sides must acknowledge connection
Must be routed manually    Add routes in each VPC’s route table
Security groups must allow traffic    Otherwise private communication breaks

What I Built Today

Architecture

  • VPC A → us-east-1 (CIDR 10.0.0.0/16)

  • VPC B → us-west-2 (CIDR 10.1.0.0/16)

  • Public subnet in each VPC (for demo)

  • EC2 instance in each running Nginx using cloud-init

  • Bi-directional VPC peering

  • Private route setup

  • Security groups for SSH, ICMP, HTTP

  • Multi-region provisioning via aliased providers

The result:

I can SSH & curl the private IP of one EC2 from the other across peered VPCs — fully private & secure.

Key Terraform Patterns Learned

ConceptPurpose
Provider Aliasing    Manage multi-region provisioning cleanly
Modules & Variables    Make code reusable and DRY
User-data    Bootstrap EC2 with web server automatically
Route tables per VPC    Enable private connectivity
VPC peering requester + acceptor    Activate peering end-to-end

Troubleshooting Lessons

IssueFix
Security group denies ICMP/HTTP    Permit CIDR range of peer VPC
Peering stuck in pending-acceptance    Create accepter block or enable auto_accept
No connectivity even after peering    Route tables missing CIDR entry
Key pair error    Local filename ≠ AWS key-name
Both instances unreachable    Wrong subnet association of route table

Hands-On Assignments (Highly recommended)

  • Replace IGW routes with private peering routes

  • Add a third VPC and test non-transitive routing

  • Lock SSH to your public IP (zero trust approach)

  • Refactor code into reusable modules

Diagram


Final Thoughts

This project clearly shows why DevOps engineers love Terraform:
Declarative, repeatable, multi-region infrastructure — no UI clicking, no manual configuration, no drift.

VPC Peering is a cornerstone of real distributed system networking.
Today’s work strengthened foundational cloud networking concepts and reinforced the discipline of writing structured, modular Terraform.

Day 15 completed successfully — and yes, everything is completely private and secure now.

Here is my repo link: https://github.com/Mo-Adnan-Mo-Ayyub/Aws-with-Terraform

Here is today's session link: 



Hashtags

#aws #terraform #devops #cloudcomputing #vpcpeering #30DaysOfAWSTerraform #awscommunity #infrastructureascode #multiRegion #cloudnetworking #learninginpublic #devopsengineer #hashicorp #awsdevops #cloudarchitect

Comments

Post a Comment

Popular posts from this blog

AWS with Terraform (Day 01)

Image
  Terraform Fundamentals – Day 01 (My Learning Notes as a DevOps Engineer) Today I wrapped up Day-01 of my Terraform with AWS series, and even with my DevOps background, this session helped me tighten my fundamentals and rethink how I approach cloud provisioning. Terraform is something I’ve used before, but today was more about understanding why IaC matters at scale and why Terraform continues to dominate in real-world DevOps ecosystems. Understanding Infrastructure as Code (IaC) As a DevOps engineer, IaC is not new to me. But today’s session broke it down in a way that clarified its real value. IaC = Infrastructure represented as code. Instead of building resources manually through AWS/Azure/GCP consoles, we define everything in .tf files. This ensures our setup is predictable, repeatable, and version-controlled. What I liked most is how clearly the contrast was shown: Cloud-Agnostic Tools (Terraform / Pulumi) Work across AWS, Azure, GCP, Kubernetes, GitHub, etc. ...
Read more

AWS with Terraform (Day 02)

Image
  AWS with Terraform – Day 02 Deep Dive into Providers, Versioning & the Real “Bridge” Between Code and Cloud Today’s session took me from simply writing Terraform code to actually understanding the engine behind it — the Provider layer . And honestly, once this clicks, Terraform stops feeling like just a tool and starts feeling like a real engineering system. Here’s what I learned and how I’ve started applying it. Providers: The Plugin That Makes Terraform Real The simplest way I now understand it: Terraform writes the story. Providers translate it into cloud actions. Before today, I treated the provider block as just two lines of mandatory code. Now I see it as the translator that turns HCL into actual AWS API calls . Example: I write: resource "aws_s3_bucket" "demo" { bucket = "my-app-demo" } The AWS provider turns that into the exact S3 API request. This layer saves us from manually hitting APIs, building payloads, or juggling ...
Read more

AWS with Terraform (Day 06)

Image
Mastering Terraform File Structure: Best Practices for Scalable AWS Infrastructure as Code You've built your first AWS resources with Terraform in one big main.tf file. It works fine at first. But as your project grows, that single file turns into a mess. Resources pile up. Variables hide in plain sight. Debugging takes forever. Good news. You can fix this now. Split your Terraform files the right way. Follow HashiCorp's tips for a clean setup. This boosts readability. It helps teams work together. Plus, it scales for big AWS setups like VPCs, EC2s, and S3 buckets. Stick with me. You'll see hands-on steps to organize your root module today. The Anatomy of a Well-Organized Terraform Root Module The root directory acts as your Terraform project's heart. It's the root module. Here, you keep all key files. No strict rules exist for names. But smart choices make life easier. Start simple. Break one fat main.tf into focused files. This stops resource clutter. You n...
Read more