AWS VPC(Virtual Private Cloud) Explained Like a Gated Society: Gates, Guards, Roads, and a 15-Minute Lab

TL;DR: A VPC is your private slice of AWS. "Public" or "private" is decided by one route, not a checkbox. Security groups guard instances, NACLs guard subnets, endpoints keep AWS traffic off the internet, and Flow Logs tell you what happened. Read the story, run the lab, steal the checklist.

Start here: a 10-second quiz

• ✅ A mental model you won't forget (gated housing society)
• ✅ The journey of one request, from the internet to your server and back
• ✅ Security Groups vs NACLs, finally clear
• ✅ A 15-minute CLI lab with proof and cleanup
• ✅ Attacker vs defender view, common mistakes, and a checklist

🏘️ The mental model: a gated society

🗺️ The big picture

Three paths to remember:

• Inbound: Internet → IGW → Load Balancer → App → Database
• Outbound (updates, APIs): App → NAT Gateway → IGW → Internet
• AWS services: App → S3 Gateway Endpoint → S3 (never touches the internet)

📦 Follow one request

1. DNS resolves the domain to the load balancer's public IP
2. The packet hits the Internet Gateway
3. The subnet's route table sends it to the load balancer inside the VPC
4. The subnet's NACL inbound rules are checked
5. The load balancer's Security Group is checked
6. The load balancer forwards to your app. The app's Security Group must allow traffic from the load balancer's Security Group
7. The response goes back. Security Groups allow it automatically (stateful), but the NACL outbound rules must allow it too, or it silently dies

🧩 Piece by piece

1. The VPC and its CIDR

• Don't overlap with your office network, home lab, or any VPC you might peer with later. Overlapping ranges can't be connected
• A comfortable default: /16 for the VPC, /24 for subnets
• A /24 gives you 251 usable IPs, because AWS reserves 5 per subnet

2. Subnets: "public" is not a setting

3. Route tables: the real boss

• The most specific route wins (10.0.0.0/16 beats 0.0.0.0/0)
• Every VPC has a built-in local route, so anything in the VPC can reach anything else in the VPC. Security Groups are what stop that

4. IGW vs NAT Gateway

5. Security Groups vs NACLs

6. VPC Endpoints: keep AWS traffic off the internet

• Gateway endpoints (S3 and DynamoDB): added as a route, no hourly charge
• Interface endpoints (PrivateLink, most other services): a network interface in your subnet, billed hourly plus data

🏗️ Real-world layout: the 3-tier pattern

🧪 Lab: build it yourself in about 15 minutes

🔍 Prove the "public vs private" claim

🔒 Add a tight Security Group and a private path to S3

🧹 Cleanup

🔴 Attacker view vs 🔵 Defender view

❌ Mistakes that actually cause incidents

• Database in a public subnet "just for now"
• 0.0.0.0/0 on port 22 or 3389
• Running production in the default VPC
• Overlapping CIDR ranges, discovered only when you try to peer
• A NAT Gateway left running after a lab
• Using NACLs as the main firewall, then losing a day to stateless return-traffic rules
• No Flow Logs, so nobody can answer "what happened?"

✅ Your 8-point VPC checklist

• [ ] CIDR planned so it won't overlap with anything you'll connect
• [ ] Subnets spread across at least two AZs
• [ ] Databases and app servers in private subnets
• [ ] Only the load balancer lives in the public tier
• [ ] Security Groups reference other Security Groups
• [ ] Gateway endpoints for S3 and DynamoDB
• [ ] Flow Logs enabled
• [ ] Nothing important in the default VPC

📌 Cheat sheet: "I need X, so I use Y"

💬 Your turn

1. Did the route-table check make "public vs private" click? Tell me what you saw in your output
2. What confused you most: route tables, SG vs NACL, or NAT vs IGW? Vote, and the winner gets a deep-dive
3. Drop your own VPC gotcha in the comments. We all learn more from the thing that broke