Planning a Cloud Network: Choosing CIDR Blocks You Won't Regret in a Year

By Mohak Mangal · Published October 26, 2026 · 8 min read

Most subnetting advice is written for exam candidates. Cloud networks are a little different, because you rarely get to change them once they're full of running systems. Pick a block that's too small and you'll be migrating servers on a weekend. Pick one that overlaps with your office network and your VPN simply won't work.

The classic mistake: everyone picks 10.0.0.0/16

Look at the default suggestions in cloud consoles and you'll see why every team ends up in the same few ranges. Then two years later, the company acquires another firm, or connects a second region, or needs to peer with a partner, and both sides are using 10.0.0.0/16. Overlapping address space can't be routed between. The only real fix is renumbering, which is slow and risky.

A cheap habit: write down every range you use, anywhere, in one shared document. Home lab, office, each cloud account, each VPN. Before you create anything new, check the list.

Cloud providers keep some addresses for themselves

In a traditional network, a subnet loses two addresses: the network and the broadcast address. In cloud subnets, a few more are taken for routing, DNS and future use. Amazon VPC and Azure reserve five addresses in every subnet. Google Cloud reserves four in a subnet's primary IPv4 range. Check each provider's current documentation, since details can change, but plan on losing around five.

That matters most in small subnets. A /28 has 16 addresses; subtract five and you have 11 for actual machines. Nobody enjoys finding that out after a deployment fails.

Sizing table (with five reserved)

The figures come straight from 2^{(32 − prefix)}. You can verify any row with the CIDR subnet calculator.

Size for the weirdest thing you run, not the average

Servers are easy to count. The things that eat addresses are the ones that scale automatically:

• Kubernetes. In some managed setups, every pod gets a real VPC address. A modest cluster can consume hundreds of IPs, and it grows when it autoscales.
• Serverless functions and load balancers that attach network interfaces into your subnets.
• Rolling deployments. During an update you may briefly run old and new copies side by side, which doubles your need for a few minutes.

As a rough habit, estimate the peak, double it, then round up to the next power of two. It feels wasteful and it is, but private address space is cheap and renumbering isn't.

A layout that has worked for a lot of teams

Start with a VPC large enough to hold everything you can imagine: a /16 gives you 256 subnets of /24 size. Then carve it by role and by availability zone, leaving gaps:

• Public subnets (load balancers, bastion hosts): small, one per zone, e.g. /26
• Application subnets: medium, e.g. /22 per zone
• Database subnets: small and private, e.g. /27 per zone
• A reserved block you deliberately leave empty for the future

Allocate the largest blocks first, so that they line up on clean boundaries. A /22 must start on a multiple of four in the third octet (10.0.0.0, 10.0.4.0, 10.0.8.0...). The calculator will tell you immediately if an address isn't a valid network start for the prefix you chose.

Think about IPv6 early, even if you don't use it yet

Most clouds can assign a /56 IPv6 block to a VPC and /64 subnets within it. Turning it on later is possible but easier when you plan for it from the start.

Document it like someone else will inherit it

Keep a table: range, purpose, owner, environment. When something breaks at 2 a.m. and a stranger has to work out whether 10.14.32.0/22 is production or staging, you'll be glad it exists. That tiny document does more for network sanity than any clever design.