AKS Kubenet vs Azure CNI – Terraform Comparison

Introduction

When building Azure Kubernetes Service (AKS) clusters with Terraform or OpenTofu, networking isn’t just configuration — it’s architecture.
AKS supports two main network plugins: Kubenet and Azure CNI.

Your choice between them determines how pods receive IPs, how traffic is routed, and how your cluster integrates with existing VNets.
In this post, we’ll compare AKS Kubenet vs Azure CNI, using real Terraform examples from the AKS Fundamentals with Terraform/OpenTofu series.

Kubenet and Azure CNI – the basics

Kubenet

Lightweight, default network plugin for AKS.
Pods get IPs from a separate, non-VNet address space and communicate with other resources through Source Network Address Translation (SNAT).
The translation happens at the node level, handled by the Linux iptables system.
✅ Pros: simple setup, minimal IP usage, quick to provision.
⚠️ Cons: limited VNet integration, no direct pod-level routing, scalability constrained by UDR limits (~400 routes).

Azure CNI

Each Pod receives an IP directly from the same subnet as the AKS nodes.
There’s no NAT translation — Pods become routable across the VNet just like any Azure VM.
✅ Pros: full VNet integration, hybrid and enterprise-ready, predictable routing.
⚠️ Cons: higher IP consumption and more subnet planning required.

Kubenet vs Azure CNI – technical comparison

Aspect

Kubenet

Azure CNI

Pod IP allocation

Separate CIDR (not part of VNet)

IPs from the same VNet subnet

Outbound traffic

Translated by SNAT on each node

Routed directly, no NAT

Pod visibility in VNet

Hidden behind node IP

Fully routable and discoverable

Integration with VNets

Limited

Full

Scalability limits

~400 UDR entries per route table

None (managed by Azure fabric)

Ideal for

Dev/Test, low-scale workloads

Production and hybrid setups

Complexity

Low

Moderate

This comparison highlights the architectural trade-offs between AKS Kubenet vs Azure CNI — simplicity vs full network integration.

How traffic flows under the hood

To understand the difference between Kubenet and Azure CNI, let’s look at how network packets move inside an AKS node.

Kubenet: SNAT performed by iptables

Pods receive addresses from a separate CIDR, such as 10.244.0.0/16, which is not part of the Azure VNet.
Each node has a primary IP from the VNet (e.g., 10.0.0.4).
When a Pod sends traffic outside its node, iptables performs Source NAT (SNAT) — rewriting the packet’s source from 10.244.x.x → 10.0.0.4.
As a result, Pods are not directly routable in the VNet — only node IPs are visible.

Microsoft Docs (2025):
“Pods receive an IP address from a logically different address space to the Azure virtual network subnet of the nodes. Network address translation (NAT) is then configured so the pods can reach resources on the Azure virtual network.”
— AKS Kubenet documentation

Azure CNI: native VNet routing

Each Pod receives a real IP address from the subnet (e.g., 10.10.1.5), the same range used by the AKS nodes.
Traffic from Pods is routed directly within the Azure VNet fabric — no NAT, no iptables translation.
Every Pod becomes a first-class citizen of the Azure network, routable to and from any connected subnet or peered VNet.

Microsoft Docs (2025):
“Pods get full virtual network connectivity and can be directly reached via their private IP address from connected networks.”
— AKS Azure CNI documentation

Mechanism

Kubenet

Azure CNI

Pod IP space

Separate CIDR (10.244.0.0/16)

Shared with VNet (10.10.0.0/16)

Translation

iptables performs SNAT per node

None

Pod visibility

Hidden behind node IP

Fully routable

Performance

Slight NAT overhead

Direct routing

Scalability

Limited by UDRs

Scales with Azure network fabric

💡 In short:

Kubenet = iptables performs SNAT → pods hidden.
Azure CNI = native routing → pods visible and routable.

Terraform/OpenTofu examples

Both models can be deployed using the same FoggyKitchen AKS module: terraform-az-fk-aks

You can switch from Kubenet to Azure CNI by changing one parameter.

Kubenet example

Here is a snippet of the Terraform code where we deploy an AKS cluster using the kubenet network plugin.
This configuration creates a simple, public AKS cluster — ideal for testing Terraform automation before moving to production.

module "aks" {
  source              = "github.com/foggykitchen/terraform-az-fk-aks"
  name                = "fk-aks-demo"
  create_rg           = false
  location            = azurerm_resource_group.foggykitchen_rg.location
  resource_group_name = azurerm_resource_group.foggykitchen_rg.name

  create_networking = true
  network_plugin    = "kubenet"
}

After applying this configuration, the AKS cluster is deployed using Kubenet networking:

Figure 1. AKS cluster deployed with Kubenet networking (Terraform example).

Azure CNI example

Now, let’s switch to Azure CNI.
In this setup, Pods receive IPs directly from the VNet subnet, becoming fully routable in the Azure environment.

module "aks" {
  source              = "github.com/foggykitchen/terraform-az-fk-aks"
  name                = "fk-aks-cni"
  location            = azurerm_resource_group.foggykitchen_rg.location
  resource_group_name = azurerm_resource_group.foggykitchen_rg.name

  network_plugin = "azure"
  vnet_id        = azurerm_virtual_network.foggykitchen_vnet.id
  subnet_id      = azurerm_subnet.foggykitchen_public_subnet.id

  default_node_count   = 2
  default_node_vm_size = "Standard_D2s_v3"
}

In the Azure Portal, this deployment shows Azure CNI under “Network configuration”:

Figure 2. AKS cluster integrated with existing VNet using Azure CNI.

When to choose which

🟩 Use Kubenet if:

You’re building a lightweight, non-production AKS cluster.
You have limited IP space.
You just need a quick Terraform deployment to explore AKS.

🟦 Use Azure CNI if:

You’re deploying into an enterprise VNet (hub-and-spoke or peered).
You need direct routing between Pods and other Azure or on-prem resources.
You require observability, NSG control, or hybrid readiness.

📐 Design notes

Most comparisons between Kubenet and Azure CNI focus on features and configuration.

In reality, choosing a CNI defines a network contract that shapes how your entire AKS platform behaves — long before workloads, private endpoints, or hybrid connectivity are introduced.

If you want to understand why this decision matters architecturally, watch this short Design Notes video below.

This design-level discussion complements the hands-on Terraform implementation described above.

Summary

Choosing between AKS Kubenet vs Azure CNI is not just about a Terraform variable — it’s a design choice that impacts performance, scalability, and hybrid connectivity.
By experimenting with both configurations using the FoggyKitchen AKS module, you’ll gain a deep, practical understanding of Kubernetes networking in Azure.