DEV Community

Rasika Dangamuwa
Rasika Dangamuwa

Posted on

Why Subnet Calculations Fail in Cloud Deployments: 5 CIDR Traps Every Engineer Hits

#devops #cloud #networking #aws

When designing cloud infrastructure, CIDR subnetting often seems straightforward: pick a /16 VPC block, divide it into /24 subnets across availability zones, and deploy via Terraform.

Then production traffic scales, an autoscaling event triggers, and suddenly services fail to provision. Kubernetes pods hang in ContainerCreating, database instances cannot acquire network interfaces, or cross-subnet routing silently drops packets.

Subnetting in cloud environments—particularly across AWS, Azure, and container networks—involves constraints that differ from classic textbook networking. Here are five subnet calculation traps that consistently catch engineering teams off guard.

1. The Cloud Provider Reserved IP Trap

In standard RFC 791 IPv4 networking, calculating usable IP addresses for a subnet is simple: subtract 2 from the total host count ($2^{(32 - \text{prefix})} - 2$) for network identifier and broadcast. A /24 yields 254 usable IPs, a /28 yields 14, and a /29 yields 6.

However, major cloud providers do not give you $2^n - 2$ usable addresses. AWS reserves 5 IP addresses in every subnet:

  • .0: Network address.
  • .1: Reserved for the VPC router.
  • .2: Reserved for internal DNS resolution (AmazonProvidedDNS).
  • .3: Reserved for future protocol use.
  • .255: Network broadcast address.

If you provision a /28 subnet expecting 14 usable IPs, only 11 are assignable. In a /29 subnet, you receive just 3 usable IPs instead of 6. Sizing subnets without factoring in this 5-IP offset leads to immediate address exhaustion during blue/green deployments.

2. The Non-Boundary CIDR Alignment Trap

CIDR prefixes are binary bitmasks, not arbitrary numerical ranges. A frequent mistake during capacity expansion is attempting to define a range that bridges a non-power-of-two boundary.

Suppose a team exhausts 10.0.1.0/24 (256 addresses) and expands to 512 addresses. An engineer might configure 10.0.1.0/23, intending to encompass 10.0.1.0 through 10.0.2.255.

This is mathematically invalid. In binary, a /23 mask requires the least significant bit of the third octet to be 0:

10.0.1.0:       00001010.00000000.00000001.00000000
Subnet mask:    11111111.11111111.11111110.00000000
Network (AND):  00001010.00000000.00000000.00000000 -> 10.0.0.0/23
Enter fullscreen mode Exit fullscreen mode

The prefix automatically resolves to 10.0.0.0/23 (10.0.0.0 to 10.0.1.255). If infrastructure already runs in 10.0.0.0/24, applying this creates an immediate route collision.

3. Variable Length Subnet Masking (VLSM) Fragment Overlaps

When slicing a large network block (such as a /20, containing 4,096 IPs) across multiple tiers—public gateways, application services, and database clusters—teams rely on VLSM.

The trap occurs when assigning larger blocks after smaller blocks without respecting binary boundaries. For example:

  • Subnet A: 10.0.0.0/24 (10.0.0.0 – 10.0.0.255)
  • Subnet B: 10.0.1.0/25 (10.0.1.0 – 10.0.1.127)
  • Attempting Subnet C as a /24 starting at 10.0.1.128

A /24 requires a 256-boundary ending at .0. Starting a /24 at 10.0.1.128 is impossible and overlaps 10.0.2.0/24. When designing multi-AZ architectures, validating network boundaries and usable host offsets with a visual Nutilz Subnet Calculator eliminates fragmentation errors before Terraform apply runs.

4. Kubernetes CNI Pod IP Exhaustion

In clusters using native VPC networking (such as AWS VPC CNI on EKS or Azure CNI on AKS), every Pod receives an IP directly from the host node's VPC subnet.

Each EC2 instance type attaches a fixed number of Elastic Network Interfaces (ENIs), each carrying a limited number of secondary IPv4 addresses:
Max Pods = (ENIs * (IPs per ENI - 1)) + 2

Running m5.large instances (3 ENIs, 10 IPs per ENI = 29 pods/node) in a /24 subnet (251 usable IPs) means just 8 worker nodes will completely exhaust the subnet. Once exhausted, new pods fail with FailedCreatePodSandBox: failed to assign an IP address. Mitigating this requires planning secondary CIDR blocks (such as RFC 6598 100.64.0.0/10) early.

5. Wildcard Mask Inversion in Firewalls and ACLs

While cloud route tables use prefix notation, firewalls, network ACLs, and older edge routers frequently require wildcard masks (inverse masks).

For a /27 subnet, the netmask is 255.255.255.224. The wildcard mask is computed by subtracting each octet from 255: 0.0.0.31. Confusing subnet masks with wildcard masks in security rules can inadvertently permit traffic to match broad, unintended ranges.

Summary

Reliable cloud networking requires looking past basic division:

  • Subtract 5 IPs (not 2) per subnet in AWS and Azure.
  • Keep CIDR prefixes strictly aligned to binary power-of-two boundaries.
  • Separate pod CIDRs from node subnets to avoid Kubernetes provisioning deadlocks.
  • Verify host ranges, masks, and boundary offsets with tools like ipcalc or Nutilz Subnet Calculator to catch allocation issues before deploying to production.

Top comments (0)