Azure Architecture Blog

9 MIN READ

From Ingress to Gateway API: A pragmatic path forward (and why it matters now)

Microsoft

Jan 28, 2026

If you operate Kubernetes at scale, you've felt it: "Ingress YAML sprawl", annotation archaeology, and the creeping sense that your edge configuration is one upstream change away from becoming fragile. Over the last couple of years, the Kubernetes networking community has been steadily moving toward a clearer, more expressive model for north-south traffic management: Gateway API.

That shift has accelerated recently for a very practical reason: Ingress NGINX (the community ingress-nginx controller) is on a retirement timeline. For many teams, that controller wasn't a "nice to have" - it was the default ingress path. Now, you have to make two decisions in short order:

Pick a proxy / gateway implementation that you can run confidently for years.
Learn Gateway API (or at least build a migration plan toward it).

This post addresses both challenges constructively, without turning it into a "rip-and-replace" story. The goal is to help you make the shift to Gateway API with a clear plan, and to show how Azure Application Gateway for Containers can serve as a stable landing zone for teams seeking an Azure-native path forward.

Why the community is moving: Gateway API is the new center of gravity

The original Kubernetes Ingress API did one job well: provide a basic, portable way to route HTTP/S to services. Over time, real-world production needs outgrew what a single resource plus controller-specific annotations could express. The Kubernetes community designed Gateway API to address those gaps.

The change is more than "Ingress but newer." Gateway API splits responsibilities across multiple resources so it's easier to reason about ownership, multi-tenancy, and safe delegation:

GatewayClass: the "provider" of gateway capability.
Gateway: the actual entry point (listeners, addresses, TLS).
HTTPRoute / TCPRoute / GRPCRoute: app-owned routing rules attached to gateways.

That separation matches how most organizations actually operate: platform teams manage shared ingress infrastructure, while application teams manage routes.

The ingress-nginx project maintainers have made this shift explicit. Their README now states: "If you are not already using ingress-nginx, you should not be deploying it... Instead you should identify a Gateway API implementation and use it." The broader Kubernetes networking community has rallied around Gateway API for its richer features, cleaner extensibility model, and explicit role separation.

The catalyst: Ingress NGINX retirement forces a decision

The Kubernetes SIG Network and the Security Response Committee announced the retirement plan for the Ingress NGINX project, with best-effort maintenance until March 2026, after which there are no further releases or security updates.

This is about the community "ingress-nginx" controller project, but it's worth noting that the Ingress API itself is also frozen - no new features will be added as Gateway API is the intended successor.
Your clusters may keep routing traffic after retirement, but you'll be running an unmaintained edge component.

For Azure Kubernetes Service (AKS) customers, Microsoft has also published guidance: if you're using the AKS Application Routing add-on with NGINX to manage Ingress NGINX resources, official support for the current NGINX Ingress will remain until November 2026 (critical security patches only during that period), after which the future direction will focus on Gateway API.

The practical implication: you now have a clear timeline to act, and the ecosystem is aligned on Gateway API as the future.

The two challenges (and why they're intertwined)

When you hear "migrate from ingress-nginx," you might be thinking about two different projects:

Challenge 1: Picking a proxy

Ingress NGINX had a simple value proposition: "install it and route traffic." But it also became a catch-all for features via annotations - rewrites, headers, canary, auth, rate limits, mTLS, and more.

When choosing your next proxy/gateway, you now have to weigh:

Support model: community vs. vendor-backed vs. managed service.
Operational burden: patching cadence, upgrades, incident response.
Ecosystem integration: observability, identity, policy, security tooling.
Feature parity: what's native vs. what requires extensions.

Challenge 2: Learning Gateway API

Even if you keep the same data plane technology, moving to Gateway API changes how you model traffic:

You'll think in Gateways and Routes, not just "an Ingress per app."
You'll formalize who owns TLS and listeners vs. who owns routing rules.
You'll reduce "annotation magic," which is good - but it's still a learning curve.

In other words: the proxy choice and the API choice are linked. You want to avoid migrating twice.

A practical approach to both challenges

Treat the gateway layer as a platform capability

If you're currently running Ingress NGINX or Application Gateway Ingress Controller (AGIC), now is the time to start planning your migration. Both rely on the Ingress API, which is frozen, and the ingress-nginx controller is heading toward end-of-life.

Instead of coupling your applications tightly to a specific ingress implementation, consider treating the gateway layer as a platform-managed capability. With Gateway API, teams can express routing intent as standard resources, while the platform handles lifecycle and operational concerns (patching, upgrades, policy enforcement) at the gateway layer. This separation keeps application routing policy stable even as the underlying gateway implementation evolves.

This is particularly valuable when you consider how much operational overhead ingress controllers add: patching cadence, security response, compatibility testing with each Kubernetes upgrade. A managed gateway shifts that burden off your team.

Adopt Gateway API for interoperability, not lock-in

A common concern when adopting any managed service is vendor lock-in. Gateway API addresses this directly.

If your managed gateway implements the Kubernetes Gateway API standard, your routing configuration (Gateways, HTTPRoutes, etc.) stays portable. For multi-cloud or hybrid deployments, your core configuration follows the same spec. You're not locked into proprietary annotations or custom resources for basic routing—you're using the API that the entire Kubernetes ecosystem is converging on.

For Azure customers, this is exactly where Application Gateway for Containers comes in.

Application Gateway for Containers: The next step

While Gateway API is the model the Kubernetes community is investing in, you still need a gateway implementation that can carry production traffic safely. For many AKS customers, Azure Application Gateway for Containers is attractive because it's designed specifically for Kubernetes ingress, while fitting naturally into Azure's application delivery portfolio.

At a high level, Application Gateway for Containers is an L7 (application layer) load balancer and dynamic traffic management product for Kubernetes workloads, positioned as the evolution of Application Gateway Ingress Controller (AGIC). It supports Kubernetes Ingress and Kubernetes Gateway API, it's managed by an ALB controller running in-cluster that adheres to Kubernetes Gateway APIs, and has native integration with Web Application Firewall.

What sets Application Gateway for Containers apart from DIY open source options

When comparing Application Gateway for Containers to self-managed open source ingress controllers, several architectural and operational differences stand out:

Enterprise support, SLA, and security patching Application Gateway for Containers is a fully supported Azure service with:

Microsoft support - file tickets, get engineering assistance, escalate when needed.
Enterprise SLA - financially-backed availability guarantees for production workloads.
Security patching handled by Microsoft - when CVEs emerge in the underlying proxy or platform, Azure patches the service.

Out-of-cluster architecture Unlike in-cluster proxies (NGINX, Envoy, etc.), Application Gateway for Containers runs the data plane outside your AKS cluster. This means:

No proxy pods consuming your cluster's CPU and memory - those resources stay available for your workloads.
Independent scaling - the gateway scales based on traffic, not tied to your cluster's node capacity.
Blast radius separation - a misconfiguration or overload at the edge doesn't starve your application pods.

Azure-native Web Application Firewall (WAF) Application Gateway for Containers integrates with Azure WAF, giving you OWASP protection, bot mitigation, and custom rules without bolting on a separate security layer. But it's not just about convenience - Azure WAF benefits from Microsoft's global threat intelligence, drawing on signals from trillions of daily transactions across Azure, Microsoft 365, and other services to keep rulesets current against emerging attack patterns. With open source options, WAF typically means running yet another component (ModSecurity, Coraza, etc.) that you patch and tune yourself - and you're responsible for staying ahead of the threat landscape.

Deep Azure Ecosystem Integration Because Application Gateway for Containers is a first-party Azure service, you get:

Azure Monitor and Log Analytics for metrics, logs, and alerting - no sidecar exporters needed.
Azure Service Health notifications for platform incidents.
Portal, CLI, PowerShell, Bicep, and Terraform for provisioning and management.
Azure Policy and RBAC for governance at scale.

This matters operationally: instead of stitching together your own monitoring and alerting pipelines for your ingress layer, you inherit the same observability stack you already use for the rest of Azure.

And the expected bases are covered

Beyond the architectural advantages, Application Gateway for Containers delivers the routing capabilities you'd expect from a modern gateway:

Support for both Ingress and Gateway API - migrate incrementally without a hard cutover.
Traffic splitting and weighted round robin - enable canary deployments and progressive rollouts.
Mutual authentication (mTLS) - secure service-to-service communication.
Near real-time configuration updates - pod, route, and probe changes propagate in seconds, not minutes.
Flexible deployment strategies - manage the Azure resource lifecycle via ARM/Bicep/Terraform, or let the ALB Controller handle it entirely via Kubernetes CRDs.

No gaps, no surprises, just a solid foundation for production traffic.

Migrating today: A safe, incremental plan

Whether you're coming from AGIC or ingress-nginx, the practical goal is the same: reduce risk while maintaining traffic parity.

A conservative migration pattern looks like this:

Inventory your Ingresses (hosts, paths, TLS patterns, annotations).
Stand up Application Gateway for Containers in parallel (choose BYO vs. managed deployment strategy).
Convert a low-risk service first, validate end-to-end.
Migrate iteratively (service-by-service), monitor and roll back if needed.
Cut traffic over once parity is proven, then retire the old controller.

This approach is consistent with both:

Microsoft's goal of "incremental migration + validation + no downtime" for AGIC to Application Gateway for Containers migrations.
Gateway API guidance that you can run a Gateway API controller alongside Ingress-NGINX to test in isolation.

The Missing Piece: Translating Years of Annotations (and How Tooling Helps)

For many teams, the hardest part isn't "create a Gateway" - it's annotation archaeology.

That's why Microsoft has built and open-sourced the Application Gateway for Containers Migration Utility: a command-line utility that helps translate existing Kubernetes Ingress configuration (including controller-specific annotations) into Gateway API YAML for Application Gateway for Containers.

You can find the tool at aka.ms/agc/migrationutility.

What the utility does

The tool is a command-line utility that:

Reads your existing NGINX Ingress configuration from a cluster (read-only),
Outputs the equivalent Gateway API YAML, and
Translates AGIC / NGINX annotations into Gateway API resources and (where needed) Application Gateway for Containers-specific custom resources.

The utility is fully open source, and we welcome your contributions! If you encounter missing annotation support, edge cases, or have ideas for improvement, please open an issue or submit a pull request at aka.ms/agc/migrationutility. Your feedback helps make the tool better for everyone navigating this migration.

Important note: Any migration tool should be used as a starting point - the output is meant to be reviewed, tested, and adjusted based on your environment's specifics (auth, WAF rules, TLS policies, edge cases).

A practical phased rollout checklist

To make this actionable for teams planning the next few months, here's a simple rollout scaffold:

Phase 1: Decide your target state

Choose whether your end state is Gateway API-first (recommended) or Ingress-first as a short bridge.
Choose Application Gateway for Containers deployment strategy:
- BYO (Bring Your Own): Create and manage Application Gateway for Containers via Azure Portal, CLI, or Terraform, then reference it in Kubernetes. Best when your CI/CD pipelines already manage Azure resource lifecycle.
- Managed by ALB Controller: The in-cluster ALB Controller handles Application Gateway for Containers lifecycle based on Kubernetes CRDs. Best when you want a fully Kubernetes-native experience.

Phase 2: Stand up the parallel path

Deploy ALB Controller.
Create Application Gateway for Containers using your chosen strategy.
Create a test Gateway + HTTPRoute for a single service.

Phase 3: Convert + validate incrementally

Use translation tooling to generate initial Gateway API resources.
Validate routing parity (hosts, paths, rewrites, headers).
Validate security posture (TLS, backend mTLS if needed, policy/WAF).
Cut traffic over only when observability and SLOs look equivalent.

Migrate once - onto the model the ecosystem is backing

The retirement of the community ingress-nginx controller is forcing planning work across the industry. The best long-term outcome is to migrate once onto the model Kubernetes is actively evolving: Gateway API.

For AKS customers, Microsoft's direction is clear: support continuity for the existing add-on through November 2026 (critical security patches), while investing in the future centered on Gateway API.

The combination of Application Gateway for Containers + Gateway API + migration tooling is meant to reduce friction: pick a supported path forward, adopt the modern API, validate safely, and minimize the number of migrations.