Choose a Cloud Subnet CIDR by Usable IPs, Not Address Count

A /26 contains 64 IPv4 addresses. That does not mean a cloud subnet can assign 64 addresses to workloads, and even the familiar answer of 62 usable hosts can be too high.

This matters when a subnet is close to capacity. Consider a hypothetical deployment that needs addresses for 50 network interfaces today. The team chooses a 20% planning margin, so its design target is 60 addresses. A conventional CIDR calculation says that a /26 has 62 usable host addresses. In an AWS or Azure subnet, however, five addresses are unavailable, leaving 59. The same /26 therefore misses the target by one address.

This guide shows how to separate CIDR block size from provider-assignable capacity, reproduce the numbers, and choose between /26 and /25 without pretending that one percentage is right for every system.

Start with the two numbers a CIDR prefix can tell you

IPv4 has 32 bits. If the prefix length is p, the number of addresses in the block is:

total addresses = 2^(32 - p)

RFC 4632 defines CIDR prefix notation and lists /26 as 64 addresses and /25 as 128. The prefix describes the block; it does not encode a particular cloud provider's reservations or a managed service's capacity rules.

Open the Calquio CIDR Calculator and enter 26. It reports:

The calculator's 62 follows the traditional IPv4 subnet convention: subtract the network and broadcast addresses. That is useful as a protocol-level baseline. For cloud planning, add a second step:

provider-assignable capacity = total addresses - provider-reserved addresses

The calculator cannot know whether the planned block is an AWS VPC subnet, an Azure VNet subnet, a Google Cloud primary range, a secondary range, or a special service subnet. Treat its “usable hosts” result as a baseline, not a provider quota.

Apply the provider's reservation rule

The current first-party documentation produces three different capacities for the same /26 primary subnet:

AWS documents that the first four and last IPv4 addresses are unavailable. Azure likewise reserves the first four and the last address. Google Cloud marks the first two and last two addresses of a primary IPv4 range unusable.

These rules are not interchangeable. Google Cloud says that all addresses in a secondary IPv4 range can be used, while the four-address rule applies to the primary range. AWS also documents a BYOIP exception. A service such as a managed firewall, gateway, or Kubernetes offering can impose another minimum size or consume addresses through scaling. Check the documentation for the exact subnet and service type, not merely the provider name.

Work the 50-address example

Suppose the hypothetical inventory is 50 addresses:

• 36 application network interfaces
• 8 worker or build interfaces
• 4 internal endpoints
• 2 operational addresses

The categories are illustrative; they are not a recommended architecture. What matters is that every item that receives an address is counted once.

The team chooses a 20% margin:

planning target = ceil(50 × 1.20) = 60

Now compare prefixes:

For AWS or Azure, /26 fails because 64 - 5 = 59, which is less than 60. /25 passes because 128 - 5 = 123.

For a Google Cloud primary range, /26 reaches 60 exactly because 64 - 4 = 60. “Exactly” is a warning rather than comfort: the 20% margin is completely consumed at the design target. If the inventory omitted a load balancer interface, a temporary replacement during a rolling update, or another address-consuming resource, allocation could fail. Choosing /25 may be reasonable when the surrounding address plan can afford it.

The reverse mistake is also possible. Automatically choosing /24 “for safety” allocates 256 addresses before reservations. Across many environments and tiers, that can fragment private address space and make future non-overlapping connections harder. The useful choice is the smallest provider-valid block that covers documented demand and an explicit margin—not the smallest mathematical block and not an unexamined oversized default.

Test sensitivity before choosing the prefix

A planning margin is a decision input, not a sourced universal constant. Test several demand levels to see where the power-of-two boundary changes the answer:

One additional address can cause a jump from /26 to /25, doubling the block from 64 to 128 addresses. That is not rounding error; CIDR sizes are powers of two. Record why the larger block was selected so that a later reviewer can distinguish planned headroom from accidental waste.

Also model temporary peaks rather than only steady state. A rolling replacement can briefly require old and new interfaces at the same time. Autoscaling, private endpoints, load balancer front ends, and managed-service control components may consume addresses differently. Use the service's current documentation to turn those behaviors into inventory rows.

Use a provider-aware decision checklist

Before reserving a subnet, write down:

1. Range type: provider, IPv4 range type, and whether it is primary, secondary, BYOIP, or service-dedicated.
2. Current demand: every interface, endpoint, node, and service address expected at steady state.
3. Peak demand: deployment overlap, failover, and maximum autoscaling—not just today's instance count.
4. Planning margin: the chosen percentage or fixed count and the reason for it.
5. Provider subtraction: total block addresses minus the reservations documented for that exact range type.
6. Service minimums: any prefix constraints or dedicated-subnet requirements imposed by the service.
7. Address-plan fit: overlap checks against VPCs, VNets, on-premises networks, peers, and VPN-connected ranges.

Then use the CIDR calculator to verify the prefix's total addresses and subnet mask. Keep the provider subtraction beside the calculator result in the design record. That small annotation prevents “62 usable” from silently becoming an AWS or Azure capacity promise.

Limits of this calculation

This method sizes IPv4 address capacity; it does not design routing, security boundaries, availability-zone layout, IPv6, or Kubernetes Pod ranges. A larger subnet is not automatically more reliable or secure. Provider rules and service requirements can change, and some range types have explicit exceptions.

The worked inventory and 20% margin are hypothetical. Replace both with observed demand, documented scaling behavior, and your organization's recovery requirements. Finally, verify the chosen CIDR against the current provider and service documentation before deployment.

Sources

• RFC 4632: Classless Inter-domain Routing (CIDR) — IETF Best Current Practice, August 2006; accessed July 29, 2026.
• AWS: Subnet CIDR blocks — current VPC reservation and subnet-size documentation; the page does not state a revision date; accessed July 29, 2026.
• Microsoft Azure: Virtual networks and subnets — updated June 22, 2026; accessed July 29, 2026.
• Google Cloud: Subnets — updated July 27, 2026 UTC; accessed July 29, 2026.