AWS Networking for Dummies: VPC, Subnets, and More Explained Simply

If you've ever tried to set up an application on AWS and found yourself staring at terms like "VPC", "NACL", and "Internet Gateway" with absolutely no idea what they mean — this post is for you.

We're going to break down six core AWS networking concepts using a single analogy: an office building. By the end, you'll understand how all the pieces fit together and why each one exists.

The Big Picture: Your Office Building in the Cloud

Think of AWS as a massive city with countless buildings. When you sign up for AWS, they give you a plot of land in that city where you can construct your own private building. Everything inside that building is yours — your servers, databases, and applications. Nobody from outside can walk in uninvited.

That building is your VPC. Everything else we'll discuss — subnets, route tables, gateways, security groups, NACLs — are the floors, doors, security guards, and rules that govern your building.

Let's walk through each one.

VPC — Your Private Building

VPC (Virtual Private Cloud) is an isolated, private network within AWS. When you launch AWS resources like EC2 instances or RDS databases, they live inside a VPC.

Think of a VPC as a private office building:

• Only you (and whoever you invite) can operate inside it
• It has its own address range (like a building having floors 1 through 10)
• Multiple teams can have separate spaces inside the same building
• It's completely isolated from other buildings (other AWS customers)

When you create a VPC, you define its IP address range using something called a CIDR block — for example, 10.0.0.0/16. This is like saying "our building covers addresses 10.0.0.0 through 10.0.255.255" — giving you 65,536 possible addresses to work with.

Every AWS account gets a default VPC automatically. When you're just starting out and launch an EC2 instance without specifying a VPC, it goes into this default one.

Subnet — The Floors of Your Building

Once you have a building (VPC), you divide it into floors. Each floor serves a different purpose. That's what a Subnet is — a segment of your VPC with its own smaller IP range.

There are two types of subnets:

• Public Subnet — The lobby floor. Accessible from the outside world. You'd put your web servers and load balancers here, since they need to be reachable by users on the internet.
• Private Subnet — The internal floors. No direct access from the internet. You'd put your databases, internal APIs, and backend services here — things that should only be accessed by other parts of your application, not the public.

A VPC can have many subnets, and they can be spread across different Availability Zones (think of these as different physical buildings in the same city — spreading resources across them improves reliability).

Example: You might create:

• 10.0.1.0/24 — Public Subnet (web servers, 256 addresses)
• 10.0.2.0/24 — Private Subnet (database, 256 addresses)

Route Table — The Directory Board

Every floor (subnet) in your building has a directory board that tells people where to go. In AWS, this is the Route Table — a set of rules that determines where network traffic gets sent.

A route table contains entries like:

• "Traffic going to 10.0.0.0/16? Stay inside the building (local)."
• "Traffic going to 0.0.0.0/0? Head to the Internet Gateway (exit the building)."

Key things to know:

• Every subnet must be associated with a route table
• A route table can be shared by multiple subnets
• The main route table is created automatically with your VPC
• Public subnets have a route to the Internet Gateway; private subnets do not

This is what makes a subnet "public" or "private" — it's not the subnet itself, it's the route table attached to it. If the route table has a route pointing to an Internet Gateway, traffic can flow to and from the internet.

Internet Gateway — The Front Door

Your building needs a front door that connects it to the outside world (the internet). In AWS, that front door is the Internet Gateway (IGW).

An Internet Gateway:

• Attaches to your VPC (one IGW per VPC)
• Allows resources in public subnets to send and receive traffic from the internet
• Is highly available and scales automatically — you never need to manage it
• Does nothing by itself — it only works when subnets have route table entries pointing to it

Without an Internet Gateway, your VPC is completely isolated. Nobody from the internet can reach your servers, and your servers can't reach the internet either. This is sometimes intentional — fully private VPCs exist for sensitive workloads that should never touch the public internet.

Important: Even with an Internet Gateway, EC2 instances also need a public IP address (or Elastic IP) to be reachable from the internet. Think of it as a building having a front door AND each office having a nameplate on it.

Security Group — The Bouncer for Each Office

Now let's talk about security. Imagine each employee in your building has their own personal bouncer who controls who can enter or leave their office. That's a Security Group.

Security Groups are virtual firewalls applied at the instance level (like an EC2 server). They control inbound and outbound traffic for specific resources.

Key characteristics:

• Stateful — If you allow traffic in, the response is automatically allowed back out. You don't need separate rules for both directions.
• Allow-only — You can only write rules that _allow_ traffic. There's no concept of explicitly blocking; anything not allowed is simply denied.
• Applied to instances — Each EC2 instance can have one or more security groups attached.
• Default: deny all inbound, allow all outbound — Fresh security groups block all incoming traffic and allow all outgoing traffic.

Example rules for a web server's security group:

• Allow inbound TCP port 80 from anywhere (HTTP traffic from users)
• Allow inbound TCP port 443 from anywhere (HTTPS traffic from users)
• Allow inbound TCP port 22 from your IP only (SSH for administration)

Security Groups are the most commonly used security layer in AWS and are usually sufficient for most use cases.

NACL — The Checkpoint at Each Floor's Entrance

While Security Groups protect individual offices (instances), NACLs (Network Access Control Lists) protect entire floors (subnets). Think of a NACL as a security checkpoint at the stairwell entrance of each floor — every person entering or leaving that floor must pass through it.

Key characteristics:

• Stateless — Unlike Security Groups, NACLs don't remember connections. You must explicitly write rules for both inbound AND outbound traffic.
• Allow AND deny rules — NACLs can explicitly block specific IP addresses or ports, which Security Groups cannot.
• Applied to subnets — Rules apply to all traffic entering or leaving a subnet.
• Rules are numbered and evaluated in order — Lower numbered rules are checked first. The first matching rule wins.
• Default NACL: allow all — The default NACL that comes with your VPC allows all traffic in and out.

When would you use a NACL over a Security Group?

Use a NACL when you need to block specific IP addresses (for example, blocking a known malicious IP from even entering your subnet), or when you want subnet-wide rules that apply regardless of which instances are inside.

The Full Picture: How Everything Connects

Here's what happens step by step when a user visits your website:

1. User request hits the Internet Gateway
2. IGW routes it into the VPC
3. The Route Table for the public subnet forwards it to the correct subnet
4. The NACL on the public subnet checks if this traffic is allowed
5. The Security Group on the web server checks if the specific port is open
6. Request reaches your EC2 web server
7. Web server queries the database in the private subnet (Security Group on RDS allows port 5432 from the web server's Security Group only)

Security Group vs NACL — Key Differences

Rule of thumb: Use Security Groups for most things. Add NACLs only when you need to explicitly block traffic at the subnet level (like blocking an IP range).

Quick Reference

Wrapping Up

AWS networking can feel intimidating at first, but it follows a logical hierarchy. Start with the VPC (your building), divide it into subnets (floors), attach an Internet Gateway if you need internet access, configure route tables to direct traffic, and then layer on Security Groups and NACLs to control who gets in.

You don't need to understand every edge case on day one. The most common setup — a VPC with one public and one private subnet, an Internet Gateway, and Security Groups on your instances — covers the vast majority of real-world use cases.