When I started studying AWS, VPC was the topic that made me want to close my laptop and go for a walk.
Every tutorial I found was either too technical or too vague. Then one day, a senior engineer explained it to me using a house analogy, and suddenly it all made sense.
So here's my attempt to pass that clarity forward.
So What Exactly is a VPC?
VPC stands for Virtual Private Cloud. Fancy name, simple concept.
It's your own private network inside AWS. Think of it as buying a plot of land with a boundary wall. Inside that wall, you decide everything. What buildings go where. Who can enter. Who can leave. What roads connect what.
AWS gives you the land. You design the layout.
Subnets - Dividing Your Space
Once you have your land (VPC), you need to organize it. That's where subnets come in.
A subnet is just a smaller section of your VPC. Like dividing your property into a front yard and a backyard.
Public Subnet - This is your front yard. It faces the main road. Visitors can see it and reach it. You put things here that need to interact with the outside world. Web servers, load balancers, that kind of stuff.
Private Subnet - This is your backyard. Hidden from the road. No direct access from outside. You keep valuable things here. Databases, application servers, anything you don't want exposed.
Internet Gateway - Your Main Door
Here's something that tripped me up initially.
Just because you call something a "public subnet" doesn't automatically make it public. You need an Internet Gateway attached to your VPC.
The Internet Gateway is like the main door of your property. Without a door, nobody gets in or out. Doesn't matter how many rooms you have inside.
So when you create a public subnet, you also need to:
- Attach an Internet Gateway to your VPC
- Update the route table so traffic knows to use that gateway
Skip either step and your "public" subnet is just a private subnet with a misleading name.
NAT Gateway - The Interesting One
This took me a while to understand. Why would private resources ever need internet access?
Well, think about it. Your database server in a private subnet might need to:
- Download security patches
- Pull updates from package repositories
- Send logs to an external monitoring service
But you don't want anyone from the internet connecting TO your database. That would defeat the purpose of keeping it private.
NAT Gateway solves this. It lets your private resources reach out to the internet, but blocks any incoming connections. One way traffic.
Like having a mail slot in your door. You can send letters out. But nobody can climb in through it.
Putting It Together - A Real Example
Let me walk through how I set up a recent project.
I needed to deploy a simple web app with a database. Here's what I created:
VPC: 10.0.0.0/16 (gives me plenty of IP addresses to work with)
Public Subnet: 10.0.1.0/24
Placed my load balancer here
Also added a bastion host for SSH access when I need to troubleshoot
Private Subnet: 10.0.2.0/24
- My application servers live here
- They receive traffic from the load balancer
- They can reach the internet through NAT Gateway for updates
Another Private Subnet: 10.0.3.0/24
- Database goes here
- Only the application servers can talk to it
- Completely isolated from the internet
Internet Gateway: Attached to the VPC, route table configured for the public subnet
NAT Gateway: Placed in the public subnet (it needs internet access to work), private subnets route outbound traffic through it
When a user visits my site:
- Request comes through the Internet Gateway
- Hits the load balancer in public subnet
- Load balancer sends it to an app server in private subnet
- App server queries the database in the other private subnet
- Response goes back the same way
The database never touches the internet. The app servers only receive traffic from the load balancer. Everything stays controlled.
Mistakes I Made Along the Way
Forgot to update route tables - I created an Internet Gateway, attached it to my VPC, and wondered why my EC2 instance still couldn't reach the internet. Turns out the route table for that subnet was still pointing nowhere. Rookie mistake.
Put RDS in a public subnet "temporarily" - We all know how temporary solutions go. Don't do this. Just set it up properly from the start.
Used only one Availability Zone - My NAT Gateway was in one AZ. When that AZ had issues, my private resources in other AZs lost internet access. Now I always create NAT Gateways in multiple AZs for production workloads.
Overcomplicated the CIDR blocks - Started with a /24 VPC because I thought I wouldn't need much space. Then had to recreate everything when I needed more subnets. Start with /16 and give yourself room to grow.
That's Really It
VPC seems complex because AWS documentation throws every possible option at you. But the core concept is straightforward.
You get an isolated network. You divide it into sections. Some sections face the internet, some don't. Gateways control what traffic flows where.
Start with this mental model. Build a simple VPC manually through the console. Don't use the default VPC that AWS creates for you. Actually go through the steps yourself. Create subnets, attach gateways, configure route tables.
Break something. Figure out why it broke. Fix it.
That's how I learned. Probably how you'll learn too.
Top comments (0)