End-to-End AWS Networking: VPC Peering, NAT Gateway, Elastic IP & Routing Simplified!


Note: Before you jump in, give this theoretical blog a quick read to these two blogs [blog1] & [blog2], it'll help you understand all the concepts better!
I hope you have read the previous two blogs, as they will make it easier for you to understand what we’re learning here. However, if you are already experienced, you can proceed to read this blog directly.
What is VPC Peering?
If you want to send a ping from VPC2 to VPC1, you might wonder how this is possible since they are on different networks. This can be achieved through VPC Peering.
VPC Peering is a crucial topic in the industry because it allows multiple clients and applications to communicate. When one application needs to ping or send a request to another application in a different VPC, VPC Peering enables this interaction.
Let’s understand this with one example:
You have two houses one for your frontend (say, House A) and one for your backend (House B). Now you want to visit House B from House A to get something (like data).
But there’s no road between the two houses.
So, what do you do?
You build a private road directly connecting House A and House B.
That private road is VPC Peering.
It allows two VPCs (Virtual Private Clouds) to talk to each other privately and securely, just like you're walking from House A to House B without touching public roads.
So VPC Peering is used for a direct one-to-one connection.
Let's perform a practical exercise:
- Create an additional VPC:
Assign the name tag "prod-vpc" to the VPC.
Allocate a large IP address range to allow the creation of both public and private subnets, as well as numerous smaller subnets.
- Now, we will proceed to create subnets.
When we assign the IP address range 192.0.0.0/16, it allocates 65,536 IP addresses to this subnet.
Now we will create private subnet with name prod-private-subnet-1.
Here we have give 192.0.128.0/17 because it is not overlapping to 192.0.0.0/16
If we modify the fourth octet, our first usable IP address will remain unchanged, and AWS will not permit its use.
- To address this, we used 192.0.128.0/17. Its first usable IP is distinct.
- Now we have private and public subnet, now create Route table and Internet Gateway.
- It is in detached state. So attached it with PROD VPC
- Now, proceed to create a Route Table as demonstrated below.
- Now add the public subnet to the route table's subnet associations.
- Now, we will add the production Internet Gateway.
- You can examine the map of the Prod VPC, where you will see that the public subnet has Internet access, while the private subnet does not.
NAT Gateway
- To enable communication from the public subnet to the private subnet, we will create a NAT Gateway.
You need to provide a name, select a subnet, and assign an Elastic IP allocation.
According to the diagram, if you're using a NAT Gateway, you must also assign an Elastic IP address.
What is Elastic IP Address?
Think of an Elastic IP like your personal phone number.
Even if you change your phone (EC2 instance), you can keep the same number (Elastic IP) so people can still reach you.
In AWS, an Elastic IP is a fixed public IP address that doesn’t change, and you can attach it to any instance or NAT Gateway. If something breaks or you replace your instance, you just move the IP to the new one. No need to update DNS or inform users.
Quick Tip:
It’s free if you’re using it.
But it’s chargeable if it’s sitting unused.
Now, let's create another instance because we have two VPCs, each with different devices running in them.
Create an EC2 instance using the details provided below. Ensure that you select the production VPC and the appropriate subnet for the instance.
- Now connect both of the instances with EC2 instance connect:
Take the private IP of the production instance and attempt to ping it from the test instance. You will notice that data is sent but not received, as these instances are in separate networks that are isolated from each other.
To enable communication between these two VPCs, we will establish VPC peering.
Go to VPC and click on Peering Connections:
I wanted my test VPC, within the same account and region, to peer with the production VPC as illustrated below:
Click on "Create."
Similar to sending a friend request on social media, where you can't message a private account until they accept your request, this peering connection remains in "Pending Acceptance." You can choose to accept or reject this connection using the Action menu.
But if you try to ping again, it will still not work.
WHY?
Because Security group is additional layer of security.
Go to Test instance and then click on security and edit inbound secuirty group.
Essentially, all my devices can ping me or my peer, which is 192, so those devices can also ping me.
Now the same thing we will do it in production.
Even after these steps, if you try to ping, it still won't work. To resolve this, we need to update the route tables, as communication relies on them.
First, we will add a route in the Test VPC to the Production VPC.
This is a peering connection between the test and production environments.
Now similarly, we will add a route in the Production VPC to the Test VPC.
- Now you can attempt to ping or send data, and you will see that communication between the two devices is now possible.
This is how VPC peering is used to connect two VPCs.
What if you have 5 VPCs? I will address this topic in an upcoming blog. Stay tuned...
Happy & Fun Learning
Subscribe to my newsletter
Read articles from Chetan Mohanrao Mohod directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by

Chetan Mohanrao Mohod
Chetan Mohanrao Mohod
DevOps Engineer focused on automating workflows, optimizing infrastructure, and building scalable efficient solutions.