CIDR Cheat Sheet

CIDR notation is one of those things every infrastructure team uses constantly, but few people want to recalculate from memory in the middle of a design review.

This page gives you a fast CIDR reference for:

  • Subnet masks
  • Total IP addresses
  • Usable hosts
  • Common cloud subnet sizes
  • Kubernetes planning context

If you just need the quick answer, start with the table below.


Quick CIDR Reference Table

CIDRSubnet MaskTotal IPsUsable Hosts
/32255.255.255.25511
/31255.255.255.25422
/30255.255.255.25242
/29255.255.255.24886
/28255.255.255.2401614
/27255.255.255.2243230
/26255.255.255.1926462
/25255.255.255.128128126
/24255.255.255.0256254
/23255.255.254.0512510
/22255.255.252.010241022
/21255.255.248.020482046
/20255.255.240.040964094
/19255.255.224.081928190
/18255.255.192.01638416382
/17255.255.128.03276832766
/16255.255.0.06553665534

These usable host counts reflect classic IPv4 subnetting:

  • network address reserved
  • broadcast address reserved

Cloud platforms reserve additional IPs inside subnets, so actual usable capacity is lower in Azure, AWS, and GCP.


How to Read CIDR Quickly

CIDR notation tells you how many bits belong to the network portion of the address.

Examples:

  • /24 = 24 network bits, 8 host bits
  • /20 = 20 network bits, 12 host bits
  • /16 = 16 network bits, 16 host bits

The smaller the prefix number:

  • the larger the subnet
  • the more total IP addresses it contains

The larger the prefix number:

  • the smaller the subnet
  • the fewer available host addresses it contains

Most Common Subnet Sizes in Practice

These are the prefixes most teams use regularly:

/24

  • 256 total IPs
  • 254 usable hosts

Very common in classic networking, but often too small for production Kubernetes clusters in shared-subnet models.

/23

  • 512 total IPs
  • 510 usable hosts

Often used as a safer starting point when /24 feels too tight.

/22

  • 1024 total IPs
  • 1022 usable hosts

A common production subnet size for Kubernetes worker nodes or application subnets with growth headroom.

/21

  • 2048 total IPs
  • 2046 usable hosts

A good fit when high pod density, multiple node pools, or future growth are likely.

/20

  • 4096 total IPs
  • 4094 usable hosts

Frequently used for larger pod ranges, GKE secondary ranges, or long-lived platform environments.


Cloud CIDR Cheat Sheet Note

Classic subnetting tables are useful, but cloud networking changes the usable count:

  • Azure reserves 5 IPs per subnet
  • AWS reserves 5 IPs per subnet
  • GCP reserves 4 IPs per subnet

That means:

  • /24 in Azure or AWS = 251 usable
  • /24 in GCP = 252 usable

This matters a lot when sizing:

  • AKS worker subnets
  • EKS node subnets
  • internal load balancer subnets
  • private endpoint or proxy-only subnets

For cloud-aware usable capacity, use:

Cloud Usable IP Calculator


CIDR Cheat Sheet for Kubernetes

CIDR sizing gets more complicated in Kubernetes because you may need to size:

  • node subnet
  • pod CIDR
  • service CIDR

And the answer changes depending on how the cluster allocates pod IPs.

Shared-subnet models

Examples:

  • AKS Azure CNI (flat)
  • EKS with AWS VPC CNI

Pods and nodes consume addresses from the same subnet.

This is why /24 frequently fails in production clusters.

Separate pod CIDR models

Examples:

  • AKS Overlay
  • Kubenet
  • ARO cluster network

Pods use a separate range, which reduces subnet pressure on the node subnet.

Secondary range models

Example:

  • GKE VPC-native

Nodes, pods, and services may all use different ranges.

This is cleaner operationally, but still requires deliberate CIDR planning.

For Kubernetes-specific sizing:


Quick Rule of Thumb

If you are choosing between common subnet sizes:

  • /24 = often too small for production Kubernetes
  • /23 = safer small production starting point
  • /22 = common practical baseline
  • /21 or larger = better for growth-heavy clusters

The exact answer still depends on:

  • max pods per node
  • autoscaler behavior
  • cloud reserved IPs
  • whether pods use the node subnet