adaptive.run TECH BLOG

Since that announcement, a recurring question has come up again and again: what does this actually mean if you’re running AKS? Many teams are unsure how serious the situation is, which alternatives are valid, and how quickly they need to react.

That uncertainty makes sense. Searching for “NGINX ingress on AKS” surfaces several overlapping solutions: Microsoft’s Application Routing add-on, the upstream Ingress NGINX project, and newer offerings like Application Gateway for Containers. It’s not obvious which component is being deprecated, which ones Microsoft actively supports, or what the long-term migration path looks like.

To cut through the noise, I spent several weeks deploying and testing the main options in development clusters to understand the practical trade-offs.

If you’re currently using Ingress NGINX on AKS, you’re facing more than a simple controller swap. You’re really deciding what your ingress architecture should look like over the next few years. Fortunately, the timing isn’t all bad. The ecosystem has evolved significantly. ModSecurity, which many of us paired with NGINX for WAF functionality, is effectively in maintenance mode, while Coraza has emerged as a modern replacement. At the same time, the Gateway API has clearly positioned itself as the long-term successor to the Ingress API. Between Azure-managed services and increasingly mature open-source projects, there are more viable paths forward than most teams realize.

While there are many ingress controllers in the Kubernetes ecosystem (Istio, Kong, HAProxy, and others), only a handful make sense specifically for AKS when you factor in Azure integration, maturity, cost, and Gateway API support.

• Application Gateway for Containers (AGC) – Microsoft’s managed Gateway API offering with integrated WAF

• Application Routing add-on – A managed NGINX-based controller with Azure-native integrations (Gateway API support planned for H1 2026)

• Envoy Gateway – An open-source, vendor-neutral Gateway API implementation

• Traefik Proxy v3 – A user-friendly ingress and Gateway API controller with lighter WAF maturity

Each option represents a different balance of operational effort, cost, and long-term alignment with Kubernetes networking direction.

AGC is Microsoft’s modern replacement for the legacy Application Gateway Ingress Controller. It is purpose-built for AKS and supports the Gateway API from day one.

AGC offers native support for both the Gateway API and the traditional Ingress API, backed by Azure-managed infrastructure. It includes an Azure WAF with OWASP rule sets, autoscaling, and high throughput. Although the data plane lives in Azure, it integrates tightly with AKS through the Application Load Balancer (ALB) Controller, which runs in the cluster and can be deployed via Helm or as an AKS add-on (currently in preview).

For a basic deployment without WAF, the monthly cost lands around $136, covering the AGC resource, frontend, association, and minimal capacity units. Enabling WAF roughly doubles that number to about $245 per month.

For teams accustomed to running NGINX with a standard Azure load balancer and public IP—typically around $25–30 per month—this is a substantial increase.

AGC currently supports only public endpoints; private frontends are expected but not until early 2026. Each ALB Controller is tied to a single AKS cluster and requires its own managed identity, which means AGC instances can’t easily be shared across clusters. Running multiple ALB Controllers in a single cluster is also unsupported.

AGC works well for organizations that are deeply invested in Azure, have the budget for managed services, and want minimal operational involvement. The developer experience is smooth: define Gateway resources in Kubernetes, and Azure infrastructure is provisioned and updated automatically.

However, there’s an important caveat. If you already rely on Azure Front Door or Application Gateway for WAF and global routing in front of NGINX, AGC doesn’t replace those services—it duplicates them. Several teams I spoke with already pay for Front Door, and adding AGC would mean an extra $245 per cluster for overlapping functionality.

This becomes especially painful in multi-cluster environments. Five clusters quickly turn into over $1,200 per month just for ingress. For many teams, that cost is hard to justify when open-source alternatives exist.

________________________________________

The Application Routing add-on is Microsoft’s managed implementation of the familiar NGINX ingress controller. Functionally, it behaves much like a self-managed NGINX deployment, but Microsoft handles lifecycle management and updates.

It supports the Ingress API, works with existing NGINX-style configurations, and integrates with Azure services like Key Vault (via the Secrets Store CSI Driver) and optionally Azure DNS. Pricing stays roughly in line with self-managed NGINX, since you’re still only paying for standard load balancer infrastructure.

Gateway API support is not available yet, though Microsoft has announced plans to add it in the first half of 2026, powered by the Istio control plane. The add-on restricts certain NGINX configuration options for security reasons: you can’t modify the ingress-nginx ConfigMap, and several snippet annotations are blocked. It also requires the AKS cluster to use managed identities and limits Azure DNS integration to five zones.

If you need the lowest-risk migration away from self-managed NGINX and can’t overhaul your ingress strategy immediately, this is the most straightforward option. In testing, most existing Ingress manifests worked with little to no modification, aside from changing the ingressClassName to webapprouting.kubernetes.azure.com.

Microsoft takes care of updates, and certificate management via Key Vault is seamless if you choose to use it. You can still rely on cert-manager or other tools if preferred. While you’re temporarily locked into the Ingress API, the announced Gateway API roadmap is realistic for most teams’ timelines.

For WAF protection, you can continue using Azure Front Door or Application Gateway exactly as you do today. One thing to watch for: several snippet annotations are blocked (load_module, lua_*, proxy_pass, location, and others). If your configuration relies heavily on these, you’ll need alternatives—or you’ll need to stay self-managed for now.

________________________________________

Envoy Gateway represents the modern, open-source path forward. It’s the CNCF’s reference implementation of the Gateway API and runs equally well on Azure or any other Kubernetes platform.

Envoy Gateway supports the Gateway API natively and is completely vendor-neutral. For WAF needs, you can either integrate with Azure Front Door or Application Gateway, or deploy Coraza, a Go-based, actively maintained WAF that replaces ModSecurity. Infrastructure costs remain similar to NGINX deployments, as you’re still using standard Azure load balancers.

This is a self-managed solution. You’re responsible for upgrades, security patches, CVE monitoring, and (if using Coraza) WAF rule management. Initial setup is more complex than managed offerings, and support comes from the community rather than a commercial SLA.

If Gateway API support is a priority, you want to avoid cloud lock-in, and your team has platform engineering capacity, Envoy Gateway is an excellent long-term investment. The Gateway API model is more expressive and cleaner than Ingress, especially with its separation of infrastructure (Gateway) and routing (HTTPRoute), which simplifies RBAC and multi-team ownership.

Coraza integrates with Envoy using a WebAssembly-based extension designed specifically for this purpose. It supports OWASP CRS v4 and uses Kubernetes-native YAML configuration rather than Apache-style directives. Tuning rules still takes time, but anyone familiar with ModSecurity will recognize the workflow.

The downside is operational overhead. For teams without dedicated platform engineers, this can be burdensome. In those cases, Application Routing may be a better interim solution.

________________________________________

Traefik has been a popular cloud-native ingress controller for years and is well known for its usability and documentation. Version 3 introduced full Gateway API support, making it an attractive migration option from NGINX.

Traefik supports both Ingress and Gateway APIs, offers automatic service discovery, includes a polished web dashboard, and provides built-in observability features like metrics, tracing, and access logs. Infrastructure costs are comparable to NGINX.

Advanced WAF functionality is part of Traefik’s commercial offering (Traefik Hub). In open source deployments, WAF requires external plugins such as Coraza-Traefik, which are less mature than Envoy’s integration. Like Envoy Gateway, Traefik requires you to manage upgrades and security yourself.

Traefik is appealing if ease of use and developer experience are top priorities, and WAF requirements are minimal or handled externally. The project offers clear migration documentation and tooling to help teams move from NGINX. For environments where WAF enforcement is critical, Envoy combined with Coraza is currently more robust.

________________________________________

Teams still using ModSecurity should be aware that ModSecurity v3 is no longer actively evolving. Coraza has effectively taken its place as the modern, maintained alternative. It’s compatible with existing ModSecurity rules and OWASP CRS and integrates cleanly with Envoy via WebAssembly.

If you’ve managed ModSecurity before, Coraza’s approach will feel familiar, just more Kubernetes-native.

When helping teams evaluate their options, I focus on a few key questions:

• Do you actually need WAF at the ingress layer, and is it already provided by Azure Front Door or Application Gateway?

• How many AKS clusters are in scope, and how does per-cluster pricing affect you?

• Does your team have the capacity to run self-managed infrastructure?

• Is Gateway API adoption urgent, or can it wait until 2026?

• How complex are your existing NGINX configurations and custom snippets?

________________________________________

If I were migrating a production AKS environment today, I’d approach it in two phases.

Enable the Application Routing add-on and migrate off self-managed NGINX with minimal disruption. Run it alongside your existing controller initially, shift traffic gradually, and validate certificate handling, DNS integration, and any custom configuration. This approach minimizes risk and buys time.

Plan a move to Envoy Gateway once you’re ready to adopt the Gateway API fully. Run both controllers in parallel during the transition, observe traffic behavior, and migrate incrementally. For WAF, either keep using Azure Front Door/Application Gateway or introduce Coraza in detection mode before enforcing blocking rules.

This staged approach avoids the common pitfall of trying to replace the ingress controller, API model, and WAF all at once—a strategy that often leads to outages.

The deprecation of Ingress NGINX on AKS isn’t just a forced migration—it’s a chance to realign with where Kubernetes networking is headed. Gateway API is clearly the future, and there are now credible paths to get there.

If you need stability and speed, the Application Routing add-on is the safest move. If you’re investing in the long term, Envoy Gateway is the most future-proof option. Traefik is compelling for teams that value simplicity. And if cost isn’t a concern and you want Azure to manage everything, AGC delivers that experience.

The key is to start planning now. March 2026 will arrive faster than it seems.