Compare NGINX Ingress Controller vs Istio Gateway vs AWS ALB Ingress Controller for Kubernetes. When would you choose each?
Quick Answer
NGINX Ingress: flexible L7 routing, widely adopted, good for most use cases. Istio Gateway: when using service mesh, advanced traffic management. AWS ALB: tight AWS integration, native WAF/Shield support.
Detailed Answer
NGINX Ingress Controller
- Most popular K8s ingress controller - Full NGINX configuration via annotations and ConfigMaps - L7 routing: host-based, path-based, header-based - SSL termination, rate limiting, basic auth, canary deployments - Works on any infrastructure (cloud, on-prem, edge) - Best for: General-purpose ingress, teams familiar with NGINX, multi-cloud
Istio Gateway
- Part of Istio service mesh — requires full mesh deployment - VirtualService + Gateway resources for routing - Advanced traffic management: mirroring, fault injection, retries - Automatic mTLS, authorization policies, observability - Best for: Teams already using Istio, need service mesh features at the ingress layer, complex traffic routing (A/B testing, canary with metric-based promotion)
AWS ALB Ingress Controller
- Provisions actual AWS Application Load Balancers - Native integration: WAF, Shield, Cognito auth, Certificate Manager - Target group binding directly to pods (IP mode) or NodePort - Cost: Per ALB + per LCU pricing (can get expensive with many ingresses) - Best for: AWS-only deployments, need WAF/Shield, compliance requirements, teams preferring AWS-native services
Decision Matrix
- Multi-cloud → NGINX Ingress - Already on Istio → Istio Gateway - AWS-only + need WAF → ALB Ingress - Cost-sensitive → NGINX Ingress (one deployment handles all routes)
Code Example
# NGINX Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: api-ingress
annotations:
nginx.ingress.kubernetes.io/rate-limit: "100"
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
ingressClassName: nginx
tls:
- hosts: [api.example.com]
secretName: api-tls
rules:
- host: api.example.com
http:
paths:
- path: /v2
pathType: Prefix
backend:
service:
name: api-v2
port: { number: 80 }
# Istio Gateway + VirtualService
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: api-gateway
spec:
selector:
istio: ingressgateway
servers:
- port: { number: 443, name: https, protocol: HTTPS }
tls:
mode: SIMPLE
credentialName: api-tls
hosts: [api.example.com]
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
hosts: [api.example.com]
gateways: [api-gateway]
http:
- route:
- destination: { host: api-v1 }
weight: 90
- destination: { host: api-v2 }
weight: 10Interview Tip
Frame your answer around the decision matrix, not just feature lists. Show you can make a recommendation based on the specific context (cloud provider, existing stack, team expertise).