Amazon EKS Ingress Controllers: AWS Load Balancer Controller, ALB Routing, and TLS

Simple explanation

If you are new to Kubernetes, here is the short version.

A Service is the standard Kubernetes way to expose a set of pods to network traffic. When you create a Service of type LoadBalancer, EKS provisions an AWS load balancer and gives you an external address. One Service, one load balancer.

An Ingress is a higher-level routing layer. It is a Kubernetes resource that defines rules like: requests for api.example.com/v1 go to the API service, and requests for dashboard.example.com go to the dashboard service. One Ingress resource can route traffic to many Services through a single load balancer.

An ingress controller is the software that makes those rules work. By itself, an Ingress resource is just YAML. It does not do anything. The ingress controller watches for Ingress resources in the cluster and configures a load balancer to enforce the routing rules you defined.

Ingress vs Service: what is the difference

A Kubernetes Service of type LoadBalancer creates one AWS load balancer per Service. If you have five services to expose externally, an API, a dashboard, a webhook handler, a docs site, and a metrics endpoint, you end up with five separate load balancers. Each one costs money, needs its own DNS record, and has its own health check configuration.

An Ingress sits in front of multiple Services and routes requests to the right one based on URL path or hostname:

• api.example.com routes to the API Service
• dashboard.example.com routes to the Dashboard Service
• example.com/webhooks routes to the Webhook Service

All of this goes through a single AWS Application Load Balancer. One load balancer, one set of TLS certificates, one DNS entry point.

When a LoadBalancer Service is enough:

• You only have one service to expose externally
• You need TCP or UDP routing, not HTTP
• You want the simplest possible setup with no extra components installed

When Ingress is the better choice:

• You have multiple HTTP/HTTPS services to expose
• You want path-based or host-based routing
• You want TLS termination in one place
• You want to reduce the number of load balancers and the costs that come with them

What an ingress controller does on EKS

On Amazon EKS, the main AWS-native option for running an ingress controller is the AWS Load Balancer Controller.

The controller is a pod that runs inside your cluster. It watches for Ingress and Service resources using the Kubernetes API. When you create an Ingress resource with the right annotations, the controller reads it, calls the AWS API, and creates or updates an Application Load Balancer to match your routing rules.

This is different from a self-hosted ingress controller like NGINX, which runs a proxy pod inside the cluster. With AWS Load Balancer Controller, the load balancer itself lives in AWS infrastructure, not inside your cluster. That means native AWS integrations (WAF, ACM, Shield, CloudWatch), better throughput, and no in-cluster proxy to scale or maintain.

How it works on AWS

Here is the request flow when a user hits a service exposed via Ingress on EKS:

User browser
    ↓
Route 53  →  resolves the domain to the ALB DNS name
    ↓
Application Load Balancer  →  listener rules match hostname or path
    ↓
Target group  →  routes directly to pod IPs
    ↓
Pod (your application)

Route 53 typically points your domain to the ALB’s DNS name using an Alias record. The Application Load Balancer handles TLS termination, evaluates listener rules, and distributes traffic. The EKS networking model (VPC CNI) gives every pod a real VPC IP address, which is why the ALB can route directly to pods rather than going through node ports.

Path-based routing sends traffic to different Services based on the URL path. A request to /api/ goes to the API service and a request to /admin/ goes to the admin service, both through the same ALB and the same hostname.

Host-based routing sends traffic to different Services based on the hostname. api.example.com goes to one Service and dashboard.example.com goes to another. Each hostname maps to a separate listener rule on the ALB.

You can combine both: route by hostname first, then by path within that hostname.

What you need before this works

Before an Ingress resource on EKS will create a working ALB, you need all of the following in place:

• A working EKS cluster. If you do not have one, start with creating your first EKS cluster.
• AWS Load Balancer Controller installed. Not present by default. Install it via Helm.
• IRSA configured for the controller. The controller needs an IAM role with permission to create and manage ALBs, target groups, and security groups. That role is linked to the controller’s Kubernetes service account via IAM Roles for Service Accounts.
• Subnets tagged correctly. The controller uses subnet tags to find where to place the ALB. Public subnets need kubernetes.io/role/elb: 1 for internet-facing ALBs. Private subnets need kubernetes.io/role/internal-elb: 1 for internal ALBs.
• Security groups that allow ALB traffic. The ALB needs to reach your pods on the target port.
• An ACM certificate if using HTTPS. You do not store certificates in Kubernetes. The ALB uses a certificate from AWS Certificate Manager, which handles renewal automatically.

Basic Ingress example

Here is the simplest useful Ingress: one backend service, HTTPS enabled.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  namespace: production
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:eu-west-1:123456789012:certificate/abc123
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
    alb.ingress.kubernetes.io/ssl-redirect: '443'
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 80

When you apply this, the AWS Load Balancer Controller creates an internet-facing ALB that listens on ports 80 and 443, redirects HTTP to HTTPS automatically, terminates TLS using the ACM certificate, and routes all traffic to my-app-service.

Here is an example with multiple backends using path-based and host-based routing:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: main-ingress
  namespace: production
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:eu-west-1:123456789012:certificate/abc123
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
    alb.ingress.kubernetes.io/ssl-redirect: '443'
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
      - path: /webhooks
        pathType: Prefix
        backend:
          service:
            name: webhook-service
            port:
              number: 80
  - host: dashboard.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: dashboard-service
            port:
              number: 80

Important AWS Load Balancer Controller annotations

The controller uses annotations on the Ingress resource to configure the ALB. These are the ones you will use most often:

TLS termination with ACM

With AWS Load Balancer Controller, TLS is terminated at the ALB, not inside your cluster. Here is how the setup works:

1. Request or import a certificate in AWS Certificate Manager for your domain.
2. Add the certificate ARN to your Ingress as the certificate-arn annotation.
3. The controller configures the ALB with an HTTPS listener using that certificate.
4. The ALB handles the TLS handshake with the client.
5. The ALB forwards the request to your pod as plain HTTP over the VPC network.

Your pods do not need to handle certificates at all. ACM manages certificate renewal automatically, with no secrets to rotate and no Kubernetes resources to update when a certificate renews.

AWS Load Balancer Controller vs NGINX Ingress on EKS

Both work on EKS. The choice depends on what your team needs.

AWS Load Balancer Controller provisions native AWS ALBs and NLBs directly from Kubernetes resources. The load balancer lives in AWS infrastructure, not inside your cluster. It integrates with ACM for TLS, WAF for request filtering, Shield for DDoS protection, and CloudWatch for metrics. All configuration is done through annotations on the Ingress resource.

NGINX Ingress Controller runs an NGINX proxy pod inside your cluster and exposes it via a LoadBalancer Service (which creates an NLB). It is more flexible for routing: it supports matching by headers, query strings, and request body in ways that ALB listener rules cannot. TLS is managed via Kubernetes Secrets, often using cert-manager for automated issuance and renewal.

For most new EKS projects, AWS Load Balancer Controller is the right default. It avoids running and scaling a proxy pod inside the cluster, and it integrates cleanly with the rest of the AWS stack. Choose NGINX Ingress when you need routing rules that ALB annotations cannot express, or when you need consistent ingress behaviour across clouds.

When to use Ingress on EKS

Use Ingress when:

• You have more than one HTTP/HTTPS service to expose and want to avoid one load balancer per service
• You need to route requests based on hostname or URL path
• You want TLS termination in one place, managed through ACM
• You want to group services from different teams or namespaces behind a single ALB using group.name
• You are building a microservices architecture where a single external entry point fans out to multiple backends

Do not use Ingress when:

• You need to expose a single TCP or UDP service; use a LoadBalancer Service or an NLB directly instead
• You only have one HTTP service and want the simplest possible setup
• You need WebSocket or gRPC connections; these work with ALB but require additional annotations and care

Troubleshooting checks

If your Ingress is not working, run through these in order.

Check whether the ALB was created:

kubectl get ingress -n <namespace>

The ADDRESS column should show the ALB DNS name. If it is empty, the controller did not provision the ALB.

Describe the Ingress for controller events:

kubectl describe ingress <name> -n <namespace>

The Events section at the bottom shows what the controller attempted and where it stopped.

Check the controller is running:

kubectl get pods -n kube-system | grep aws-load-balancer

Check controller logs for errors:

kubectl logs -n kube-system -l app.kubernetes.io/name=aws-load-balancer-controller

Common specific issues:

• No ADDRESS on the Ingress: Controller is not running, IRSA is missing, or subnets are not tagged correctly.
• ALB created but targets are unhealthy: Confirm target-type: ip is set, the Service selector matches running pods, and the Service port matches what the container listens on.
• HTTPS not working: Verify the ACM certificate ARN is correct and the certificate status is Issued. The domain on the certificate must match the host rule in the Ingress.
• HTTP not redirecting to HTTPS: Both listen-ports (including HTTP 80 and HTTPS 443) and ssl-redirect: '443' must be set together.
• 404 from the ALB: The ALB listener rules were created but no backend rule matched the request. Check that the path and host in the Ingress spec match what the request is sending.
• Internal service not reachable from outside: The scheme annotation may be set to internal when you need internet-facing, or the ALB security group does not allow inbound traffic on port 443.

For cluster-level logging context, see logging in Kubernetes. For security controls around ingress, see securing EKS clusters.

Cost and architecture considerations

The main cost benefit of Ingress is consolidation: one ALB in front of many services instead of one load balancer per service.

A LoadBalancer Service on EKS typically provisions one Network Load Balancer. If you have ten services exposed via separate LoadBalancer Services, you pay for ten load balancers. Put those same ten services behind a single ALB via Ingress with a shared group.name, and you pay for one.

ALB pricing has two parts: a fixed hourly rate per load balancer, plus a usage-based charge (Load Balancer Capacity Units) that scales with connections, data processed, and rules evaluated. For most applications with moderate traffic, the usage cost is low and consolidating behind fewer ALBs saves money clearly. Check the current AWS pricing page for your region, since rates vary. At very high traffic volumes, model the usage cost directly against the fixed cost of running more load balancers.

Practical patterns worth knowing:

• One ALB per environment (dev, staging, prod) using group.name is a common and cost-effective pattern. Teams define their own Ingress resources and the controller merges them into the shared ALB automatically.
• Separate internet-facing and internal ALBs is a clean split: one group for public traffic, one for internal service-to-service communication.
• WAF on public ALBs adds cost but provides meaningful protection if your services handle user-generated content or are exposed to untrusted traffic.