Course outline · 0% complete

0/27 lessons0%

Course overview →

Your private slice of the network

lesson 5-1 · ~10 min · 13/27

Lesson 4-2 closed with a pattern worth naming. A brand-new S3 bucket, a brand-new security group, and an identity with no policies share one property.

All three deny everything by default. Access is always an explicit exception.

Default deny is AWS's recurring design rule, and you have now met it three times: IAM in lesson 2-2, security groups in 3-3, and buckets in 4-2. This lesson adds the layer underneath the security groups, which is the network itself.

VPC: your own private network

Without private networking, every machine you rent would sit directly on the shared internet, and your database would be one bad firewall rule away from the whole world. AWS's answer: every instance you launch lands inside a VPC (Virtual Private Cloud), your own private network within a region. Machines inside can talk to each other, and nothing outside can even reach the network without you wiring up a path. Docker gave you a miniature of this: containers on one Docker network reach each other by name while the outside world sees only published ports.

A VPC covers a range of private IP addresses, written in CIDR notation: 10.0.0.0/16. Read the /16 as "the first 16 bits are fixed as the network's name, the remaining 32−16 = 16 bits enumerate the machines". So a /16 holds 2¹⁶ = 65,536 addresses, and a bigger slash number means a smaller network.

You then divide the VPC into subnets, smaller ranges that each live in exactly one availability zone (lesson 1-2). A typical layout: one public and one private subnet in AZ a, the same pair in AZ b.

VPC 10.0.0.0/16internet, reachable only through the gatewayinternet gatewayAZ us-east-1apublic subnet 10.0.1.0/24web serverprivate subnet 10.0.2.0/24databaseAZ us-east-1bpublic subnet 10.0.3.0/24web serverprivate subnet 10.0.4.0/24database
The standard VPC layout: public and private subnet pairs mirrored across two AZs. Gold marks what can face the internet, everything else is unreachable from outside.

How many machines fit in a subnet

A subnet holds 2^(32 − prefix) addresses, and AWS reserves 5 of them per subnet for its own use.

prefix=24
total=$((2 ** (32 - prefix)))
usable=$((total - 5))
echo "a /$prefix subnet has $total addresses, $usable usable (AWS reserves 5)"

Output

a /24 subnet has 256 addresses, 251 usable (AWS reserves 5)

The exponent is 32 - prefix because an IPv4 address is 32 bits and the prefix fixes the leading ones. A /24 therefore leaves 8 bits to enumerate machines, which is 256 addresses.

The 5 reserved addresses cover the network address, the broadcast address, the VPC router, the DNS resolver, and one AWS keeps in hand. Every cloud provider reserves a few, and forgetting them is how a subnet sized for exactly 256 machines turns out to hold 251.

A subnet sizing table

Looping over four common prefixes gives the quick table you want in a design review.

for prefix in 28 24 20 16; do
  total=$((2 ** (32 - prefix)))
  usable=$((total - 5))
  echo "/$prefix -> $usable usable addresses"
done

Output

/28 -> 11 usable addresses
/24 -> 251 usable addresses
/20 -> 4091 usable addresses
/16 -> 65531 usable addresses

Reading the table

  • The loop lists all four prefixes on the for line and repeats the same two calculations, so the arithmetic lives in one place.
  • Each step of 4 in the prefix multiplies the size by 16, which is why the numbers grow so fast. Going from /24 to /20 is not a small adjustment.
  • A /28 leaves only 11 machines. Tiny subnets fill up, and a subnet that runs out of addresses fails new launches with a confusing capacity error, which is why real VPCs hand out /24 or bigger.
  • Private address space is free and enormous, so there is no reason to be frugal here. Oversizing a subnet costs nothing and undersizing one costs a migration.