In this article, I will walk you through how I built the setup step-by-step, what I learned along the way, and why this project strengthened my understanding of AWS and cloud infrastructure security.
What is a VPC?
A VPC (Virtual Private Cloud) is a logically isolated section of the AWS Cloud where you can launch resources like EC2 instances, databases, and load balancers in a private, secure network that you control.
You decide the IP address range, create subnets, and define rules that manage how traffic moves within and outside your network.
Think of it as your own private data center hosted inside AWS.
Tools and Services I Used
Here are the AWS components I worked with in this project:
VPC *– To create a private network
**Subnets *– Divided into public and private zones
**Internet Gateway (IGW) – To allow internet access for public resources
NAT Gateway **– To allow private resources to access the internet securely (for updates, downloads, etc.)
**Route Tables – To control how traffic flows
Security Groups and Network ACLs (NACLs) – To define inbound and outbound rules for security
EC2 Instances – To test and verify the setup
Step-by-Step Setup
Step 1: Create a VPC
I started by creating a new VPC with a CIDR block of 10.0.0.0/16, which gives me up to 65,536 private IP addresses. This range acts as the foundation for all the subnets I created later
Step 2: Create Subnets (Public and Private)
To separate resources and improve security, I created:
Public Subnet – for resources that need internet access (like web servers)
Private Subnet – for backend systems such as databases or application servers that should not be accessible directly from the internet
Each subnet had its own CIDR range:
Public Subnet: 10.0.1.0/24
Private Subnet: 10.0.2.0/24
Step 3: Attach an Internet Gateway (IGW)
The Internet Gateway connects the public subnet to the internet. I created internet gateway, then I attached it to my VPC and updated the public route table to direct all outbound traffic (0.0.0.0/0) to the IGW.
Step 4: Set Up a NAT Gateway
The NAT Gateway (Network Address Translation) allows resources in the private subnet to access the internet securely (for software updates or package installations) while keeping them hidden from incoming traffic.
I placed the NAT Gateway inside the public subnet and attached an Elastic IP to it.
Step 5: Create and Configure Route Tables
I created two route tables:
Public Route Table – Linked to the public subnet and directed internet traffic to the IGW.
Private Route Table – Linked to the private subnet and directed traffic through the NAT Gateway.
This ensures that:
Public subnet resources (like web servers) can communicate with the internet.
Private subnet resources (like databases) can reach the internet for updates, but cannot be accessed directly.
I also edited the association to linked the private and public route to the subnets accordingly.
Step 6: Launch EC2 Instances to Test
I launched one EC2 instance in the public subnet and another in the private subnet to test communication:
From my public instance, I could SSH into it using the Elastic IP.
From there, I could connect to the private instance through its private IP — confirming that the network worked perfectly.
Step 7 : Configure Security Groups
Security groups act as virtual firewalls for EC2 instances.
For the public subnet, I allowed:
Inbound: HTTP (port 80), HTTPS (port 443), and SSH (port 22)
Outbound: All traffic (default)
For the private subnet, I allowed only:
Inbound: Traffic from the public subnet’s security group (e.g., for database connections)
Outbound: All traffic (so the instance can reach the internet via NAT)
Step 7: Add Network ACLs (NACLs)
NACLs provide an additional layer of network security at the Subnet Level.
I created NACLs for both subnets:
Public subnet NACL: Allows inbound/outbound HTTP, HTTPS, and SSH.
Private subnet NACL: Allows only internal communication and outbound connections through NAT.
Each rule has a rule number (like 100, 200, etc.) to control priority — lower numbers are evaluated first.
What I Learned
This project helped me understand how AWS networking and security really work in practice. Some key takeaways:
How public and private subnets help build secure architectures
How route tables control data flow within a VPC
The role of NAT Gateways and Internet Gateways in network design
How Security Groups and NACLs work together for defense in depth
How to think like a DevOps engineer, focusing on scalability and security from the ground up
Challenges I Faced During the Project.
1. CIDR Block Confusion
At first, I struggled to understand how to choose CIDR blocks correctly without overlapping IP ranges. I learned that each subnet must have a unique portion of the VPC’s IP range (for example, 10.0.1.0/24 and 10.0.2.0/24), and planning this ahead helps avoid routing issues later.
2. Internet Access Not Working for Private Instances
Initially, my private EC2 instance couldn’t reach the internet. The issue was that I hadn’t configured the NAT Gateway and Private Route Table properly. After updating the route table to direct 0.0.0.0/0 traffic to the NAT Gateway, everything worked perfectly.
3. Security Group and NACL Confusion
Understanding the difference between Security Groups (Stateful) and NACLs (Stateless) was tricky. I accidentally blocked SSH traffic at first because my inbound/outbound rules weren’t aligned. This helped me learn that:
Security Groups remember allowed connections automatically.
NACLs require explicit inbound and outbound permissions for each direction.
Conclusion:
Setting up a secure VPC gave me hands-on confidence in AWS networking and reinforced how important it is to design systems with security in mind from the very beginning.
If you’re starting your DevOps or cloud journey, I highly recommend trying this project, it’s one of the best ways to truly understand how the cloud works behind the scenes.
Have you tried setting up a VPC before? What challenges did you face?
Top comments (0)