How do I calculate how many hosts a subnet needs?

Count the devices that need an address, add room for growth, then pick the smallest subnet whose usable host count covers that number. Usable hosts equals 2^(32 minus prefix) minus 2 on a standard network.

What size subnet do I need for 100 hosts?

A /25, which gives 126 usable hosts. A /26 gives only 62, which is too few, so you round up to the /25.

Is it better to make a subnet too big or too small?

Neither extreme is good. Too small and you run out of addresses and have to renumber; too big and you waste space and create an oversized broadcast domain. Size for current devices plus sensible growth, then round up to a clean prefix.

Why do cloud subnets have fewer usable hosts?

Cloud providers reserve more addresses per subnet than a standard LAN. AWS and Azure reserve 5, GCP reserves 4, and OCI reserves 3, versus 2 (network and broadcast) on a normal network.

How to Choose a Subnet Size

Picking a subnet size sounds like it should be simple arithmetic, and the maths part is. The harder part is judgement: how much room to leave, when to round up, and when a clean layout beats a tightly packed one. This guide is the rule of thumb I wish I had when I started, with the reasoning behind each step.

Step 1: count the hosts you actually need

Start with the number of devices that need an address on the subnet, then be honest about growth. A subnet sized for exactly today is a subnet you will be redoing in six months.

Remember that two addresses in every normal subnet are not usable: the network address and the broadcast address. So a /24 gives you 254 usable hosts, not 256. The formula is:

usable hosts = 2 to the power of (32 minus prefix), minus 2

Prefix	Total addresses	Usable hosts
/27	32	30
/26	64	62
/25	128	126
/24	256	254
/23	512	510
/22	1,024	1,022

Step 2: round up to the next size that fits

Subnets only come in powers of two, so you cannot make a subnet that holds exactly 100 hosts. You pick the smallest one that is big enough. Need 100 hosts? A /25 (126 usable) fits; a /26 (62) does not. Need 300? A /23 (510) is your size.

A useful habit: pick the size that fits, then ask whether the next size up is worth it. Going from a /25 to a /24 doubles your headroom for one extra bit. If this subnet is likely to grow, that is often a good trade.

Step 3: leave room to grow, within reason

The classic mistake is sizing every subnet to the device count plus two and feeling clever about it. Then a new printer, a handful of IoT gadgets, or a second access point shows up and you are out of addresses on a network you cannot easily expand without renumbering.

The opposite mistake is making everything a /16 “to be safe”. That wastes address space, makes the broadcast domain needlessly large, and means a single subnet now spans tens of thousands of addresses you will never use. On a busy layer-2 network, an oversized broadcast domain is a real performance and troubleshooting headache.

A reasonable default for a general-purpose LAN is to size for current devices, double it, then round up to the nearest clean prefix. For a point-to-point link between two routers, do the opposite and use a /30 (2 usable) or a /31, because you know it will only ever hold two ends.

Step 4: account for the cloud

If you are sizing a subnet in a cloud VPC, the usual “minus 2” is wrong. Cloud providers reserve more addresses per subnet:

Platform	Reserved per subnet	Usable in a /24
Standard LAN	2	254
AWS	5	251
Azure	5	251
Google Cloud	4	252
Oracle Cloud	3	253

It is a small difference at /24, but at a /28 (16 addresses) losing 5 to AWS instead of 2 takes you from 14 usable down to 11, which matters when you are packing small subnets tightly. The subnet calculator has a cloud mode toggle so you can see the real usable count for each provider instead of doing it in your head.

Step 5: keep the layout clean

When you carve a parent network into children, sizes that align on clean boundaries are far easier to read, summarise, and firewall. Four equal /26 subnets out of a /24 is tidy. A jumble of one /25, one /27, and three /28s squeezed in wherever they fit is technically valid but painful to reason about later.

When your subnets genuinely need to be different sizes (a big user LAN, a small server VLAN, a tiny link network), that is exactly what VLSM is for: it assigns each requirement the smallest prefix that fits and packs them without overlap. The VLSM planner does this for you, and the VLSM guide explains the method.

A worked example

Say you are planning a small office out of 192.168.10.0/24:

Staff LAN: 60 devices today, likely 100 within a year. Size for 100, round up: /25 (126 usable).
Servers: 10 devices, stable. /28 (14 usable) is plenty.
Guest wifi: unpredictable, could spike. /26 (62 usable) gives headroom.
Router-to-firewall link: exactly 2 ends. /30.

Add those up, drop them onto the /24 with VLSM, and you have a layout that fits, leaves sensible headroom where growth is likely, and stays tight where it is not.

Try it

Open the subnet calculator, start from your parent network, and split it down to see the host counts at each size. When the sizes need to differ, switch to the VLSM planner and let it place them. The CIDR reference has the full table of every prefix if you want to look up a size directly.