CIDR Notation Explained: A Visual Guide for Cloud Engineers

Why Every Cloud Engineer Needs to Understand CIDR

CIDR — Classless Inter-Domain Routing — is the foundation of IP address management in every cloud environment. When you create a VPC on AWS, a VNet on Azure, a VPC on GCP, or a VCN on OCI, the first thing you specify is a CIDR block. When you design subnets, configure security groups, set up VPN tunnels, or plan VPC peering, you work with CIDR notation. Despite its importance, CIDR notation confuses many engineers because the relationship between the prefix length, subnet mask, and available addresses is not intuitive without a clear mental model.

This guide explains CIDR from the ground up with visual examples and practical cloud use cases. By the end, you will be able to read any CIDR block, calculate the number of available addresses, determine whether two CIDR blocks overlap, and design subnet layouts for cloud VPCs with confidence. No prior networking knowledge is assumed.

IP Addresses in Binary

An IPv4 address is a 32-bit number, typically written as four decimal octets separated by dots: 192.168.1.0. Each octet represents 8 bits, and its value ranges from 0 to 255. To understand CIDR, you need to think in terms of the binary representation. The address 192.168.1.0 in binary is 11000000.10101000.00000001.00000000. The key insight is that CIDR notation divides these 32 bits into two parts: the network portion (which identifies the network) and the host portion (which identifies individual addresses within that network).

The slash notation in CIDR tells you how many bits are in the network portion. In 192.168.1.0/24, the /24 means the first 24 bits are the network identifier and the remaining 8 bits are for host addresses. Since 8 bits can represent 256 values (2^8), a /24 network contains 256 IP addresses: from 192.168.1.0 to 192.168.1.255. In 10.0.0.0/16, the first 16 bits are the network portion and the remaining 16 bits are for hosts, giving 65,536 addresses (2^16): from 10.0.0.0 to 10.0.255.255.

The Prefix Length: What the Number After the Slash Means

The prefix length determines the size of the network. A smaller prefix number means a larger network (more host addresses), and a larger prefix number means a smaller network. This is counterintuitive at first, but it follows from the binary math: the prefix length is the number of fixed bits, and the remaining bits are variable. More variable bits means more possible addresses.

Here is the practical reference table for the most common prefix lengths used in cloud networking:

• /8 — 16,777,216 addresses (e.g., 10.0.0.0/8). Used for the overall private address space of large enterprises.
• /16 — 65,536 addresses (e.g., 10.0.0.0/16 or 172.16.0.0/16). Common for VPC/VNet CIDR blocks in cloud environments.
• /20 — 4,096 addresses (e.g., 10.0.0.0/20). Common for large subnets in cloud VPCs.
• /24 — 256 addresses (e.g., 10.0.1.0/24). The most common subnet size in cloud networking. Easy to reason about.
• /28 — 16 addresses (e.g., 10.0.1.0/28). The minimum subnet size on AWS (AWS reserves 5 addresses per subnet, leaving 11 usable). Common for small subnets like NAT gateways or bastion hosts.
• /32 — 1 address (e.g., 10.0.1.5/32). Used in security group rules and routing to specify a single host.

The formula is simple: a /N network contains 2^(32-N) addresses. A /24 has 2^8 = 256 addresses. A /20 has 2^12 = 4,096 addresses. A /16 has 2^16 = 65,536 addresses.

Subnet Masks and Their Relationship to CIDR

Before CIDR notation became standard, networks were defined using subnet masks. A subnet mask is a 32-bit number where the network bits are set to 1 and the host bits are set to 0. The subnet mask for a /24 network is 255.255.255.0 (binary: 11111111.11111111.11111111.00000000). The subnet mask for a /16 is 255.255.0.0. The subnet mask for a /20 is 255.255.240.0.

CIDR notation is simply a more concise way to express the same information. The /24 prefix length and the subnet mask 255.255.255.0 are equivalent — they both say "the first 24 bits are the network portion." You will encounter subnet masks in legacy configuration files, on-premises network equipment, and occasionally in cloud provider interfaces. When you see a subnet mask, count the consecutive 1-bits from the left to get the equivalent CIDR prefix length.

Common subnet mask to CIDR conversions you should memorize: 255.0.0.0 = /8, 255.255.0.0 = /16, 255.255.240.0 = /20, 255.255.255.0 = /24, 255.255.255.240 = /28, 255.255.255.252 = /30.

Private IP Address Ranges (RFC 1918)

RFC 1918 defines three private IP address ranges that are used for internal networking and are not routable on the public internet. These are the ranges you will use for cloud VPCs:

• 10.0.0.0/8 — 16.7 million addresses. The largest private range and the most commonly used for cloud VPCs because of its size and flexibility.
• 172.16.0.0/12 — 1.05 million addresses (172.16.0.0 to 172.31.255.255). Less common but useful for avoiding conflicts with other networks that use the 10.x range.
• 192.168.0.0/16 — 65,536 addresses. Commonly used for home and small office networks. Avoid for cloud VPCs because they are likely to conflict with employee home networks when using VPN.

When choosing a CIDR block for your cloud VPC, use the 10.0.0.0/8 range and allocate non-overlapping blocks for each VPC, environment, and region. A common pattern is to use 10.{environment}.{region}.0/16, where the second and third octets encode the environment and region. This makes it easy to identify the purpose of any IP address at a glance and prevents conflicts when connecting VPCs through peering or transit gateways.

Determining If Two CIDR Blocks Overlap

CIDR overlap is one of the most common networking errors in cloud environments. Two CIDR blocks overlap if any IP address belongs to both ranges. VPC peering, transit gateway connections, and VPN tunnels require non-overlapping CIDR blocks. If you try to peer two VPCs with overlapping CIDRs, the cloud provider will reject the configuration because the routing would be ambiguous.

To check for overlap manually: determine the range of addresses in each CIDR block (first address and last address) and see if the ranges intersect. For example, 10.0.0.0/16 covers 10.0.0.0 to 10.0.255.255, and 10.0.128.0/17 covers 10.0.128.0 to 10.0.255.255. These overlap because the second range is entirely contained within the first. However, 10.0.0.0/17 (10.0.0.0 to 10.0.127.255) and 10.0.128.0/17 (10.0.128.0 to 10.0.255.255) do not overlap — they are two equal halves of 10.0.0.0/16.

A quick heuristic: if one CIDR block's prefix is shorter (larger network) and its network address is the same as or encompasses the other block's network address, they overlap. 10.0.0.0/8 overlaps with any 10.x.x.x address. When in doubt, use a CIDR overlap checker tool to verify before configuring peering or VPN connections.

Designing VPC Subnets with CIDR

A well-designed VPC subnet layout follows a consistent, predictable pattern. Start with a VPC CIDR block large enough for current and future needs. A /16 provides 65,536 addresses, which is sufficient for most workloads. If you expect to run very large Kubernetes clusters with pod networking (where each pod gets a VPC IP), consider a /14 or even a /12 to accommodate thousands of pods.

Divide the VPC CIDR into subnets by purpose and availability zone. A common pattern for a three-AZ deployment on AWS:

• Public subnets (for load balancers and NAT gateways): three /24 subnets, one per AZ (e.g., 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24)
• Private application subnets (for EC2/ECS/EKS workloads): three /20 subnets, one per AZ (e.g., 10.0.16.0/20, 10.0.32.0/20, 10.0.48.0/20)
• Private database subnets (for RDS, ElastiCache): three /24 subnets, one per AZ (e.g., 10.0.4.0/24, 10.0.5.0/24, 10.0.6.0/24)

This layout provides 251 addresses per public subnet (more than enough for load balancers and NAT gateways), 4,091 addresses per application subnet (sufficient for hundreds of instances or thousands of Kubernetes pods), and 251 addresses per database subnet (ample for database instances). The remaining address space in the /16 VPC is reserved for future use, such as additional subnet tiers for management, VPN endpoints, or new workloads.

CIDR Planning for Multi-VPC and Multi-Cloud

When your architecture spans multiple VPCs, regions, or cloud providers, CIDR planning becomes critical. Every network that might need to communicate must have a non-overlapping CIDR range. Create a central IP Address Management (IPAM) registry — even a simple spreadsheet — that records every CIDR allocation across all environments.

AWS VPC IPAM is a managed service that automates IP address planning and tracks allocations across accounts and regions. Azure provides IP address management through Virtual Network Manager. GCP and OCI do not have dedicated IPAM services, so you will need external tooling or manual tracking for those providers.

A common allocation strategy for multi-account, multi-region environments: assign a /12 to each major environment (production, staging, development), a /16 to each region within each environment, and subnet each /16 as described above. This provides a clear, predictable addressing scheme where you can determine the environment and region from any IP address: 10.0.0.0/12 for production (10.0.0.0-10.15.255.255), 10.16.0.0/12 for staging (10.16.0.0-10.31.255.255), 10.32.0.0/12 for development (10.32.0.0-10.47.255.255).

Common CIDR Mistakes in Cloud Environments

The most common CIDR mistake is using the same CIDR block for multiple VPCs that later need to be connected. Teams often default to 10.0.0.0/16 for every VPC because it is the first example in every tutorial. When they later need to set up peering, transit gateways, or VPN connections, they cannot because the CIDRs overlap. Retroactively changing a VPC CIDR is possible on some providers (AWS supports adding secondary CIDR blocks) but is disruptive and limited.

Another common mistake is making subnets too small. A /28 subnet with 11 usable addresses (after AWS reservations) can run out of addresses surprisingly quickly if you deploy an auto-scaling group or a Kubernetes node pool into it. Right-sizing a subnet after deployment is impossible on most cloud providers — you must create a new, larger subnet and migrate resources. Start with /24 as your minimum subnet size for any workload that might scale, and use /20 for workloads that will definitely scale (Kubernetes node pools, large auto-scaling groups).

Using 192.168.0.0/16 for cloud VPCs is another frequent mistake. This range is used by nearly every home router, and when employees connect to the VPN, their home network and the cloud VPC have overlapping address spaces. This causes routing ambiguity and breaks connectivity. Always use the 10.0.0.0/8 range for cloud VPCs and reserve 172.16.0.0/12 as a backup range for overflow or special-purpose networks.