Introducing Today's Project!
What is Amazon VPC?
Amazon VPC lets you build a private cloud in AWS. It's useful for secure networking control, custom IP ranges, and scalable infrastructure setups.
How I used Amazon VPC in this project
I used Amazon VPC to set up Maven-1 and Maven-2 VPCs, enabled peering, configured routing, and opened ICMP traffic for secure instance communication and successful ping validation.
One thing I didn't expect in this project
One thing I didn't expect in this project was how critical correct routing and security configurations were for VPC peering. I thought peering alone would enable communication, but I had to fine-tune routes and rules to make it work smoothly.
The project took me around 35 minutes to complete. It involved setting up two VPCs, configuring a peering connection, updating route tables and security groups, and validating connectivity with ping tests.
In the first part of my project
Step 1 - Set up my VPC
I'm creating two VPCs; Maven-1 and Maven-2 with unique CIDR blocks using the AWS VPC Wizard. This sets the stage for peering, ensuring both networks are isolated but ready to connect securely through a private link.
Step 2 - Create a Peering Connection
I'm setting up a private connection between my two VPCs, so they can talk to each other using internal IPs. This lets them share data securely without going through the public internet.
Step 3 - Update Route Tables
I'm updating the route tables for both VPCs to set them up to reach each other. This lets traffic from VPC 1 find VPC 2, and vice versa, using the private peering connection we've just created.
Step 4 - Launch EC2 Instances
I'm now going to launch EC2 instances in each VPC as testing tools for the VPC peering connection. This helps confirm that private communication between the VPCs is working properly
Multi-VPC Architecture
I started my project by launching two VPCs Maven-1 and Maven-2, each with a unique CIDR block (10.1.0.0/16 and 10.2.0.0/16). I created one public subnet in each VPC using the AWS VPC Wizard and skipped NAT gateways to reduce cost and simplify setup.
The CIDR blocks for VPCs 1 and 2 are 10.1.0.0/16 and 10.2.0.0/16. They have to be unique because overlapping ranges would cause routing conflicts between VPCs. Distinct blocks ensure smooth traffic movement across the peering without IP conflict.
I also launched 2 EC2 instances
I didn't set up key pairs for these EC2 instances as theyʼre only for testing VPC peering. No SSH access is needed, with EC2 Instance Connect, AWS actually manages a key pair for us.
VPC Peering
A VPC peering connection is a private network bridge between two VPCs that lets them share resources securely using internal IPs, bypassing the public internet.
VPCs would use peering connections to privately exchange traffic using internal IPs, keeping data secure and avoiding public internet exposure while connecting isolated networks.
The difference between a Requester and an Accepter in a peering connection is who initiates and who approves the link between two VPCs.
Updating route tables
After accepting a peering connection, my VPCsʼ route tables need to be updated because they donʼt know how to reach each other yet. Adding a route makes traffic flow securely through the peering link.
My VPCs' new routes have a destination of the other VPCʼs CIDR block 10.2.0.0/16 for VPC 1 and 10.1.0.0/16 for VPC 2. The routesʼ target was the VPC peering connection ID that links Maven-1 and Maven-2.
In the second part of my project
Step 5 - Use EC2 Instance Connect
I'm about to use EC2 Instance Connect to access my first EC2 instance and check if itʼs reachable within the peered VPC network. If thereʼs a connection error, Iʼll troubleshoot issues like route tables or security group settings to fix it.
Step 6 - Connect to EC2 Instance 1
I'm going reconnecting to Instance 1 using EC2 Instance Connect and fixing another connectivity issue likely from security group rules or routing to confirm stable VPC peering setup.
Step 7 - Test VPC Peering
I'm testing if my Instance 1 can reach Instance 2 through VPC peering, then fixing any network issues until Instance 2 sends messages back proving my VPCs can talk to each other!
Troubleshooting Instance Connect
Next, I used EC2 Instance Connect to access my EC2 instance quickly using a browser, without key pairs. It helped me verify VPC connectivity and troubleshoot any connection issues.
I was stopped from using EC2 Instance Connect as my instance had no public IP, auto-assign public IP was disabled. EC2 Instance Connect needs a public IP for browser-based access to work.
Elastic IP addresses
To resolve this error, I set up Elastic IP addresses. Elastic IPs are static public IPs that let me reconnect to my EC2 instance even when auto-assign public IP is disabled during setup.
Associating an Elastic IP address resolved the error because it gave my EC2 instance a public IP, letting EC2 Instance Connect work even though auto-assign public IP was disabled at launch.
Troubleshooting ping issues
To test VPC peering, I ran the command 'ping ' from Instance 1 to confirm network connectivity across the peering link.
A successful ping test would validate my VPC peering connection because it shows traffic flows between VPCs, confirming routes and security setups work.
I had to update my second EC2 instance's security group because it blocked ICMP. I added a new rule that allowed ICMP from the first VPCʼs CIDR block.
🤝Next in the series builds on this, which is "VPC Monitoring with Flow Logs"
Top comments (0)