Ingress NGINX Is Retiring in March 2026: What This Means for AKS Users

Reading Time: 10 minutes

Whilst at KubeCon Atlanta, the Kubernetes project announced something significant: Ingress NGINX is being retired in March 2026. The project is winding down the controller due to insufficient maintainership and mounting technical debt. Since the announcement, I’ve been asked by a lot of people what this means for AKS users specifically. There’s been quite a bit of confusion around what to do, which options make sense, and how urgently you need to act.

The confusion is understandable. If you search for “NGINX ingress AKS,” you’ll find Microsoft’s Application Routing add-on, the open source Ingress NGINX project, and references to Application Gateway for Containers. It’s not immediately clear what’s retiring, what Microsoft supports, and what the upgrade path looks like. I spent the last few weeks testing each option in dev clusters to understand the real trade-offs.

If you’re running Ingress NGINX on AKS, you’ve got a decision to make. Not just about replacing the controller, but about where you want your ingress strategy to be in the next few years. The timing is actually useful because the ecosystem has matured significantly. ModSecurity (the WAF most of us paired with NGINX) is effectively in maintenance mode now, with Coraza emerging as the modern replacement. The Kubernetes Gateway API has become the successor to Ingress. Between Azure’s managed offerings and the matured open source alternatives, there are more paths forward than you might expect.

Let me walk you through what I found, including cost breakdowns and the gotchas I hit along the way.

The Four Realistic Options

I know there are other ingress controllers out there (Istio, Kong, HAProxy, and more), but after testing and researching, these are the four options that make the most sense for AKS users specifically. They balance maturity, cost, Azure integration, and Gateway API support.

After filtering out the noise, there are four options worth considering:

1. Application Gateway for Containers (AGC) – Azure’s managed Gateway API solution with built-in WAF
2. Application Routing Add-on – Managed NGINX with Azure integrations, Gateway API support coming H1 2026
3. Envoy Gateway – Open source Gateway API implementation (use Coraza WAF or existing Azure WAF)
4. Traefik Proxy v3 – Easy-to-use Gateway API controller with less mature WAF integration

Each has different trade-offs around cost, complexity, and future-proofing.

Option 1: Application Gateway for Containers (AGC)

This is Microsoft’s official successor to the legacy Application Gateway Ingress Controller (AGIC). It’s built specifically for AKS and supports Gateway API natively.

What it gives you:

• Gateway API and Ingress API support out of the box
• Azure-managed WAF with OWASP rules
• Auto-scaling and high performance
• Azure-hosted but integrated with AKS (managed by the Application Load Balancer Controller in your cluster)
• ALB Controller (Application Load Balancer Controller) deployable via Helm or AKS addon (preview)

What it costs:

Without WAF, you’re looking at ~$136/month for basic setup (AGC resource + frontend + association + minimal capacity units).

With WAF enabled, costs jump to ~$245/month as all pricing meters roughly double.

If you’re used to NGINX costing you $25-30/month (just a load balancer and public IP), this is a significant jump.

Important limitations:

One of the biggest limitations of AGC is it only supports public frontends (internet-facing endpoints) right now, though private frontend support is expected in early 2026. Beyond that, each ALB Controller requires its own unique managed identity and is tied to a single cluster. You can’t easily share one AGC instance across multiple clusters. Multiple ALB Controllers on the same cluster aren’t recommended or supported.

When it makes sense:

If your company is all-in on Azure, you have budget, and you want “set and forget” managed infrastructure, AGC is solid. The integration is genuinely nice. You define a Gateway resource in Kubernetes, and the ALB Controller provisions the Azure resources automatically. Updates happen without you touching the Azure portal.

But here’s the catch. If you’re already using Azure Front Door or Application Gateway with your NGINX ingress for WAF protection, AGC might duplicate those costs rather than replace them. I’ve spoken with several teams running Front Door for global load balancing and WAF, and adding AGC on top would mean paying $245/month per cluster for overlapping capabilities. You’d essentially be paying twice for similar features.

The other consideration is multi-cluster scenarios. Each cluster needs its own ALB Controller with a unique managed identity. If you’re running 5+ clusters, that’s $1,200+/month just for ingress infrastructure. For most teams I’ve worked with, the cost is hard to justify when open source alternatives exist at a fraction of the price.

Option 2: Application Routing Add-on (Managed NGINX)

This is Azure’s managed version of NGINX ingress controller. It’s essentially the same NGINX you’re running now, but Microsoft manages the lifecycle and updates.

What it gives you:

• Familiar NGINX configuration
• Azure Key Vault integration for certificates (managed feature using Secrets Store CSI Driver)
• Azure DNS integration (optional)
• Ingress API support (your current manifests mostly work)
• Same cost structure as self-managed NGINX (~$25-30/month)

Important limitations:

Only supports Ingress API currently (no Gateway API support). However, Microsoft has announced that Gateway API support (powered by Istio control plane) is planned for H1 2026. Limited to five Azure DNS zones. Can’t edit the ingress-nginx ConfigMap. Certain NGINX snippet annotations are blocked for security. Requires AKS cluster with managed identity.

When it makes sense:

If you can’t migrate away from NGINX-style ingress quickly and need the lowest-risk path forward, this is it. I tested the migration from self-managed NGINX to Application Routing, and most of my Ingress manifests worked without changes. The biggest adjustment was updating the ingressClassName to webapprouting.kubernetes.azure.com.

The nice part is Microsoft handles updates and integrates with Azure DNS if you need it. For certificates, the add-on’s managed integration uses Azure Key Vault via the Secrets Store CSI Driver. That said, since it’s still NGINX under the hood, you can use other certificate solutions like cert-manager if needed, though you won’t get the same level of Azure integration. The downside is you’re locked to Ingress API until H1 2026 when Gateway API support arrives. But realistically, that timeline works for most teams. You get stability now and a future Gateway API path without changing platforms again.

For WAF protection, you can continue using your existing Azure Front Door or Application Gateway setup, just as you likely do with your current NGINX deployment. This keeps your security architecture unchanged while you migrate the ingress controller itself.

One gotcha I hit. The addon blocks specific snippet annotations for security reasons, including load_module, lua_package, _by_lua, location, root, proxy_pass, serviceaccount, and several special characters ({, }, '). If you’re using these in your current NGINX configs, you’ll need to find alternative approaches or stick with self-managed NGINX.

Option 3: Envoy Gateway

This is the modern open source option. Envoy Gateway is the CNCF’s reference implementation of the Gateway API. For WAF protection, you can either deploy Coraza (a modern, actively maintained alternative to ModSecurity) or integrate with your existing Azure Front Door or Application Gateway.

What it gives you:

• Native Gateway API support
• Vendor-neutral (runs anywhere, not just Azure)
• Optional Coraza WAF (open source, actively maintained, OWASP CRS v4 compatible)
• Can integrate with existing Azure Front Door or Application Gateway for WAF
• Same cost as NGINX (~$25-30/month for load balancer and IP)

Important limitations:

Self-managed, so you own the operational overhead. If using Coraza, responsible for WAF rule tuning, updates, and security patches. More complex initial setup compared to managed options. Relies on community support rather than commercial SLA.

When it makes sense:

If you want Gateway API support, don’t want Azure vendor lock-in, and have the engineering capacity to manage it, this is the path forward. I deployed Envoy Gateway in a dev cluster, and once you understand the Gateway API model, it’s cleaner than Ingress. HTTPRoute resources are more expressive than Ingress objects, and the separation between infrastructure (Gateway) and routing (HTTPRoute) makes RBAC easier.

For WAF, you have two paths. If you already have Azure Front Door or Application Gateway, keep using them. If you want a self-managed WAF, Coraza integrates via the coraza-proxy-wasm extension (a WebAssembly plugin designed specifically for Envoy). The OWASP CRS rules work similarly to ModSecurity, and the configuration is YAML-based rather than Apache-style directives, which feels more Kubernetes-native. Rule tuning takes time, but if you’ve managed ModSecurity before, you’ll recognize the patterns.

The operational overhead is real though. You’re responsible for CVE monitoring and version upgrades for Envoy Gateway itself. If you deploy Coraza, add WAF rule tuning to that list. There’s no support SLA, just community forums and GitHub issues. For teams with dedicated platform engineering, this is manageable. For smaller teams, Application Routing might be more practical.

Option 4: Traefik Proxy v3

Traefik is a modern cloud-native ingress controller and edge router that’s been around since 2015. It’s known for its ease of use, automatic service discovery, and excellent documentation. Traefik v3 added full Gateway API support and has positioned itself as one of the easier migration paths from NGINX.

What it gives you:

• Gateway API and Ingress API support
• Easy to configure with excellent web dashboard
• Automatic service discovery and dynamic configuration
• Built-in observability (metrics, tracing, access logs)
• Same cost as NGINX (~$25-30/month for load balancer and IP)

Important limitations:

Traefik’s built-in WAF capabilities are commercial-only (Traefik Hub). The open source version requires external plugins like Coraza-Traefik, which are less mature than the Envoy integration. For production WAF needs, you’ll likely want to pair with Azure Front Door or Application Gateway. Like Envoy Gateway, you’re responsible for the operational overhead of managing upgrades, monitoring CVEs, and maintaining the deployment.

When it makes sense:

If ease of use is your top priority and you’re okay with external WAF or don’t need it at all, Traefik is worth considering. The dashboard and automatic service discovery make it approachable for teams new to Gateway API. Traefik provides official migration documentation at doc.traefik.io/traefik/migrate/nginx-to-traefik and a dedicated migration site at ingressnginxmigration.org to help with the transition. But for WAF-heavy workloads, Envoy + Coraza is more battle-tested.

About ModSecurity and Coraza

If you’re running ModSecurity today, here’s something important. ModSecurity v3 is effectively in maintenance mode. The industry has shifted to Coraza, which is a Go-based WAF that’s compatible with ModSecurity rules (including OWASP CRS).

Coraza runs as a WebAssembly plugin on Envoy, which means it integrates cleanly with Envoy Gateway. It’s actively maintained by OWASP and has a growing community. If you were comfortable managing ModSecurity rules, Coraza will feel familiar.

Planning Your Migration

Before picking an option, here are the questions I’ve been asking teams:

Do you need WAF capabilities? If you’re already using Azure Front Door or Application Gateway for WAF, adding AGC creates cost duplication. Consider whether you can consolidate or if Application Routing + external WAF makes more sense.

How many clusters are you running? The per-cluster cost model matters. AGC at $245/month per cluster adds up fast. Open source options scale linearly with just load balancer costs.

What’s your team’s operational capacity? Managed options (AGC, Application Routing) reduce operational overhead but increase costs and lock you into Azure’s release schedule. Self-managed options (Envoy, Traefik) give you control but require maintenance bandwidth.

Do you need Gateway API now or can you wait? If Gateway API is critical for your architecture (policy management, multi-team routing), AGC or Envoy Gateway are your options. If you can wait until H1 2026, Application Routing will support it.

How complex are your current NGINX configs? Heavy use of NGINX snippets or custom modules might not translate cleanly to managed options. Test your configurations thoroughly.

What I’d Recommend

Here’s the approach I’d take if I were migrating a production cluster:

Why not the other options?

Before diving into the recommendation, let me explain why I’m not leading with AGC or Traefik. Application Gateway for Containers is excellent if you have the budget and want Azure to manage everything, but at $245/month per cluster with WAF (or $136 without), it’s expensive for most teams. If you’re already using Azure Front Door or Application Gateway for WAF, AGC duplicates that cost rather than replacing it. Traefik is solid for ease of use, but Envoy Gateway is the CNCF’s reference implementation of Gateway API and has more mature WAF integration options. For production workloads, Envoy’s battle-tested track record gives you more confidence.

Phase 1: Short-term (before March 2026)

Deploy the Application Routing add-on. Enable it on your cluster with:

Update your Ingress resources to use ingressClassName: webapprouting.kubernetes.azure.com. Deploy alongside your existing NGINX controller initially. Route a small percentage of traffic to test behavior. This is your lowest-risk path and gives you breathing room.

Key things to test:

• Certificate management (Key Vault integration works well)
• DNS integration if you’re using Azure DNS zones
• Any custom NGINX configurations, especially snippet annotations
• Load balancer behavior (internal vs external)

Your existing Ingress manifests will mostly work with minimal changes. This buys you time to plan the next phase without rushing.

Phase 2: Long-term

Migrate to Envoy Gateway. This sets you up with Gateway API and keeps you vendor-neutral. The Gateway API model is cleaner:

Run both controllers in parallel during the transition. Route traffic gradually to Envoy Gateway. Monitor error rates, latency, and WAF rule matches. Once you’re confident, deprecate the Application Routing add-on.

For WAF protection, you have two options. If you already have Azure Front Door or Application Gateway providing WAF, keep using them. If you want a self-managed WAF inside your cluster, deploy Coraza via the coraza-proxy-wasm extension. Coraza configuration is done via SecurityPolicy custom resources. Start with OWASP CRS in detection mode, tune based on your traffic, then switch to blocking mode.

Why this two-phase approach?

Because trying to do everything at once (migrate from NGINX, adopt Gateway API, and switch WAF solutions) is a recipe for problems. I’ve seen teams try to do a big-bang migration and end up with production incidents.

Phase 1 is your safety net. It keeps your costs low, gives you managed infrastructure, and buys time to learn Gateway API properly. Phase 2 is your strategic investment. By the time you migrate, you’ll have hands-on experience with Gateway API concepts, and Application Routing’s Gateway API support might even be available as a third option.

Cost Comparison

Here’s what you’re looking at in terms of monthly Azure costs:

• Current NGINX + ModSecurity: ~$25-30/month (load balancer + public IP)
• Application Routing add-on: ~$25-30/month (same infrastructure)
• Envoy Gateway: ~$25-30/month (same infrastructure)
• Application Gateway for Containers: ~$125-150/month base + capacity unit charges (doubles with WAF)

If budget is a concern (and it usually is), the managed services route with AGC is expensive. The open source options keep your costs similar to what you have now.

Next Steps

Here’s what I’d do this week:

1. Audit your current setupDocument your NGINX configurations, custom annotations, and WAF rules. Identify what’s custom vs standard.
2. Test in devSpin up a dev cluster and deploy Application Routing add-on. Migrate a sample application and validate traffic flow, TLS termination, and any Key Vault integrations.
3. Review costsCalculate your current infrastructure costs (load balancers, IPs, Front Door/App Gateway if applicable). Compare against AGC pricing for your cluster count.
4. Plan Gateway API learningEven if you stick with Ingress API short-term, start learning Gateway API concepts. The model is different but more powerful. Try the Envoy Gateway quickstart in a local cluster.
5. Convert existing Ingress manifestsUse the ingress2gateway tool to preview how your current Ingress resources would translate to Gateway API. This Kubernetes SIG-Network tool supports NGINX Ingress and can help identify any conversion issues early. Install it with brew install ingress2gateway or go install github.com/kubernetes-sigs/ingress2gateway@latest, then run ingress2gateway print --providers=ingress-nginx against your cluster.
6. Check WAF requirementsIf you’re running ModSecurity, start investigating Coraza. The rule syntax is compatible, but deployment is different. Test OWASP CRS v4 in detection mode to see what triggers in your traffic. Alternatively, if you already have Azure Front Door or Application Gateway providing WAF protection, you can continue using those with Envoy Gateway or any ingress controller, eliminating the need to deploy and manage Coraza entirely.

The March 2026 deadline is closer than it seems. Start planning now rather than scrambling at the last minute.

Final Thoughts

The retirement of NGINX ingress on AKS isn’t just about replacing a controller. It’s an opportunity to think about where Kubernetes ingress is headed. Gateway API is the future, and you have real choices. Whether you want managed infrastructure from Azure, self-managed open source controllers, or to stick with NGINX temporarily while you plan, every option has a sensible use case.

If you need to move fast, go with Application Routing add-on. If you want to invest in the future, start planning your move to Envoy Gateway. Traefik is solid if ease of use is your priority. For WAF, remember you can continue using Azure Front Door or Application Gateway with any of these controllers, or deploy Coraza with Envoy Gateway if you want a self-managed in-cluster WAF. And if budget isn’t a constraint and you want Azure to handle everything, Application Gateway for Containers is solid.

What path are you taking? I’d be curious to hear what other teams are doing. Reach out if you hit any interesting gotchas or find better approaches than what I’ve covered here.