- TechOps Examples
- Posts
- How to Set the Right Subnet Sizing for Your Cloud Network
How to Set the Right Subnet Sizing for Your Cloud Network
TechOps Examples
Hey — It's Govardhana MK 👋
Welcome to another technical edition.
Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.
Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities and articles.
👋 👋 A big thank you to today's sponsor GUIDDE
Effortless Tutorial Video Creation with Guidde
Transform your team’s static training materials into dynamic, engaging video guides with Guidde.
Here’s what you’ll love about Guidde:
1️⃣ Easy to Create: Turn PDFs or manuals into stunning video tutorials with a single click.
2️⃣ Easy to Update: Update video content in seconds to keep your training materials relevant.
3️⃣ Easy to Localize: Generate multilingual guides to ensure accessibility for global teams.
Empower your teammates with interactive learning.
And the best part? The browser extension is 100% free.
IN TODAY'S EDITION
🧠 Use Case
How to Set the Right Subnet Sizing for Your Cloud Network
👀 Remote Jobs
Ozone is hiring a DevOps Engineer
Remote Location: Worldwide
Sporty Group is hiring a Site Reliability Engineer
Remote Location: Worldwide
📚️ Resources
If you’re not a subscriber, here’s what you missed last week.
To receive all the full articles and support TechOps Examples, consider subscribing:
🧠 USE CASE
How to Set the Right Subnet Sizing for Your Cloud Network
A lot of cloud engineers run into unexpected issues not because they don’t know networking, but because they misjudge how IP ranges actually behave.
You're spinning up workloads, connecting VPCs, or designing subnets for EKS or ECS. You pick a CIDR block that seems "big enough." And then, later, you realize the IP space wasn’t just small, it was too rigid, too overlapping, or too fragmented for the actual network flow.
The root cause? A mental gap between what CIDR notation says and how that translates into usable, flexible IPs in real deployments.
Quick Primer
CIDR stands for “Classless Inter-Domain Routing”. It helps you define IP ranges.
A CIDR block is written like this: IP_address/prefix_length, e.g. 172.16.0.0/16.
The number after the slash in CIDR (like /16) tells how many bits are fixed. The rest can change, giving you more or fewer IPs.
You’ll see CIDR blocks used across - VPC CIDR ranges, Subnet definitions, Security group and NACL rules, Route tables and peering configs
An octet is one of the four parts in an IP address, separated by dots. Each octet is 8 bits, allowing values from 0 to 255 (we are referring IPv4 here).
Instead of memorizing what /16 or /24 means, it’s better to understand what part of the IP is allowed to change.

Common CIDR Examples in the Real World
0.0.0.0/0→ All IPv4 addresses. Used to allow traffic from anywhere.10.0.0.0/8→ Covers the entire10.x.x.xprivate range.192.168.1.0/24→ A common default for home or dev environments.
Subnet Sizing with Context
Once you’re clear on how octets shift, the next task is choosing the right subnet size. This visual answers that.

Now here’s the gotcha most engineers learn too late. You pick a /24, thinking you have 256 IPs.
But the moment you attach this to an AWS VPC, 5 of those are gone. Reserved.
One for the network base
One for broadcast (even though AWS doesn’t use it)
One for the default gateway
One for DNS
One kept aside for future use
That means only 251 IPs are actually usable. The smaller the subnet, the bigger the impact.
A /30 CIDR block provides 4 IP addresses, but AWS reserves 5, so it becomes completely unusable for deployments.
You don’t notice this in dev environments. But in production, when auto-scaling fails silently or new pods can’t start due to IP exhaustion, it’s this detail that bites.
You now have the map. Use it early. Save yourself the rewiring later.
🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)

