- TechOps Examples
- Posts
- Understanding CIDR
Understanding CIDR
Govardhana M K
June 17, 2025
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.
👋 Before we begin... a big thank you to today's sponsor PROTON
Organizations that need security choose Proton Pass
Proton Pass Business helps teams securely share passwords, manage access, and simplify onboarding.
Trusted by 50,000+ businesses and featured in The Verge and TechCrunch, Pass was built by the teams behind Proton Mail’s and SimpleLogin for startups, nonprofits, and enterprises alike. Secure your accounts, no training required.
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:
IN TODAY'S EDITION
🧠 Use Case
Understanding CIDR
🚀 Top News
👀 Remote Jobs
VyOS is hiring a Python Developer with DevOps background
Remote Location: Worldwide
Supabase is hiring a Cloud Platform / Site Reliability Engineer
Remote Location: Worldwide
📚️ Resources
🛠️ TOOL OF THE DAY
kube-composer - A modern, intuitive Kubernetes YAML generator that simplifies deployment configuration for developers and DevOps teams.
🧠 USE CASE
Understanding CIDR
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.
Download a high resolution copy of this cheat sheet here for future reference.
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.