Application Gateway Ingress Controller (AGIC) lets Azure Application Gateway act as the ingress for your Azure Kubernetes Service (AKS) cluster.

Here’s an AKS cluster with AGIC configured, showing a simple Nginx deployment and its corresponding Application Gateway configuration.

# nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

---
# nginx-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-service
            port:
              number: 80
---
# nginx-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

When you apply these manifests to your AKS cluster, AGIC observes the Ingress resource. It then configures the associated Application Gateway. This involves creating backend pools pointing to your AKS pods, health probes to monitor pod health, and listeners/rules to route incoming traffic from myapp.example.com on port 80 to the Nginx service.

The core problem AGIC solves is providing a robust, feature-rich L7 load balancer for AKS without needing to manage a separate ingress controller deployment within the cluster itself. Application Gateway offers features like SSL termination, Web Application Firewall (WAF), cookie-based session affinity, URL-based routing, and autoscaling, all managed by Azure. AGIC acts as the bridge, translating Kubernetes Ingress objects into Application Gateway configuration.

Internally, AGIC runs as a deployment within your AKS cluster. It watches the Kubernetes API server for Ingress resources. When it detects changes (creation, update, deletion), it communicates with the Azure Resource Manager (ARM) API to update the configuration of the specified Application Gateway. This means your Application Gateway’s configuration is always in sync with your Kubernetes ingress resources.

The key levers you control are the Ingress resource itself, and the Application Gateway’s configuration. For example, you can specify ssl-redirect: "true" in the Ingress annotations to force HTTPS traffic. You can also configure WAF policies via Application Gateway’s properties, which AGIC will then apply.

The most surprising thing about AGIC is that it doesn’t run any pods from your application within the Application Gateway itself. It’s purely a control plane integration, meaning your application pods run exclusively within AKS, and Application Gateway sits in front of them as a managed Azure service.

When you define multiple paths or hosts in your Ingress resource, AGIC translates these into multiple rules within the Application Gateway’s HTTP settings, routing traffic to different backend services based on the request’s host header and URL path.

The next concept to explore is how to integrate Application Gateway’s Web Application Firewall (WAF) with AGIC for enhanced security.

Want structured learning?

Take the full Aks course →