The CIDR Notation Cheat Sheet Every Network Admin Should Bookmark

CIDR notation shows up everywhere in networking — from configuring a home router’s subnet to defining a cloud VPC’s address space — yet the slash number at the end of an IP address (like the /24 in 192.168.1.0/24) trips up even experienced administrators when they’re working outside their usual range of familiar values. This article breaks down exactly how CIDR notation works and why, gives you a complete printable-style cheat sheet covering every prefix length, compares how the same slash notation applies differently to IPv6, points you to a tool for quick calculations, and walks through how CIDR planning actually plays out when sizing subnets in AWS, Azure, or GCP.

How CIDR Notation Actually Works

CIDR (Classless Inter-Domain Routing) notation is a shorthand way of expressing an IP address along with its subnet mask, using a single number after a slash instead of writing out the full mask separately.

1. The slash number represents bits, not a mask directly. In 192.168.1.0/24, the /24 means the first 24 bits of the 32-bit IPv4 address are fixed as the “network” portion, while the remaining bits are available for individual host addresses on that network.
2. A subnet mask is really just those same bits expressed differently. Converting /24 into a traditional subnet mask means setting the first 24 bits to 1 and the rest to 0: 11111111.11111111.11111111.00000000, which translates to the familiar 255.255.255.0.
3. Fewer network bits mean more available host addresses. A /24 reserves 24 bits for the network, leaving 8 bits (2⁸ = 256 total addresses) for hosts. A /16, by contrast, reserves only 16 bits for the network, leaving 16 bits (2¹⁶ = 65,536 total addresses) for hosts — a smaller slash number always means a larger network.
4. Two addresses in every subnet are reserved, not usable by hosts. The very first address in a range is the network address (identifying the subnet itself), and the very last is the broadcast address (used to send data to every device on that subnet at once) — which is why usable host counts are always the total address count minus 2, for any subnet size larger than a /31.
5. CIDR notation replaced the older classful system for a reason. Before CIDR, networks were assigned in fixed-size blocks (Class A, B, or C), which wasted enormous amounts of address space. CIDR allows a network to be sized to exactly what’s needed — a /27 for a small branch office, a /22 for a larger headquarters — rather than being forced into one of three rigid sizes.

With the underlying logic in place — fewer network bits reserved means more hosts available — the actual values for every possible prefix length are worth having on hand as a single reference, which is exactly what the chart below provides.

Full CIDR Notation Cheat Sheet: Prefix, Subnet Mask, and Host Counts

CIDR    Subnet Mask          Total Addresses     Usable Hosts
/1      128.0.0.0            2,147,483,648       2,147,483,646
/2      192.0.0.0            1,073,741,824       1,073,741,822
/4      240.0.0.0            268,435,456         268,435,454
/8      255.0.0.0            16,777,216          16,777,214
/9      255.128.0.0          8,388,608           8,388,606
/10     255.192.0.0          4,194,304           4,194,302
/12     255.240.0.0          1,048,576           1,048,574
/16     255.255.0.0          65,536              65,534
/17     255.255.128.0        32,768              32,766
/18     255.255.192.0        16,384              16,382
/19     255.255.224.0        8,192               8,190
/20     255.255.240.0        4,096               4,094
/21     255.255.248.0        2,048               2,046
/22     255.255.252.0        1,024               1,022
/23     255.255.254.0        512                 510
/24     255.255.255.0        256                 254
/25     255.255.255.128      128                 126
/26     255.255.255.192      64                  62
/27     255.255.255.224      32                  30
/28     255.255.255.240      16                  14
/29     255.255.255.248      8                   6
/30     255.255.255.252      4                   2
/31     255.255.255.254      2                   0 (point-to-point link, no usable hosts by traditional rule)
/32     255.255.255.255      1                   1 (single host route)

This chart covers the ranges most commonly referenced in day-to-day networking; every prefix length from /1 to /32 follows the same doubling/halving pattern shown above — each step down in usable hosts corresponds to exactly one more bit reserved for the network portion, and vice versa.

IPv4 vs. IPv6 CIDR Notation: Key Differences

The same slash notation is used for IPv6 addresses, but because IPv6 addresses are 128 bits long rather than 32, the numbers involved — and the typical prefix lengths used in practice — look quite different.

Why does IPv6 standardize so heavily around /64? Unlike IPv4, where administrators carefully size a subnet to match expected host count (as shown in the cheat sheet above) due to address scarcity, IPv6’s address space is so vast that a /64 subnet — containing roughly 18 quintillion addresses — is used almost universally regardless of how many devices will actually be on it, since there’s no practical benefit to conserving IPv6 address space the way there is with IPv4.

Quick Answers: Using an Online CIDR Calculator

Manually working through the cheat sheet and bit math above is useful for understanding the logic, but for a fast, error-free result — especially with an unusual or unfamiliar prefix — an online CIDR calculator is often the more practical choice.

What does a CIDR calculator actually do? Enter an IP address and CIDR prefix (like 10.20.30.0/22), and the tool instantly returns the subnet mask, the network address, the broadcast address, the first and last usable host addresses, and the total number of usable hosts — everything covered manually in the earlier sections, calculated automatically.

Can these tools work in reverse, converting an IP range into a CIDR block? Yes — many calculators also support entering a starting and ending IP address and returning the smallest CIDR block (or set of blocks) that covers that exact range, which is useful when documenting an existing network whose boundaries you already know but whose CIDR notation you don’t.

Are these calculators accurate for both IPv4 and IPv6? Most modern CIDR calculators support both, though it’s worth confirming a specific tool explicitly handles IPv6’s 128-bit addressing and larger prefix range (as detailed in the comparison above) rather than being built for IPv4 only.

When is a calculator more useful than the cheat sheet above? The cheat sheet is fastest for quickly recalling standard values you already have memorized or nearly memorized; a calculator becomes more valuable when working with a specific, real IP address and needing the exact network and broadcast addresses for that address rather than just the general host-count pattern.

Understanding both the manual math and having a calculator on hand covers most day-to-day subnetting tasks — but CIDR planning takes on an additional layer of practical consideration once you move into sizing address blocks for cloud infrastructure.

CIDR Notation Best Practices for AWS, Azure, and GCP VPCs

Setting up a Virtual Private Cloud (VPC) requires choosing a CIDR block up front, and getting the sizing right matters more in the cloud than on a traditional local network, since resizing later is often disruptive or impossible without significant rework.

1. Choose a VPC CIDR block larger than you think you’ll need. A common recommendation is starting with a /16 for the overall VPC (65,536 addresses, as shown in the cheat sheet earlier), even if current needs are modest — this leaves substantial room for future subnets without needing to recreate the VPC entirely.
2. Use private IP ranges reserved for internal networking. Cloud VPCs are built using the same RFC 1918 private ranges used in traditional on-premises networking (such as 10.0.0.0/8 or 172.16.0.0/12), since a VPC’s address space isn’t meant to be directly exposed to the public internet.
3. Divide the VPC into smaller subnets by availability zone and purpose. Within your /16 VPC block, typical practice is carving out /24 subnets (256 addresses each, as shown in the cheat sheet) for each availability zone and tier — for example, a separate /24 for public-facing web servers and another for private database instances in each zone.
4. Avoid overlapping CIDR ranges across VPCs you may need to connect. If there’s any chance two VPCs will later be connected via peering, a VPN, or a Transit Gateway/Virtual WAN, using non-overlapping CIDR blocks from the start avoids a painful re-addressing project later — this is one of the most common cloud networking mistakes.
5. Reserve some subnet ranges for future expansion. Rather than allocating every /24 in your /16 block immediately, leave gaps in your numbering scheme (for example, skipping from 10.0.1.0/24 to 10.0.10.0/24 for a new zone) so you can insert additional subnets later without renumbering existing ones.
6. Account for cloud-provider-reserved addresses within each subnet. AWS, for instance, reserves 5 addresses in every subnet for internal networking purposes (beyond the standard network and broadcast addresses covered earlier in this article), meaning a /24 subnet in AWS provides 251 usable addresses rather than the 254 shown in the general cheat sheet — a detail worth accounting for specifically when sizing cloud subnets, even though the underlying CIDR math is identical to any other network.
7. Match subnet size to actual workload, not convenience. While /24 is a common default, resource-heavy tiers (such as an auto-scaling group expected to grow significantly) may warrant a larger /22 or /23 subnet, while small, fixed-purpose tiers (like a NAT gateway subnet) can often use a much smaller /28 without issue.

The core math behind all of these recommendations is exactly the same CIDR logic covered throughout this article — the cloud-specific considerations are really about planning ahead for scale and avoiding future conflicts, not a different subnetting system.

Between understanding the underlying bit math, having the full prefix-to-host-count chart on hand, knowing how IPv6 changes the typical numbers involved, using a calculator for quick real-world lookups, and applying all of it to cloud VPC planning, this cheat sheet and the reasoning behind it should cover the vast majority of CIDR notation questions you’ll run into in day-to-day networking work.

Please follow and like us: