Lesson 01

The VPC: your slice of the cloud

Before a single server exists, there's a network for it to live in. In AWS that's a VPC — a Virtual Private Cloud. Think of it as renting an empty office floor: nothing's in it yet, but the walls are up, and crucially, you decide the addressing scheme for everything that will ever live inside.

That addressing scheme is written in CIDR notation: something like 10.0.0.0/16. The number after the slash says how many bits of the IP address are fixed. The bits left over are yours to hand out. Fewer fixed bits → more addresses.

Size a VPC

Drag the slider to change the prefix length and watch your address space grow and shrink. AWS allows VPC blocks from /16 (biggest) to /28 (smallest).

CIDR block
10.0.0.0/16
Host bits free
16
Usable IPs*
65,531
/24 subnets that fit
256
Address space relative to a /16

*AWS reserves 5 addresses in every subnet (network, router, DNS, future use, broadcast) — hence 65,531 instead of 65,536.

Subnets: carving up the floor

You never place servers directly "in the VPC" — you place them in subnets, smaller CIDR blocks carved out of the VPC's range. A subnet has two defining properties:

① It lives in exactly one Availability Zone (one physical data-center cluster). If you want to survive an AZ outage, you need subnets in at least two AZs — this is why every "highly available" architecture diagram shows things in pairs.

② It has exactly one route table attached, and that route table is what makes a subnet "public" or "private." There is no public: true checkbox. It's all routing.

The one-sentence rule: a subnet is public if its route table has a route sending 0.0.0.0/0 (i.e. "everything else") to an Internet Gateway. That's it. That's the whole distinction.

Prove it: strand a packet

Below is a VPC with two subnets and an instance in each. Subnet A's route table has an internet route; Subnet B's doesn't. Send packets and see what happens — then toggle routes to change reality.

Route table playground

Send a packet to 8.8.8.8 from each instance. Then toggle routes below and try again. Watch where the packet dies.

internet 8.8.8.8 VPC 10.0.0.0/16 IGW NAT Subnet A · 10.0.1.0/24 · AZ-a instance A 10.0.1.10 Subnet B · 10.0.2.0/24 · AZ-a instance B 10.0.2.10
ROUTE TABLE — Subnet A
10.0.0.0/16local
0.0.0.0/0igw-01ab
ROUTE TABLE — Subnet B
10.0.0.0/16local
0.0.0.0/0nat-07cd

Notice what happened when you gave Subnet B a NAT route: the packet went to the NAT gateway (which lives in the public subnet), and the NAT relayed it out through the IGW. That's the standard pattern for private workloads: they can dial out — to pull packages, call APIs — but nothing on the internet can dial in, because they have no public IP and no inbound path.

Why this matters at work: app servers, databases, and ECS tasks almost always live in private subnets. The only things in public subnets are the front doors — load balancers, NAT gateways, the occasional bastion. If you ever see a database in a public subnet, that's a finding.

Check yourself

1. A subnet's route table has only the route 10.0.0.0/16 → local. What is this subnet?

The local route covers traffic inside the VPC and can't be removed. With no 0.0.0.0/0 route, packets destined anywhere else are simply dropped — fully private, fully valid.

2. You need roughly 1,000 usable IPs in one subnet. Which CIDR is the smallest that works?

Each bit doubles the space: /24 → 256 addresses, /23 → 512, /22 → 1,024. Subtract AWS's 5 reserved addresses and /22 gives you 1,019 usable.

3. Why does a NAT gateway have to sit in a public subnet?

The NAT gateway forwards traffic onward to the internet, so its subnet needs the 0.0.0.0/0 → IGW route. A NAT in a private subnet would be a dead end relaying to nowhere.