AKS App Routing NGINX Support Ends Nov 2026: Migrating to Gateway API on AKS

Microsoft supports critical security patches for the AKS application routing add-on with NGINX only through November 2026. If your AKS clusters route traffic through the webapprouting.kubernetes.azure.com IngressClass, you need to be on another supported implementation by then. The default successor is the application routing Gateway API implementation, and the safe way to get there is a parallel run plus a DNS cutover.

This deadline exists because the upstream kubernetes/ingress-nginx project ended maintenance in March 2026 and its repository was archived. Microsoft extended patch support for its managed add-on to give customers a runway. That runway ends next month. For the upstream side of the story and a controller-agnostic checklist, see our sister post on kubernetes.ae: ingress-nginx Is Unpatched: A Gateway API Migration Checklist.

Who is affected by the November 2026 AKS deadline?

Microsoft’s migration guidance splits AKS users into three groups:

• Application routing add-on users (managed NGINX): supported through November 2026, then you must have moved. This is the group the deadline is about.
• Self-installed OSS ingress-nginx users: already unpatched upstream since March 2026. Microsoft suggests moving to the managed add-on as a short bridge, but with November this close, going straight to a Gateway API implementation saves a second migration.
• Teams needing mesh features or advanced ingress: Gateway API on the Istio service mesh add-on is the recommended route.

Not sure which group you are in? Check three things on each cluster. Does the cluster have the application routing add-on enabled with an NGINX controller (look for the nginx Service in the app-routing-system namespace)? Do any Ingress objects use the webapprouting.kubernetes.azure.com class? And is there a separately installed ingress-nginx Helm release in another namespace? It is easy to end up with both a managed and a self-installed controller, each serving different hostnames, and both need a plan.

Also note the direction of travel. From AKS 1.36, new AKS Automatic clusters use Gateway API via the application routing add-on by default. Gateway API is the platform default on AKS now, not an option.

What are your Gateway API options on AKS?

Two constraints catch people out with the app routing Gateway API implementation:

• It cannot run alongside the Istio service mesh add-on. You must disable one before enabling the other, and leftover istio.io CRDs from a disabled mesh add-on stop the app routing control plane from starting until you delete them.
• It requires the Managed Gateway API CRDs. Self-managed Gateway API CRDs are not supported with the add-on, so if you installed them yourself, plan for that change.

How do you migrate from app routing NGINX to Gateway API on AKS?

Microsoft’s own guide is solid. Here is the condensed version with the bits we see teams skip.

1. Inventory every Ingress on the add-on’s class. Filter on ingressClassName: webapprouting.kubernetes.azure.com, export hosts, paths, TLS and annotations, and note anything pinned to the NGINX IP: Front Door origins, Traffic Manager endpoints, firewall and partner allow lists.
2. Lower DNS TTLs to 60 seconds and wait out the old TTL before going further.
3. Enable the new data plane next to the old one. Use Azure CLI 2.86.0 or later, enable the Managed Gateway API CRDs, then the app routing Istio implementation. ingress-nginx keeps serving throughout. Confirm istiod is ready in aks-istio-system and the approuting-istio GatewayClass is accepted.
4. Translate Ingress to Gateway and HTTPRoute. Use ingress2gateway for the bulk conversion and review its output by hand. Keep one Gateway per team or domain boundary rather than one giant shared object.
5. Set up TLS before DNS moves. Today the supported path for Key Vault certificates is the Secrets Store CSI driver syncing into a Kubernetes Secret referenced by the listener. Microsoft says a native Key Vault integration is in development.
6. Validate against the Gateway IP directly with curl --resolve for every host and path, real certificates, POST bodies, auth flows, and long-lived connections such as WebSockets and gRPC. Run it under sustained load for several minutes and watch for 5xx and flapping route conditions.
7. Cut over in waves. Point DNS and upstream origins at the Gateway IP, lowest-risk hostnames first, and watch the NGINX request rate drop to zero.
8. Clean up last. Only after a stable observation window, stop the add-on reconciling the default NGINX controller and delete the NginxIngressController resources. Until you do, rollback is just a DNS change.

For a detailed parity testing approach, including replaying real traffic against both data planes, see Gateway API Migration: How to Test It Before You Cut Over on kubernetes.qa.

What NGINX features will you lose, and what do you do about them?

The app routing Gateway API implementation is deliberately narrow. Map your annotations before you commit:

• Body size limits, header size limits, rate limiting: not available. Options are the Istio service mesh add-on with a gateway-scoped EnvoyFilter, Application Gateway for Containers, or enforcing limits upstream in Azure Front Door or a WAF.
• NGINX snippets and Lua: no equivalent anywhere in Gateway API. Rewrite the behaviour as a standard filter, a policy on another implementation, or move it into the application.
• Custom access log formats: Envoy access logs are on by default, but you cannot customise format or provider through the Istio Telemetry API on this implementation.
• Egress control: out of scope. Use Azure Firewall or network policy instead.

Most standard routing, redirects, rewrites, header changes and weighted canaries map cleanly to Gateway API fields. It is the long tail that needs decisions, so find it in week one, not the night before cutover.

What about UAE data residency and regulated workloads?

The migration does not change where your data lives. The Gateway proxies run inside your AKS cluster, so clusters in UAE North or UAE Central keep traffic in-region exactly as before. What does change is your evidence trail: if your compliance documentation names ingress-nginx as the ingress component, update it, and record the new component’s patching ownership. Moving from an unpatched controller to a Microsoft-managed one is a control improvement worth writing down for your auditors.

The bottom line

AKS app routing NGINX support ends in November 2026, and an unpatched internet-facing proxy is not something to carry into 2027. For most teams the application routing Gateway API implementation is the right default. Teams that depend on rate limiting or size limits should test the Istio add-on or Application Gateway for Containers first. Either way, it is a parallel run and a DNS cutover, not a flag flip.

If you would rather not spend November on this, our AKS migration sprint is a fixed-scope engagement: ingress inventory, annotation mapping, Gateway API build-out with TLS, parity testing and a staged cutover with a rehearsed rollback, delivered for a known scope agreed up front. Book a free 30-minute scoping call and we will tell you which AKS option fits your annotations.