Day 15 - Cross Region VPC Peering with Terraform

There’s something powerful about watching two completely separate networks start talking to each other… quietly, privately, without the internet even noticing.

Today’s build was exactly that.

I created two VPCs in different AWS regions and connected them using VPC peering, allowing EC2 instances to communicate using private IP addresses.

Architecture

Here is the architecture I implemented:


Simple Flow

User → SSH → EC2 (Primary VPC) → Private Network → EC2 (Secondary VPC)

What I Built

I created:

  • Two VPCs in different regions
  • One public subnet in each VPC
  • Internet gateways for both VPCs
  • Route tables with peering routes
  • VPC peering connection (cross region)
  • Two EC2 instances with Apache installed
  • Security groups allowing SSH, ICMP, and TCP

Step 1: Initialize Terraform

I started by initializing Terraform.

terraform init
  • Terminal showing Terraform has been successfully initialized

Step 2: Review Execution Plan

terraform plan

This step shows everything Terraform is going to create.

  • Plan output showing VPCs, EC2, peering, routes

Step 3: Deploy Infrastructure

terraform apply

After confirming, Terraform created everything across both regions.

  • Final line: Apply complete! Resources: X added

Step 4: Verify VPCs in AWS Console

  • Primary VPC (us-east-1)

  • Secondary VPC (us-west-2)

Step 5: Verify VPC Peering

  • Peering connection with Status = Active

This is the bridge between both worlds.

Step 6: Verify Route Tables

This is where things usually break if missed.

Each VPC must know how to reach the other.

Primary route table:

  • Destination: 10.1.0.0/16
  • Target: Peering connection

Secondary route table:

  • Destination: 10.0.0.0/16
  • Target: Peering connection


Step 7: Verify EC2 Instances


Step 8: Test Connectivity (The Real Moment)

SSH into the Secondary instance and do a Ping and HTTP test to Primary Instance

SSH into the Primary instance and do a Ping and HTTP test to Secondary Instance


Challenges I Faced
  • Understanding that peering alone is not enough
  • Remembering to update route tables on both sides
  • Managing resources across two regions using provider aliases
  • Handling SSH keys separately per region
Security Note
Instead of opening SSH to the world:
0.0.0.0/0
I restricted access to my IP:
108.227.216.109/32
Small step. Big difference.
Cost Awareness
Even small setups whisper bills in the background.
This project includes:
  • EC2 instances
  • Cross region data transfer
  • VPC resources
So I cleaned up after testing:
terraform destroy
  • Destroy complete message
Key Learnings
  • VPC peering enables private communication across regions
  • CIDR blocks must not overlap
  • Route tables control the actual traffic flow
  • Security groups must allow cross VPC communication
  • Terraform provider aliases enable multi region deployments
Final Thought
Today wasn’t just about connecting two VPCs.
It was about understanding how networks think.
Not everything that is connected, can communicate.
Not everything that communicates, is visible.
And somewhere between routes, rules, and packets , clarity begins.
Video Reference



Jay
















































Comments











Post a Comment



















Popular posts from this blog









ASM Integrity check failed with PRCT-1225 and PRCT-1011 errors while creating database using DBCA on Exadata 3 node RAC




















Image







  Error: The error message PRCT-1225: failed to verify Oracle Automatic Storage Management (Oracle ASM) user credentials using the command 'asmcmd credverify'  indicates that the asmcmd credverify  command failed to verify the Oracle ASM user credentials.  This can happen for a number of reasons,  including: The user credentials are incorrect. The user credentials file is corrupted. The user does not have the necessary permissions to run the asmcmd credverify  command. There is a problem with the Oracle ASM instance. To troubleshoot this error,  you can try the following: Make sure that the user credentials are correct.  You can do this by trying to log in to the Oracle ASM instance using the same credentials. Check the user credentials file for errors.  You can do this by using a text editor to open the file and inspect the contents. Make sure that the user has the necessary permissions to run the asmcmd credverify  command.  You can do this by checking the user's permissi...








Read more










Life is beautiful




















Image







Life brings unexpected tragedies that are beyond our control. It's heartbreaking to witness people facing circumstances they never chose. We react with tears and inevitably wonder, "What if that happens to me?" As humans, we naturally focus on the positive and avoid dwelling on such thoughts—and that's healthy. But this perspective has shaped how I approach life: Am I prepared for these scenarios? Are my loved ones protected if something goes wrong? If I were to die, I couldn't be there to tell them to stay strong—they'd have to face that grief alone. But I can give them financial security through proper planning, wills, and trusts. These are tangible ways to care for them even when I'm gone.  Beyond that, what else can I control? I don't waste energy worrying about an uncertain past or future. Instead, I choose to spread peace, truly listen to others, and share genuine smiles. I embrace the principle of living fully while letting others do the same.  ...








Read more










Lock Tables in MariaDB





















Whether or not you need to lock tables while backing up MariaDB depends on a few factors, including the type of backup you are performing and the tools you are using. If you are performing a full backup , you should lock the tables to ensure that the backup is consistent. This is because a full backup copies all of the data in the database, including any data that is currently being modified by transactions. If you do not lock the tables, it is possible that the backup could contain inconsistent data. If you are performing a differential backup  or an incremental backup , you may not need to lock the tables. Differential and incremental backups only copy the data that has changed since the previous backup. This means that the data is already consistent, so there is no need to lock the tables. However, some backup tools may require you to lock the tables, even if you are performing a differential or incremental backup. This is because these tools may need to modify the database in some ...








Read more