Understanding Application Gateway for Containers (AGC) in AKS

Introduction #

If you’re working with Azure Kubernetes Service (AKS), you need a way to handle incoming HTTP/HTTPS traffic and send it to the right applications inside your cluster. Traditionally, this has been done with tools like Application Gateway Ingress Controller (AGIC) or NGINX Ingress.

Now there’s a newer and more flexible approach: Application Gateway for Containers (AGC), built on top of the Kubernetes Gateway API.

In this post, we’ll break down:

• What Gateway API is and why it matters
• How AGC works in AKS
• How AGC handles availability and reliability
• What AGC is, and what it is not

What Is Gateway API? #

Before Gateway API, Kubernetes mainly used Ingress to manage traffic routing. It works, but it comes with some limitations.

For example:

• You often need vendor-specific annotations
• Advanced routing, like gRPC or TCP, is harder to manage
• Behavior is not always consistent across different implementations

To solve this, Kubernetes introduced Gateway API.

Why It’s Better #

Gateway API separates responsibilities into distinct components:

• GatewayClass defines how gateways should behave
• Gateway handles incoming traffic
• Routes define how traffic is sent to backend services

This separation makes things cleaner. Developers can focus on routing logic, while platform teams manage the infrastructure layer.

What Is Application Gateway for Containers (AGC)? #

AGC is Azure’s modern load balancing solution designed specifically for AKS.

It uses Gateway API concepts and provides:

• Advanced traffic routing
• Better scalability
• Native integration with Kubernetes

Think of it like this: AGC is a smarter, Kubernetes-friendly traffic controller for AKS workloads.

How AGC Works #

Here’s the request flow in simple terms:

1. A client sends a request.
2. The request reaches the AGC frontend, which acts as the public entry point.
3. The frontend receives the traffic using an auto-generated domain, or a custom DNS name if you map one.
4. Traffic is forwarded to the proxy layer running in a dedicated subnet.
5. The ALB Controller inside AKS reads Gateway and Route resources and decides how traffic should be routed.
6. The request reaches the correct Kubernetes service based on rules such as path matches or headers.

Once configured, this flow is handled automatically.

Role of the ALB Controller #

The ALB Controller is the control plane component behind AGC.

It:

• Watches Gateway API resources such as Gateway and HTTPRoute
• Updates AGC configuration
• Uses Managed Identity to securely interact with Azure resources

It typically runs as:

• Two controller pods
• One bootstrap pod that installs the Gateway API CRDs

High Availability and Reliability #

AGC is designed to be resilient by default.

Within a Region #

AGC can automatically spread across Availability Zones. If one datacenter fails, traffic can continue flowing through the remaining healthy zones.

Across Regions #

For regional resiliency and global performance, AGC can be combined with:

• Azure Front Door
• Azure Traffic Manager

This setup helps route users to healthy regions and improves failover behavior.

What AGC Is Not #

This part is important because AGC is sometimes misunderstood.

AGC is not:

• A full replacement for Azure Application Gateway in every scenario
• A universal load balancer for VMs or App Services

It is purpose-built for AKS workloads, which is exactly where it shines.

Final Thoughts #

As Kubernetes workloads grow, traffic management becomes more complex.

Gateway API addresses many of the limitations of the older Ingress model, and Application Gateway for Containers brings that model into Azure in a cleaner and more scalable way.

If you’re working with AKS and need more flexible routing, AGC is definitely worth exploring.