CIDR Block

What is a CIDR block?

CIDR notation (10.0.0.0/16) describes an IP range as a base address plus a prefix length: the /16 means the first 16 bits are fixed and the rest vary, yielding 65,536 addresses. Smaller suffix, bigger network — /8 is ~16.7 million addresses, /24 is 256, /32 is exactly one host. Every VPC, subnet, firewall rule, and route you will ever write speaks this notation.

The math worth memorizing

Each step in prefix length halves the range: /16 → two /17s → four /18s. Cloud subnetting is just this recursion — carve a /16 VPC into /20 subnets per AZ and tier. AWS quietly reserves 5 addresses per subnet (network, broadcast, router, DNS, future), so a “/28 with 16 IPs” gives you 11 — the classic capacity surprise in small subnets hosting autoscaling groups or EKS pods, which consume IPs far faster than instance counts suggest.

The permanence problem

CIDR choices are effectively forever: once workloads hold addresses, renumbering is a migration project. And the failure mode is collision — two networks both chose 10.0.0.0/16, and now peering, VPNs, or a merger demand they interconnect. Routing cannot distinguish overlapping ranges; the fixes (NAT gymnastics, renumbering) are all painful. The professional habit: keep an IP allocation plan (or IPAM tooling) from day one, assign non-overlapping supernets per environment/region, and always leave unallocated space.

What people get wrong

• Sizing subnets by server count — containers, load balancer ENIs, and Lambda interfaces consume IPs; EKS clusters exhaust /24s routinely.
• 0.0.0.0/0 reflexes: it means “everywhere” in both routes and security rules; every accidental use is an exposure.
• Forgetting IPv6 mostly ends the scarcity game — cloud VPCs hand out /56s; dual-stack designs sidestep future overlap entirely.

Primary source: RFC 4632 — Classless Inter-Domain Routing

Why CIDR Planning Deserves Upfront Care

Because two networks with overlapping CIDR blocks cannot be directly connected via VPC peering or Transit Gateway without a disruptive readdressing effort, organizations that anticipate ever needing to connect multiple VPCs — to each other, to on-premises networks, or through an acquisition merging two previously separate cloud environments — benefit enormously from choosing non-overlapping CIDR ranges from the very start, even before any specific connection is planned. This upfront discipline is one of the cheapest insurance policies in cloud network design, since the cost of fixing an overlapping range after the fact, once real resources and dependent configuration exist within it, is disproportionately higher than getting it right from day one.