On this page · 12 sections
- What Microsoft shipped, and what the launch note claims
- The sample command creates an end-of-life cluster
- The limitations that decide it for you
- The iptables blocker is a one-way door for the cluster
- What upstream Cilium says that Microsoft does not
- What it costs
- India-specific considerations
- What to do this week
- What is still unknown
- FAQ
- How eCorpIT can help
- References
Summary. Microsoft marked eBPF host routing in Advanced Container Networking Services (ACNS) for Azure Kubernetes Service generally available at 18:36 UTC on 24 August 2026, and the launch note says the new enablement experience "respects existing network connections during rollout". The Microsoft Learn page that tells you how to turn it on, last updated 29 May 2026, carries a Note that reads "Enabling eBPF Host Routing on an existing cluster may disrupt existing connections." The same page requires Kubernetes 1.33 or later and its copy-paste az aks create sample pins --kubernetes-version 1.33, a version AKS lists as end of life in July 2026. ACNS is billed at $0.025 per node per hour under the meter "Standard Node", which is $18.25 per node per month and $1,825 per month on a 100-node cluster. Five bullet points of documented limitations decide whether you can enable it at all, and none appear in the launch note.
What Microsoft shipped, and what the launch note claims
The GA entry is Azure update 569873, created and last modified 24 August 2026 at 18:36:01 UTC, status "Launched". It describes eBPF host routing as moving packet forwarding and routing decisions into the Linux kernel, bypassing iptables processing in the host network namespace, and it points at a single link, aka.ms/acns/ebpfhostrouting.
Two sentences in that note are doing the work that matters to anyone already running production traffic:
This release also introduces an enhanced enablement experience that respects existing network connections during rollout. When eBPF Host Routing is enabled on an existing cluster, AKS performs a controlled node rotation to transition nodes to the new networking mode, helping maintain connection continuity and minimize disruption to running applications.
Follow the link and it resolves to the eBPF host routing overview, which carries a "Last updated on 2026-05-29" stamp. Its Considerations section describes the same rolling upgrade, phrased as respecting existing connections "through node drain timeout". So far, consistent.
The enable page, also stamped 29 May 2026, is where it breaks. Directly above the az aks update command you are meant to run on an existing cluster sits a Note: "Enabling eBPF Host Routing on an existing cluster may disrupt existing connections." Three months after that stamp, the GA announcement says the opposite, and neither page was re-dated on launch day.
| Question | GA note, 24 Aug 2026 | Enable page, last updated 29 May 2026 |
|---|---|---|
| Existing connections during enablement | "respects existing network connections during rollout" | "may disrupt existing connections" |
| Mechanism described | "controlled node rotation" | az aks update --acns-datapath-acceleration-mode BpfVeth |
| Minimum Kubernetes version | not stated | 1.33 or later |
| Minimum Azure CLI version | not stated | 2.71.0 or later |
| Supported node OS | not stated | Azure Linux 3.0 or Ubuntu 24.04 |
| Required dataplane | not stated | Azure CNI powered by Cilium |
| Cost | "Learn more" link only | not stated on the page |
The sample command creates an end-of-life cluster
The enable page's az aks create block sets --kubernetes-version 1.33 alongside --network-dataplane cilium, --enable-acns and --acns-datapath-acceleration-mode BpfVeth. Run it unchanged on 24 August 2026 and you are asking for a Kubernetes minor that AKS's own supported versions page, last updated 5 August 2026, records as GA in June 2025 with an end of life of July 2026. That page also shows 1.36 GA in June 2026 and 1.37 due GA in October 2026, so the pinned sample is three minors behind the current GA line and already outside community support unless you have long-term support enabled, where 1.33 runs to July 2027.
The requirement itself is the more useful number. Anything below 1.33 cannot take eBPF host routing at all, which rules out clusters still on 1.32, whose standard end of life was March 2026.
The limitations that decide it for you
The overview page lists constraints the launch note does not mention. Read them before you plan the rollout, because most are structural rather than temporary.
| Limitation | What it rules out | Practical read |
|---|---|---|
| Node OS must be Ubuntu 24.04 or Azure Linux 3.0 | Every other node image | Ubuntu 22.04 and Azure Linux 2.0 pools need replacing first |
| Cluster-wide only | Hybrid node scenarios | You cannot pilot it on one node pool |
| No Windows nodes | Windows workloads | Azure CNI powered by Cilium is Linux only |
| No Confidential VMs, no Pod Sandboxing | Isolated tenancy patterns | Regulated workloads on CVM SKUs are excluded |
| Incompatible with Static Egress Gateway | Fixed source IP egress | Firewall allowlists keyed to gateway IPs break the plan |
| Istio Ambient via self-managed install with ACNS Performance mode | Self-managed Istio Ambient | Service mesh teams need to check this first |
The Static Egress Gateway clash is worth its own line, because the incompatibility is declared in only one direction. The Static Egress Gateway configuration page was updated more recently, on 7 August 2026, lists seven limitations of its own, requires Azure CLI 2.75.0 or later, and mentions eBPF, ACNS and host routing zero times. A team that starts from the egress side gets no warning at all.
The iptables blocker is a one-way door for the cluster
Two components ship with the feature. An init container called the iptables blocker prevents future installation of iptables rules in the host network namespace. The IP masquerade agent keeps running so behaviour stays consistent if you later disable the feature, but its iptables rules are ignored while eBPF host routing is active, because Cilium takes over SNAT with BPF-based masquerading.
The overview's warning about that blocker is blunt: AKS blocks attempts to install iptables rules in the host network namespace, and "Trying to bypass this block may cause the cluster to be inoperational." Any agent that writes host-namespace iptables rules, security tooling included, has to be audited before you flip the switch. AKS tries to detect existing host-namespace iptables rules and block enablement, but detection is not a guarantee.
Nodes that have completed the transition carry the label kubernetes.azure.com/ebpf-host-routing=true, which is the only cheap way to check rollout progress across a large pool.
What upstream Cilium says that Microsoft does not
Azure CNI powered by Cilium is Cilium, and AKS 1.36 ships cilium-agent v1.18.9-260508 per the supported versions page. Upstream Cilium tuning documentation records that BPF host routing landed in Cilium 1.9, requires both eBPF-based kube-proxy replacement and eBPF-based masquerading, and is enabled automatically when the kernel supports it.
Two upstream notes do not appear in the AKS pages. First, Cilium states plainly that "BPF Host Routing is incompatible with Istio", citing GitHub issue 36022. Microsoft's limitation is narrower, covering self-managed Istio Ambient with ACNS Performance mode, so a team running sidecar Istio reads the AKS page as a green light and the Cilium page as a red one. Second, upstream describes packets no longer hitting netfilter tables in the host namespace as incompatible with anything relying on netfilter hooks, and offers bpf.hostLegacyRouting=true as the escape hatch. On AKS you do not get that knob. Your only lever is --acns-datapath-acceleration-mode None, which turns the feature off for the whole cluster.
Cilium also gives you a verification step the AKS pages omit: run cilium status in a Cilium pod and confirm the "Host Routing" line reads "BPF".
What it costs
The launch note links to pricing without quoting a rate, so take it from the Azure Retail Prices API, which returns the meter directly. Product "Advanced Container Networking Services", SKU "Standard", meter "Standard Node", type Consumption, price $0.025 per 1 hour, region Global, effective from 1 June 2025. Global means the same rate applies in Central India and South India as in West Europe.
The per-hour figure hides the annual one. At 730 hours a month and 8,760 hours a year:
| Nodes | ACNS per month | ACNS per year |
|---|---|---|
| 10 | $182.50 | $2,190 |
| 25 | $456.25 | $5,475 |
| 50 | $912.50 | $10,950 |
| 100 | $1,825.00 | $21,900 |
| 250 | $4,562.50 | $54,750 |
That is the ACNS bill on top of node compute, and it buys the whole suite rather than eBPF host routing alone. The real cost is usually the node image migration, not the flag.
India-specific considerations
Because the ACNS meter is priced Global, Indian teams see no regional discount on the $0.025 per node hour. The constraint that bites harder locally is the Static Egress Gateway exclusion. Teams serving regulated Indian counterparties often pin outbound traffic to fixed IP prefixes for partner and bank firewall allowlists, and Static Egress Gateway is the AKS-native way to do that. Choosing eBPF host routing gives that up cluster-wide, so the decision belongs with whoever owns the allowlist, not only with the platform team. Where personal data flows through those egress paths, the audit trail you keep under the Digital Personal Data Protection Act 2023 should record the change of egress IP behaviour, not just the performance gain.
What to do this week
Check three things before you plan anything. Run az version and confirm 2.71.0 or later. Check your cluster's Kubernetes minor against 1.33, and do not copy the sample's --kubernetes-version 1.33 into a new cluster. List your node pools' OS SKUs and confirm every one is Ubuntu2404 or AzureLinux, because the feature is cluster-wide and one stray pool blocks it.
Then decide on the disruption question by treating the enable page as authoritative, since it is the page that describes the command you will actually run. Schedule the az aks update inside a maintenance window with pod disruption budgets and node drain timeouts set deliberately, and watch the kubernetes.azure.com/ebpf-host-routing=true label spread. If your platform runs Static Egress Gateway, sidecar Istio, Confidential VMs or Pod Sandboxing, the answer is no for now and no amount of scheduling changes that.
What is still unknown
Microsoft has not re-dated either eBPF host routing page since 29 May 2026, so it is not possible to tell from the documentation whether the "enhanced enablement experience" is a new code path that supersedes the disruption note or a restatement of the existing node drain behaviour. No published benchmark accompanies the GA note either. The overview claims lower pod-to-pod latency, higher throughput and a modest CPU reduction, and points at no numbers of its own, while upstream Cilium's TCP_STREAM comparison between "Cilium" and "Cilium (legacy host-routing)" is the only quantified reference either side offers.
FAQ
How eCorpIT can help
Our senior engineering teams run AKS upgrade and networking migrations where the constraint is rarely the flag itself. Node image replacement, egress IP allowlists and service mesh compatibility are what set the timeline. We assess the cluster against the documented ACNS requirements, model the per-node cost, and sequence node pool rebuilds so the change lands inside a maintenance window. Our DevOps and cloud operations practice covers the whole path, and adjacent work on Kubernetes 1.36 upgrade breaking changes, containerd 2.0 migration in Kubernetes 1.35 and edge Kubernetes on bare metal sits in the same cluster of decisions. eCorpIT is CMMI Level 5, MSME Certified and ISO 27001:2022 certified. Book an AKS networking review if you need the compatibility matrix checked against your own node pools.
References
Last updated: 24 August 2026.
