Why Azure CNI Runs Out of IPs (AKS Explained)

IP exhaustion is one of the most common scaling issues in Azure Kubernetes Service (AKS) when using Azure CNI (flat mode).

Clusters deploy successfully — then weeks or months later:

  • Node scaling fails
  • Pods remain in Pending
  • Upgrades break
  • New node pools cannot be created

The root cause is almost always the same:

The subnet was too small.

This article explains why Azure CNI consumes IP addresses aggressively, how subnet math works in AKS, and how to prevent IP exhaustion before it happens.

How Azure CNI Allocates IP Addresses

When using Azure CNI (flat mode):

  • Each node gets an IP from the Azure subnet
  • Each pod also gets an IP from the same subnet
  • Azure automatically reserves 5 IP addresses per subnet

Unlike overlay networking, pods receive real, routable VNet IPs.

That means your subnet must support:

Nodes

  • (Nodes × MaxPodsPerNode)
  • Growth buffer
  • 5 Azure reserved IPs

This grows much faster than most teams expect.

Why a /24 Subnet Often Fails

Let’s walk through a realistic example.

Scenario

  • 10 nodes
  • Max pods per node: 30 (default Azure CNI)
  • Subnet: /24 (256 total IPs)
  • Azure reserves 5 IPs

Usable IPs:

256 - 5 = 251 usable IPs Nodes: 10 Pods: 10 × 30 = 300 Total: 310

A /24 cannot support this cluster.

Even before scaling.

This is why many AKS deployments start with /24 and later experience failures during growth.

Why It Breaks Later (Not Immediately)

Subnet exhaustion often appears months after deployment because:

  • Initial pod usage is low
  • Autoscaling hasn’t fully triggered
  • Additional node pools are added
  • Workloads grow
  • Blue/green deployments require temporary extra capacity

By the time the problem appears, remediation is disruptive.

The maxPods Multiplier

Every AKS node has a maxPods setting.

Default Azure CNI value:

  • Usually 30

But many teams increase it to:

  • 50
  • 100
  • or higher

Subnet sizing must account for the maximum possible pods, not average usage.

Example:

20 nodes × 50 pods = 1,000 pod IPs

Even a /22 (1,024 total IPs) becomes tight once:

  • Azure reserved IPs
  • Node IPs
  • Growth buffer

are included.

Azure Reserved IP Impact

Azure reserves 5 IP addresses per subnet:

  • Network address
  • Default gateway
  • DNS
  • Azure infrastructure
  • Broadcast-equivalent

These are not usable.

In small CIDR ranges like /24 or /25, those 5 IPs significantly reduce available capacity.

Always subtract them before calculating usable space.

Correct Way to Size an AKS Subnet

When using Azure CNI (flat mode):

1️⃣ Calculate planned node count

Include:

  • Current nodes
  • Expected growth
  • Additional node pools

2️⃣ Calculate pod IP requirement

plannedNodes × maxPods

3️⃣ Add growth buffer (20–30%)

total × 1.25 (for 25% buffer)

4️⃣ Add node IPs

Nodes also consume subnet IPs.

5️⃣ Add Azure reserved IPs (5)

Only then determine the smallest CIDR prefix that satisfies total usable capacity.

To simplify this process, use:

→ AKS Subnet Planner

It accounts for:

  • Node count
  • maxPods
  • Growth buffer
  • Azure reserved IP impact

When Azure CNI Overlay Is a Better Option

If VNet address space is limited, consider Azure CNI Overlay.

In overlay mode:

  • Nodes consume Azure subnet IPs
  • Pods use a separate overlay CIDR
  • Pods do NOT consume VNet IPs

This dramatically reduces subnet pressure.

Overlay is often preferred when:

  • Corporate IP allocation is constrained
  • Large pod density is required
  • Multiple clusters share a VNet

Overlay eliminates most pod-related IP exhaustion risks.

Common Symptoms of IP Exhaustion

If your subnet is too small, you may see:

  • Node pool scale-out failures
  • Pods stuck in Pending
  • Cluster autoscaler errors
  • Upgrade failures
  • Azure reporting subnet capacity exhaustion

Fixing it typically requires:

  • New subnet creation
  • Node pool recreation
  • Cluster migration

Preventing the issue is far easier than fixing it.

Enterprise Design Considerations

Subnet sizing in enterprise Azure environments should also consider:

  • Hub-spoke VNet architecture
  • Peered VNet address overlap
  • Private endpoint IP usage
  • Future cluster expansion
  • Blue/green deployment requirements

Choosing the next larger CIDR block early is usually safer than selecting the smallest possible range.

Summary

Azure CNI runs out of IPs because:

  • Pods consume real Azure subnet IPs
  • maxPods multiplies subnet requirements
  • Azure reserves 5 IPs per subnet
  • Growth is underestimated

The most common mistake is deploying with /24 in Azure CNI flat mode.

Before deploying your next AKS cluster, validate your subnet size using:

→ AKS Subnet Planner

Correct CIDR planning prevents scaling failures, upgrade issues, and costly redesign later.

For other kubernetes clusters look here: