Running high throughput or low latency distributed systems on Kubernetes often hits an unexpected bottleneck inside the Linux kernel network stack. Microsoft has officially announced the general availability of eBPF Host Routing within Advanced Container Networking Services (ACNS) for Azure Kubernetes Service (AKS). This release fundamentally transforms how network packets move between pods and nodes across Azure infrastructure.
The overhead of traditional iptables and socket traversal
In standard Linux container networking environments, every incoming and outgoing packet traverses multiple layers of the kernel networking stack. When a container transmits data across the virtual network, the packet passes from the container network namespace through a virtual ethernet (veth) pair into the host network namespace. From there, it gets processed by Netfilter hooks, traverses complex iptables rules for connection tracking (conntrack) and network address translation (NAT), and finally moves out through the physical network interface card (NIC).
While this architecture provided flexibility in early container implementations, the overhead becomes noticeable at scale. Connection tracking tables consume memory and introduce locking contention under millions of concurrent connections. Deep packet traversal through the kernel protocol stack increases CPU utilization, taking compute cycles away from user applications and introducing jitter in latency-sensitive services like distributed AI model training, real-time streaming, and high-frequency transaction databases.
How eBPF host routing bypasses the network stack
Extended Berkeley Packet Filter (eBPF) allows safe, sandboxed programs to run directly inside the Linux kernel in response to specific events. In Azure CNI Powered by Cilium, eBPF programs attach directly to the network interface at the Traffic Control (tc) and eXpress Data Path (XDP) layers.
With eBPF Host Routing enabled in ACNS, packet forwarding decisions move directly to the host network layer. When a packet arrives on the network interface, eBPF programs evaluate destination routing and pod endpoints directly within kernel space without passing the packet through the upper socket layers, iptables chains, or conntrack tables. The packet gets redirected immediately to the target pod’s veth interface or egress NIC.
This shortcut eliminates unnecessary context switches and buffer allocations. Internal benchmarks shared by Microsoft demonstrate significant performance gains, showing up to a 43 percent improvement in networking throughput and measurable latency reductions for packet-intensive workloads.
Benchmarking and real-world performance gains
In high density container clusters, the performance gap between legacy Netfilter routing and eBPF datapath acceleration becomes pronounced across several distinct dimensions:
- Raw throughput improvement: For network-heavy applications handling large message payloads, bypassing Netfilter avoids multiple memory copies and CPU socket queue traversals, pushing throughput closer to wire speed.
- Drastic latency reduction: Processing packets directly at the XDP and tc layers eliminates connection tracking lookups, cutting tail latencies (p99) significantly across inter-pod microservice calls.
- Reduced CPU overhead: Relieving the host CPU from evaluating lengthy iptables chains frees up compute capacity for application containers, directly translating to infrastructure cost savings in large-scale AKS deployments.
Architectural trade-offs and operational caveats
Because eBPF Host Routing bypasses traditional host-level iptables processing, it is not enabled by default. Platform engineers must understand the operational trade-offs before rolling it out across production clusters:
- Bypassing custom host iptables: Any custom security policies, logging rules, or audit hooks implemented via raw iptables on the host node will not see the bypassed traffic.
- Cilium policy enforcement: Network security policies must be defined and enforced using native Kubernetes NetworkPolicy or Cilium Network Policy objects, which execute directly within the eBPF datapath.
- ACNS enablement: The feature requires clusters running Azure CNI Powered by Cilium with the Advanced Container Networking Services extension enabled.
Enabling eBPF host routing on AKS
You can enable eBPF host routing on an existing or newly provisioned AKS cluster configured with Azure CNI Powered by Cilium through the Azure CLI or Infrastructure as Code templates. To enable ACNS and host routing via Azure CLI:
az aks update \
--resource-group rg-production-k8s \
--name aks-core-cluster \
--enable-acns \
--enable-ebpf-host-routing trueYou can verify that the eBPF routing rules are active on cluster nodes by inspecting the Cilium agent endpoint status and examining BPF maps on the host nodes via the Azure CLI diagnostic extensions:
kubectl get nodes -o wide
az aks nodepool show --cluster-name aks-core-cluster --resource-group rg-production-k8s --name nodepool1Practical considerations for migration
When transitioning existing AKS clusters to eBPF Host Routing, plan an orderly validation phase. Verify that third-party observability agents (such as Prometheus node-exporter network monitors or APM tools) rely on socket or interface metrics rather than parsing Netfilter counters. Test pod-to-pod and pod-to-external communication thoroughly in a staging cluster to ensure custom egress NAT gateways and route tables remain consistent.
What this means for cloud architecture
As cloud architectures incorporate larger containerized workloads – from real-time analytics engines to AI inference pipelines – network virtualization overhead increasingly dictates cluster efficiency. By shifting routing logic from static netfilter tables into dynamic eBPF programs, AKS delivers bare-metal packet performance without sacrificing the multi-tenant isolation guarantees of managed Kubernetes.