A prefix-to-hosts cheat sheet worth memorising
Most subnetting on the job comes down to recognising a handful of prefixes on sight. The pattern: usable hosts = 2^(32 − prefix) − 2.
| CIDR | Mask | Total addresses | Usable hosts | Typical use |
|---|---|---|---|---|
| /30 | 255.255.255.252 | 4 | 2 | Point-to-point links |
| /29 | 255.255.255.248 | 8 | 6 | Tiny appliance VLAN |
| /28 | 255.255.255.240 | 16 | 14 | Small server pool |
| /27 | 255.255.255.224 | 32 | 30 | Department subnet |
| /26 | 255.255.255.192 | 64 | 62 | Floor / office |
| /24 | 255.255.255.0 | 256 | 254 | Classic LAN |
| /23 | 255.255.254.0 | 512 | 510 | Large LAN |
| /16 | 255.255.0.0 | 65,536 | 65,534 | Campus / VPC |
The mask jumps in the familiar sequence 128, 192, 224, 240, 248, 252, 254 as you walk down each octet — once that ladder is in muscle memory you rarely need to reach for a calculator at all.
VLSM: stop wasting addresses with equal-size subnets
Carving a network into equal blocks is simple but wasteful. Variable-Length Subnet Masking (VLSM) sizes each subnet to its actual host count, largest first. Suppose you own 10.0.0.0/24 and need: 100 hosts, 50 hosts, 25 hosts, and two point-to-point links.
- 100 hosts → smallest fit is /25 (126 usable) →
10.0.0.0/25 - 50 hosts → /26 (62 usable) →
10.0.0.128/26 - 25 hosts → /27 (30 usable) →
10.0.0.192/27 - link A → /30 (2 usable) →
10.0.0.224/30 - link B → /30 →
10.0.0.228/30
Allocating largest-to-smallest keeps the blocks aligned and leaves a clean, contiguous pool free at the top for growth. Allocate in the wrong order and you fragment the space into unusable gaps.
/31 and /32: the special cases that look like bugs
A /31 has only two addresses and, under classic rules, zero usable hosts — yet it is the correct choice for a router-to-router link. RFC 3021 lets both addresses in a /31 be assigned to the two ends, eliminating the waste of a /30 on every link. A /32 is a single host route, used for loopbacks, /health anycast targets, and host firewall rules. If a calculator reports “0 usable hosts” for these, that is the arithmetic being honest, not an error — your routers know what to do with them.
The cloud reserves more addresses than this calculator does
Every subnet calculator, including this one, reports usable hosts as 2^(32−prefix) − 2 — subtracting the network and broadcast addresses. On a physical LAN that is correct. On AWS, Azure or Google Cloud it is wrong, and it is wrong in the direction that breaks capacity plans after they ship.
AWS reserves five addresses in every VPC subnet, not two: the network address, the VPC router, the DNS resolver, one held for future use, and the broadcast address. Azure reserves five as well, on the same pattern. Google Cloud reserves four.
So a /24 that this tool reports as 254 usable hosts gives you:
| Environment | Usable addresses in a /24 |
|---|---|
| Physical LAN | 254 |
| AWS VPC subnet | 251 |
| Azure subnet | 251 |
| Google Cloud subnet | 252 |
Three addresses is noise in a /24. It is not noise in a /29, where AWS leaves you three usable addresses out of eight rather than the six a calculator promises — and a /28 is the smallest subnet AWS will let you create at all, precisely because the reservations swallow anything smaller. Teams discover this when a Kubernetes node group or an ECS service quietly fails to schedule at what should have been half capacity.
Plan cloud subnets with the reserved count subtracted first, then check the prefix. It is the single most common way a correct subnet calculation still produces a broken network.
Private ranges, and what happens when you outgrow them
RFC 1918 reserves three private blocks: 10.0.0.0/8 (16.7M addresses), 172.16.0.0/12 (1M), and 192.168.0.0/16 (65k). Pick the block that matches your scale and leaves room: home labs and small offices live happily in 192.168.x.x, but a growing organisation that started there often hits a wall and faces a painful renumber. Starting in the 10/8 space costs nothing up front and postpones that day for a very long time.