Ingress, load balancers and TLS

Your workloads run on EKS — now how does internet traffic reach them, with HTTPS, on a real domain? In the Foundation you met Kubernetes Ingress and Services abstractly; on EKS they connect to real AWS load balancers. This lesson is how traffic reaches a pod on EKS: the AWS Load Balancer Controller, ALBs and NLBs, and TLS with ACM certificates. It is where the networking module and the Kubernetes module meet.

The AWS Load Balancer Controller

In the Foundation, a Kubernetes Service of type LoadBalancer or an Ingress was fulfilled by "the cloud's load balancer." On EKS, that fulfilment is done by the AWS Load Balancer Controller — an add-on (the eks-basics lesson) that watches your Kubernetes Ingress and Service objects and creates the corresponding real AWS load balancers:

An Ingress object → the controller provisions an Application Load Balancer (ALB) — a layer-7 (HTTP/S) load balancer that routes by host and path, exactly the ingress role from the Foundation, now backed by an actual AWS ALB.
A Service of type LoadBalancer (with the right annotations) → a Network Load Balancer (NLB) — a layer-4 (TCP) load balancer, for non-HTTP or high-performance needs.

So you still write ordinary Kubernetes Ingress/Service YAML, and the controller translates it into AWS load balancers wired to your pods. This is the EKS realisation of the Foundation's traffic path: Internet → (AWS load balancer, created from your Ingress) → Service → Pod.

ALB vs NLB: which layer

The two load balancer types map to two layers (the networking and HTTP lessons):

Application Load Balancer (ALB) — operates at layer 7 (HTTP/HTTPS). It understands requests, so it can route by hostname and path (app.example.com → one service, api.example.com → another), terminate TLS, and do host/path-based rules. This is what you use for web apps and APIs — most EKS ingress uses an ALB.
Network Load Balancer (NLB) — operates at layer 4 (TCP/UDP). It does not understand HTTP; it forwards connections with very high performance and low latency. Use it for non-HTTP protocols, or extreme performance needs.

For a typical web/API workload, the ALB (via an Ingress) is the right choice — it gives you host/path routing and TLS termination, which is what web traffic needs.

TLS with ACM: HTTPS the AWS way

HTTPS on EKS is beautifully simple because AWS manages the certificates. AWS Certificate Manager (ACM) issues and automatically renews free TLS certificates (the networking module's TLS — no more manual renewal, no expiry outages). You:

Request a certificate in ACM for your domain (validated via DNS — a record in Route 53).
Reference that certificate on your Ingress (an annotation with the certificate's ARN).
The ALB terminates TLS using it — HTTPS to users, and the ALB forwards to your pods.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:eu-west-1:123456789012:certificate/abc  # the ACM cert
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
spec:
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: greetings
                port:
                  number: 80

This gives you HTTPS with automatic certificate renewal (ACM handles it — the certificate-expiry outage from the networking module simply cannot happen), host/path routing at the ALB, and traffic forwarded to your pods. The whole TLS burden is offloaded to AWS.

The full path on EKS, and DNS

Putting the path together with the domain:

Route 53 (AWS's DNS — the networking module's DNS) holds your domain, with a record pointing your hostname at the ALB (often an alias record to the load balancer). ExternalDNS can even create these records automatically from your Ingress.
Traffic flows: user → Route 53 (name → ALB) → ALB (TLS termination via ACM, host/path routing) → Kubernetes Service → Pod — the Foundation's traffic path, realised entirely with AWS services.
The ALB lives in your public subnets; the pods in private subnets; security groups allow ALB → pods (the networking module) — so only the ALB is internet-facing and the pods are unreachable directly.

The takeaway: on EKS you write standard Kubernetes Ingress/Service objects, and the AWS Load Balancer Controller turns them into real ALBs/NLBs, with ACM handling TLS and Route 53 handling DNS. Everything from the networking module (subnets, security groups, TLS, DNS) assembles into the path that gets HTTPS traffic to your pods — automatically renewed, host-routed, and secured.

Check your work

AWS Load Balancer Controller (an add-on) watches Ingress/Service objects and creates real AWS load balancers: an Ingress → ALB (layer 7, host/path routing, TLS), a Service type LoadBalancer → NLB (layer 4, TCP, high performance). You write standard Kubernetes YAML; it provisions AWS LBs wired to your pods.

ALB vs NLB: ALB = layer 7 HTTP/S (route by host/path, terminate TLS — for web/APIs, the usual choice); NLB = layer 4 TCP/UDP (very high performance, non-HTTP).

TLS with ACM: AWS Certificate Manager issues + auto-renews free certs; request a cert (DNS-validated via Route 53), reference its ARN on the Ingress, the ALB terminates TLS. HTTPS with no manual renewal — the cert-expiry outage cannot happen.

Full path + DNS: Route 53 points the hostname at the ALB (alias; ExternalDNS can automate), then user → Route 53 → ALB (TLS via ACM, host/path routing) → Service → Pod. ALB in public subnets, pods in private, security groups ALB → pods. The whole networking module assembles here.

Practice

Explain what the AWS Load Balancer Controller does and what a Kubernetes Ingress becomes on EKS.
Compare ALB and NLB by layer and use case, and say which suits a web API.
Explain how ACM provides HTTPS with automatic renewal and why that removes a class of outage.
Write an ALB Ingress referencing an ACM certificate for a hostname, and explain each annotation.
Trace the full traffic path from a user's browser to a pod on EKS, naming Route 53, ALB, Service, pod.
Explain where the ALB and pods sit (subnets) and how security groups restrict the path.

Official documentation

AWS — Load Balancer Controller — Creating AWS load balancers from Kubernetes objects.
AWS — Route application traffic with ALB Ingress — Ingress, ALBs and annotations.
AWS Certificate Manager — User guide — Free, auto-renewing TLS certificates.

Next: horizontal pod autoscaling and cluster autoscaling.