How AKS Networking Works (Azure CNI, Overlay, Kubenet Explained)

How AKS Networking Works

Azure Kubernetes Service (AKS) networking is flexible — but that flexibility creates confusion.

Unlike EKS or GKE, AKS supports multiple networking models, each with different IP planning implications.

Many production issues happen because teams:

Choose the wrong networking mode
Underestimate subnet size
Misunderstand pod IP allocation
Forget Azure reserved IP behavior

This guide explains exactly how AKS networking works in 2026.

1️⃣ The Three AKS Networking Models

AKS supports three networking modes:

Azure CNI (Flat / VNet Integrated)
Azure CNI Overlay
Kubenet (Legacy / Basic)

Each model changes how Pod IPs are allocated — and how you must size subnets.

Understanding the difference is critical for safe production deployments.

Azure CNI (Flat / VNet Integrated)

2️⃣ How Azure CNI (Flat) Works

In Azure CNI flat mode:

✔ Nodes receive IPs from the Azure subnet
✔ Pods ALSO receive IPs from the SAME Azure subnet

Pods become first-class IP addresses inside the VNet.

This means:

Pods are directly routable within the VNet
Connected networks (VPN/ExpressRoute/peering) can reach pod IPs directly
NSGs and UDRs apply directly to pod IPs

But it also means:

Pods and nodes share the same subnet capacity.

3️⃣ Subnet Impact in Azure CNI (Flat)

Azure reserves 5 IP addresses per subnet (first four + last one).

In flat mode:

Total IP consumption =
(nodes) + (nodes × maxPodsPerNode)

Example:

20 nodes
30 pods per node

Total IPs needed:

20 + (20 × 30) = 620
Plus buffer
Plus 5 Azure reserved

A /24 subnet (251 usable IPs) will fail quickly.

This is the most common AKS IP exhaustion scenario.

Azure CNI Overlay

4️⃣ How Azure CNI Overlay Works

Azure CNI Overlay is now widely adopted and recommended for new clusters.

In overlay mode:

✔ Nodes use Azure subnet IPs
✔ Pods use a separate overlay CIDR range
✔ Pods do NOT consume Azure subnet IPs

Azure creates a separate routing domain for the Pod CIDR.

Pod-to-pod communication inside the cluster is direct and does not require user-managed UDRs.

However:

Pod overlay IPs are not directly reachable from the VNet
Outbound traffic from pods is SNATed to the node IP
External access must be published via Service / Load Balancer / Ingress

Overlay reduces subnet pressure — but does not make pods first-class VNet IPs.

5️⃣ Critical 2026 Detail: /24 Per Node Allocation

In Azure CNI Overlay:

Each node receives a fixed /24 slice from the Pod CIDR.
This /24 size is not dynamically reduced.
Planning must ensure enough /24 blocks exist for maximum node scale.

Example:

If Pod CIDR = /16 (65,536 IPs):

Each node consumes /24 (256 IPs)

Max nodes supported:

65,536 / 256 = 256 nodes

Even if each node runs only 50 pods, the full /24 slice is reserved per node.

This makes node-count planning extremely important in overlay mode.

6️⃣ Subnet Impact in Overlay Mode

In overlay mode:

Azure subnet capacity is consumed only by:

Nodes
Load balancers
Azure platform resources

Pods consume IPs from the overlay CIDR only.

This allows:

Smaller node subnets
Independent pod scaling
Reduced risk of Azure subnet exhaustion

Overlay is the recommended default for most new AKS clusters in 2026.

Kubenet (Legacy Mode)

7️⃣ How Kubenet Works

Kubenet:

✔ Nodes use Azure subnet IPs
✔ Pods use an overlay CIDR
✔ Outbound traffic is SNATed through node IPs

Historically:

Custom route tables (UDRs) are often required
Pods are not directly reachable from the VNet
Operational complexity is higher

Kubenet is now largely superseded by Azure CNI Overlay.

It remains available but is rarely recommended for new production clusters.

8️⃣ Comparing the Three Modes

Feature	Azure CNI (Flat)	Azure CNI Overlay	Kubenet
Pods use subnet IPs	Yes	No	No
Overlay CIDR required	No	Yes	Yes
Pods directly reachable in VNet	Yes	No (publish via Service/LB)	No
Outbound SNAT to node IP	No	Yes	Yes
Subnet pressure	High	Low	Low
Recommended in 2026	Sometimes	Yes	Rarely

9️⃣ When AKS Runs Out of IPs

Flat Mode Exhaustion

Subnet too small
High pod density
Node scaling fails
Pods fail to schedule

Overlay Mode Exhaustion

Pod CIDR too small
Not enough /24 blocks for new nodes
Autoscaler fails to add nodes

Primary Subnet Too Small (All Modes)

New nodes cannot be created
Scaling stalls
Cluster expansion blocked

🔟 Azure Reserved IP Behavior

Azure reserves 5 IP addresses per subnet.

This reduces usable IP capacity for:

Node subnets
Any delegated subnets used by AKS components

Always subtract 5 from total available subnet addresses.

1️⃣1️⃣ AKS vs EKS vs GKE Networking

Provider	Pod IP Model	Subnet Pressure
AKS Flat	Pods use VNet IPs	High
AKS Overlay	Pods use overlay CIDR	Low
EKS	Pods use VPC IPs	High
GKE	Pods use secondary range	Moderate

AKS is unique because you can choose your networking model.

That flexibility increases planning responsibility.

1️⃣2️⃣ Best Practices for Production AKS (2026)

Prefer Azure CNI Overlay for new clusters.
Use flat mode only if direct VNet-reachable pod IPs are required.
Allocate a sufficiently large Pod CIDR (consider /16 for production).
Plan overlay CIDR based on maximum node count × /24 slices.
Add 25–30% growth buffer.
Avoid /24 flat subnets with high pod density.

Example Production Layout (Overlay)

Primary subnet: 10.0.0.0/22
Pod overlay CIDR: 10.240.0.0/16

This allows:

Up to 256 nodes (due to /24 per node)
Thousands of pods
Clean separation of scaling domains

Use the AKS Subnet Calculator

To safely plan your cluster:

→ AKS Subnet Calculator

It calculates:

Required node subnet size
Required Pod CIDR size
Growth buffer impact
Azure reserved IP adjustments

Final Thoughts

AKS networking is powerful — but misunderstood.

If you understand:

Flat vs overlay behavior
/24 per node allocation in overlay
Azure reserved IP math
Pod CIDR scaling

…you understand AKS networking.

And that understanding prevents the most common Azure Kubernetes scaling failures.

Want to understand how this compares to other Kubernetes providers?

→ Kubernetes Networking Comparison Guide