Ingress Controller

Overview

An Ingress Controller is a specialized load balancer for Kubernetes that manages external access to services within a cluster. While Kubernetes Services expose applications internally, an Ingress Controller acts as the entry point for HTTP/HTTPS traffic from outside the cluster.

What Does an Ingress Controller Do?

An Ingress Controller watches for Ingress resources in your cluster and configures the underlying load balancer accordingly. It typically handles:

• Routing: Directing traffic to the correct service based on hostname and URL path
• TLS Termination: Handling HTTPS certificates and encryption
• Load Balancing: Distributing traffic across multiple pod replicas
• Authentication: Validating requests before they reach your application
• Traffic Management: URL rewriting, redirects, rate limiting, and more

Choosing an Ingress Controller

We offer multiple ingress controller options, each with different strengths:

The right choice depends on your specific needs. See Making Your Choice below.

AWS LoadBalancer Controller

The AWS Load Balancer Controller provisions and manages AWS Elastic Load Balancers for your Kubernetes services. For Ingress resources, it creates Application Load Balancers (ALBs).

How It Works

Unlike traditional ingress controllers that run as pods inside your cluster, the ALB controller only runs a control plane component. The actual load balancing happens on AWS-managed infrastructure (the ALB) outside your cluster:

                         AWS Cloud
    ┌─────────────────────────────────────────────────────────┐
    │                                                         │
    │   ┌─────────────┐         ┌──────────────────────────┐  │
    │   │     ALB     │         │    Kubernetes Cluster    │  │
    │   │  (AWS Managed)────────▶  Pods (target-type: ip)  │  │
    │   └─────────────┘         └──────────────────────────┘  │
    │         ▲                            ▲                  │
    │         │                            │                  │
    │         │    watches & configures    │                  │
    │         │         ┌──────────────────┘                  │
    │         │         │                                     │
    │         │   ┌─────┴──────┐                              │
    │         └───│ ALB Controller │                          │
    │             └────────────┘                              │
    └─────────────────────────────────────────────────────────┘

Key Characteristics

Traefik

Traefik is a modern, cloud-native ingress controller that runs as pods within your Kubernetes cluster. It’s designed for dynamic environments and supports both the traditional Ingress API and the newer Gateway API.

How It Works

Traefik runs as a deployment in your cluster, watching for Ingress resources and routing traffic accordingly:

                    Kubernetes Cluster
    ┌───────────────────────────────────────────────────────┐
    │                                                       │
    │   ┌─────────────────┐                                 │
    │   │  Traefik Pods   │──────▶ Service A ──▶ Pods      │
    │   │  (Deployment)   │──────▶ Service B ──▶ Pods      │
    │   └────────┬────────┘──────▶ Service C ──▶ Pods      │
    │            │                                          │
    │            │ watches                                  │
    │            ▼                                          │
    │   ┌─────────────────┐                                 │
    │   │ Ingress / CRDs  │                                 │
    │   └─────────────────┘                                 │
    │                                                       │
    └───────────────────────────────────────────────────────┘
            ▲
            │
        Internet (via NLB/Service)

Key Characteristics

Ingress-NGINX Controller

The ingress-nginx controller was historically the most popular Kubernetes ingress controller, running NGINX as a reverse proxy inside your cluster.

Migration from Ingress-NGINX to ALB/Traefik

In general we will follow a simple process by enabling the new ingress controller alongside ingress-nginx, migrating workloads together with the customer one-by-one, and then decommissioning ingress-nginx once all workloads have been migrated.

1. Launch new ingress solution in parallel
2. Switch workloads and ingresses case by case to the new ingress, using examples from the How-To Guides
3. Verify everything is working
4. Disable ingress-nginx through cluster definition file

Making your choice

✅ Full native support | ⚠️ Partial/limited support | ❌ Not supported

Strengths & Weaknesses

When to use what

Choose Traefik when:

• You need CORS headers at the ingress level
• You need rate limiting without additional AWS costs
• You have complex proxy timeout/buffer requirements
• You’re migrating from ingress-nginx with custom annotations
• You need cookie-based session affinity

See the Traefik How-To Guide for configuration examples.

Choose AWS Load Balancer Controller when:

• You need standard HTTP routing with TLS termination
• You’re using OIDC or Cognito for authentication
• You want a more AWS Native, managed solution

See the AWS Load Balancer Controller How-To Guide for configuration examples.

Migration Coverage Summary

In preparation for migrating from ingress-nginx to a new ingress controller, we analyzed ~1,100 existing ingresses to determine how many could be migrated easily, which would require moderate effort, and which would face significant blockers. Below is a summary of our findings for both the AWS ALB Controller and Traefik.

ALB Controller

ALB Hard Blockers

Traefik

Traefik Hard Blockers