DEV Community: Rajesh

How to Configure Inter-Region VPC Peering

Rajesh — Fri, 14 Aug 2026 18:26:15 +0000

If you have servers running in different AWS Regions, you may need to allow the workloads on those servers to communicate privately.

For example, an application running in Hyderabad might need to communicate with a database running in Sydney using private IPs.

In this how-to, I'll show you how I peered two VPCs in different AWS Regions and connected them using VPC Peering.

Architecture

Assume for this lab that the following architecture is required to be configured:

Region A

Hyderabad

vpc-a-peering-connection (CIDR: 10.0.0.0/16)

subnet: 10.0.1.0/24

Region B

Sydney

vpc-b-peering-connection (CIDR: 10.1.0.0/16)

subnet: 10.1.1.0/24

Make sure that the CIDR ranges do not overlap on the VPCs as you can't peer VPCs with overlapping CIDRs

1. Creating the VPCs and instances

I first proceeded to create the VPCs and launched instances in them

Navigating to Hyderabad region, I created a vpc-a-peering-connection VPC, public subnet, internet gateway, and a route table. Then I launched a simple Ubuntu EC2 instance in the region

Our region A VPC is created:

The public subnet that I created in Hyderabad region:

The Internet Gateway attached to my Hyderabad VPC:

I then switched to Sydney region and created similar resources in that region as well

The Sydney VPC is created:

The subnet in Sydney region:

The Internet Gateway attached to my Sydney VPC:

For this lab, I launched my EC2 instances in public subnets so that they can be easily accessed for testing. The VPC peering connection does not require the subnet to be public or VPC to have an Internet Gateway

At this point, a ping from the Hyderabad instance to the Sydney instance will fail because there is no route between the two VPCs yet.

2. Creating the peering connection

Now, I proceeded to create the peering connection

I navigated to VPC Dashboard in Hyderabad region, clicked Peering connections, and created a new one

I gave it a name VPC-A to VPC-B, chose my vpc-a-peering-connection as the Requester, and another region as Accepter and Sydney as the region

I chose the vpc-b-peering-connection as the accepter VPC and clicked create

The peering connection request was sent and is awaiting approval:

3. Accepting the connection

Switching to Sydney region, I navigated to Peering connections and accepted the request:

You can now see that the peering connection is active. The next thing to do is to update the route tables

4. Updating the route tables

I navigated to Route Tables and selected the route table associated with the subnet where I launched my EC2 Instance

I added a route to the Sydney VPC:

Destination: 10.1.0.0/16

Target: Peering Connection (selected the PCX created earlier)

I did the same thing in the Sydney region to route traffic back to Hyderabad:

Destination: 10.0.0.0/16

Target: Peering Connection

This route table in Hyderabad now has a route to the Sydney VPC via the peering connection:

The Sydney route table now has a route back to the Hyderabad VPC

5. Updating the security groups

The route tables are now updated, but we also need to allow ICMP traffic in the security groups for the ping test to work.

In the security group of my EC2 instance in Hyderabad region, I updated the Inbound rules to explicitly allow All ICMP - IPv4 from the source 10.1.0.0/16:

(Note: In the above image, there is a TCP rule from another lab. For ICMP traffic, we need the All ICMP - IPv4 inbound traffic rule)

Similarly, in the security group in Sydney, I updated the Inbound rules to allow All ICMP - IPv4 from the source 10.0.0.0/16:

I explicitly allowed the inbound ICMP rules in Sydney. If you have the default outbound rule (All traffic - 0.0.0.0/0) as Allow, there is no need to add an outbound rule for this ping test

6. Testing the connection

I then SSH'd back into my instance in Hyderabad region and did a ping to the private IP address of the instance in Sydney region. It worked after updating the security group:

Now, the two instances can communicate with each other over the AWS network via private IPs

Things to note

You can't establish a VPC Peering connection between VPCs with overlapping IPv4 or IPv6 CIDR blocks
VPC Peering is not transitive. If VPC A is peered with VPC B, and VPC B is peered with VPC C, VPC A cannot communicate with VPC C through VPC B. You need a separate peering connection between A and C. If you have many VPCs, AWS Transit Gateway can provide a centralized way to connect them.

Now you know how to configure inter-Region VPC peering. The peering connection provides the path between the VPCs, but you still need the correct route table entries and security group rules on both sides.

EC2 in Real Life: A Simple Blog Note for Beginners

Rajesh — Sun, 28 Jun 2026 17:00:33 +0000

I wrote this like I would explain to a junior in a lab session. No heavy words, no theory overload. Just what matters when you actually create and use an EC2 machine.

Small intro

When we say "EC2," think of one thing: a computer on rent. You do not buy hardware. You open AWS, pick a machine size, and start using it.

That is why most people start cloud learning with EC2.

1) What is EC2?

EC2 stands for Elastic Compute Cloud.

Simple meaning:

It is a virtual server in AWS.
You can install software in it like your own laptop.
You can run website, backend API, database, scripts, anything.

Why "Elastic"?
Because you can scale up or down based on traffic.

If today only 10 users come, small server is enough.
If tomorrow 10,000 users come, you can move to bigger machine or add more machines.

2) EC2 pricing model (the part everyone asks first)

AWS gives multiple payment options. Choose based on your situation.

On-Demand

Use and pay. No long commitment.
Best for:

Learning
Demo
Testing new features

Reserved Instances

You commit for long term (usually 1 or 3 years).
Cost is lower than on-demand.
Best for:

Stable production apps
Predictable workloads

Spot Instances

Very cheap (sometimes huge discount), but AWS can reclaim it.
Best for:

Batch jobs
Video processing
Non-critical tasks Not best for always-on production.

Savings Plans

You commit to a certain usage/spend level over time.
Good discount and some flexibility.

Quick student rule:

New to AWS -> start On-Demand.
Predictable long-term app -> compare Reserved/Savings.
Cost-first experiments -> try Spot.

3) Instance families (machine categories)

All EC2 machines are not same. AWS groups them by purpose.

General purpose

Balanced CPU + RAM.
Example family: T series, M series.
Good for normal web apps and learning.

Compute optimized

More CPU power.
Example family: C series.
Good for CPU-heavy tasks like rendering, transforms, game servers.

Memory optimized

More RAM.
Example family: R series.
Good for cache/database memory-heavy apps.

Storage optimized

Fast/high-throughput disk access.
Example family: I series.
Good for data-intensive workloads.

A common beginner pick is t3.micro or t2.micro style instance (based on region/free-tier rules).

4) What is AMI image?

AMI means Amazon Machine Image.

AMI is like a prebuilt template used to launch an EC2 instance.
It contains:

OS (Ubuntu, Amazon Linux, Windows, etc.)
Base config
Sometimes preinstalled tools

Two common types:

Public AMI: provided by AWS or marketplace/community
Private AMI: custom image prepared by your org/team

Easy memory trick: AMI is the "starter pack" for your EC2 machine.

5) SSH, public key, private key (important)

When you connect to Linux EC2, usually you use SSH.

You create/use a key pair:

Public key -> placed on server side
Private key (.pem) -> stays only with you

Never share private key. Ever.
If private key leaks, server access risk is high.

Basic command:

ssh -i mykey.pem ubuntu@<EC2_PUBLIC_IP>

Common usernames:

Ubuntu AMI -> ubuntu
Amazon Linux -> ec2-user

If permission issue comes for key file, set strict permission:

chmod 400 mykey.pem

6) Install Nginx and host first static file in /var/www/html

Assume Ubuntu EC2.

Install and start Nginx

sudo apt update
sudo apt install -y nginx
sudo systemctl start nginx
sudo systemctl enable nginx

Put first static page

echo "<h1>My first EC2 static page</h1>" | sudo tee /var/www/html/index.html

Now open:

http://<EC2_PUBLIC_IP>

If port 80 is open in Security Group, page will load.

7) Flask Hello World host on port 8080 + Security Group

Install Python + Flask

sudo apt update
sudo apt install -y python3 python3-pip
pip3 install flask

Create app.py

from flask import Flask

app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello World from Flask running on EC2"

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8080)

Run it

python3 app.py

Security Group for port 8080

In AWS Console:

EC2 -> Instances -> select your instance
Security -> click Security Group
Inbound rules -> Edit inbound rules
Add rule:
- Type: Custom TCP
- Port: 8080
- Source: 0.0.0.0/0 (only for demo/testing)

Now test in browser:

http://<EC2_PUBLIC_IP>:8080

You should see your hello message.

Production note:
Do not keep wide-open rules forever. Restrict CIDR, use reverse proxy, and enable HTTPS.

One-page final summary

EC2 is a cloud server you can rent in minutes.
You choose pricing model based on your budget and stability needs.
Instance families help you pick the right machine for CPU, memory, or storage focus.
AMI is the base image used to launch the instance.
SSH key pair is how you securely log in.
Nginx helps you host static pages from /var/www/html.
Flask can run on port 8080, and you must allow that port in Security Group.

If you can do these steps once by yourself, you already have strong EC2 fundamentals.