AWS Day 29: Establishing Secure Communication Between Public and Private VPCs via VPC Peering

Introduction

During Day 29 of the KodeKloud 100 Days of Cloud Challenge, I explored AWS VPC Peering, a networking feature that enables secure communication between two Virtual Private Clouds (VPCs).

In many AWS environments, applications are distributed across multiple VPCs to improve security and isolate workloads. However, there are situations where resources in different VPCs need to communicate privately without sending traffic over the public internet. AWS solves this using VPC Peering, which creates a private network connection between two VPCs.

In this lab, I configured a VPC Peering connection between the default public VPC and an existing private VPC, updated the route tables, configured security groups, and verified connectivity between two EC2 instances.

What is AWS VPC Peering?

AWS VPC Peering allows two VPCs to communicate using private IPv4 or IPv6 addresses.

Unlike Internet Gateways or NAT Gateways, VPC Peering keeps traffic entirely within the AWS network, providing secure and low-latency communication between resources.

Some common use cases include:

• Connecting public and private VPCs

• Sharing services across multiple VPCs

• Multi-tier application architectures

• Cross-team or cross-environment communication

• Secure backend connectivity

Task Requirements

The following tasks needed to be completed:

• Create a VPC Peering Connection named nautilus-vpc-peering

• Connect the Default Public VPC and nautilus-private-vpc

• Update the Route Tables in both VPCs

• Configure Security Groups to allow communication

• SSH into the public EC2 instance

• Verify connectivity by pinging the private EC2 instance

Step 1: Review the Existing Infrastructure

Before creating the peering connection, I verified the existing resources.

The lab already contained:

Resource	Name
Public EC2	nautilus-public-ec2
Private VPC	nautilus-private-vpc
Private Subnet	nautilus-private-subnet
Private EC2	nautilus-private-ec2

This saved time since only the networking configuration needed to be completed.

Step 2: Create the VPC Peering Connection

I opened the VPC Dashboard and navigated to:

VPC → Peering Connections

Then I created a new peering connection with the following configuration:

Setting	Value
Name	nautilus-vpc-peering
Requester VPC	Default VPC
Accepter VPC	nautilus-private-vpc

After creating the request, I accepted the peering connection.

Once accepted, the status changed to:

Active

Step 3: Update the Route Tables

Creating a peering connection alone doesn't allow communication between VPCs.

I updated the route tables in both VPCs by adding routes for each other's CIDR blocks.

Public VPC Route Table

Destination	Target
10.1.0.0/16	nautilus-vpc-peering

Private VPC Route Table

Destination	Target
Default VPC CIDR	nautilus-vpc-peering

These routes ensure that traffic between the two VPCs is forwarded through the VPC Peering connection.

Step 4: Configure the Security Groups

To allow communication between the EC2 instances, I updated the Security Group attached to the private EC2 instance.

The following inbound rules were added:

Protocol	Port	Source
ICMP	All	Default VPC CIDR
SSH (if required)	22	Default VPC CIDR

Step 5: Configure SSH Access

The lab required SSH access from the AWS client host to the public EC2 instance.

I copied the public key located at:

/root/.ssh/id_rsa.pub

and added it to the following file on the public EC2 instance:

~/.ssh/authorized_keys

This enabled passwordless SSH access from the AWS client host.

Step 6: Verify Connectivity

Finally, I connected to the public EC2 instance using SSH.

ssh ec2-user@<Public-IP>

From the public EC2 instance, I pinged the private EC2 instance using its private IP address.

ping <Private-EC2-IP>

The ping responses confirmed that communication between the two VPCs was working successfully through the VPC Peering connection

What I Learned

This lab helped me understand that creating a VPC Peering connection is only one part of the setup.

For communication to work successfully, route tables must be updated in both VPCs, and the Security Groups must explicitly allow the required traffic. Missing any one of these configurations can prevent connectivity, even if the peering connection is active.

I also learned how VPC Peering enables secure communication between isolated networks without exposing resources to the public internet.

Conclusion

Day 29 provided hands-on experience with AWS networking by configuring a VPC Peering connection between a public and a private VPC.

By updating route tables, configuring Security Groups, and verifying connectivity between two EC2 instances, I gained a better understanding of how AWS enables secure communication across multiple VPCs. This is a common networking pattern used in production environments where applications are distributed across isolated VPCs while still requiring private communication.