EKS AWS Load Balancer Controller: Ingress, ALB & NLB Hands-On

Quick take: the AWS Load Balancer Controller is the piece that turns a Kubernetes Ingress into a real Application Load Balancer and a Service of type LoadBalancer into a Network Load Balancer — provisioning the AWS resources out-of-band from your cluster, watching your manifests, and reconciling listeners, target groups, rules, and target registration as pods come and go. It replaces the legacy in-tree Kubernetes cloud provider (which only ever gave you a Classic Load Balancer per Service) with something production-grade: target-type: ip so the ALB talks straight to pod IPs, ACM TLS termination, WAF/Shield association, and — the cost saver everyone misses — an IngressGroup that folds many Ingresses onto one shared ALB. Get the IRSA role, the subnet tags, or the security-group chain wrong and you will stare at an Ingress with a blank ADDRESS, a controller in CrashLoopBackOff, or an ALB returning 503 because no target ever went healthy.

A platform team I worked with had a clean EKS cluster, a working Deployment, and a Service — and an Ingress object that had sat with an empty ADDRESS field for three days. No ALB. No error in kubectl get ingress. They had followed a blog, applied the manifest, and assumed EKS would “just make a load balancer” the way a managed platform does. It does not. Kubernetes has no built-in Ingress implementation — an Ingress resource is inert until a controller reconciles it. They had never installed the AWS Load Balancer Controller. Once we installed it (Helm chart, an IRSA ServiceAccount with the IAM policy attached) the controller’s first reconcile threw couldn't auto-discover subnets because the VPC’s public subnets were not tagged kubernetes.io/role/elb. Two tags later, the ALB appeared in ninety seconds. Not a Kubernetes bug. Not an app bug. A controller-not-installed bug followed by a missing-subnet-tag bug — both one layer below where they were looking.

This article is the hands-on, production-grade path to load balancing on EKS with the AWS Load Balancer Controller: what the controller actually watches and provisions (Ingress → ALB, Service LoadBalancer → NLB, TargetGroupBinding → an existing target group), how to install it with Helm on an IRSA identity plus the subnet tags it depends on, every alb.ingress.kubernetes.io/* annotation that matters (target-type ip vs instance, scheme, listen ports, SSL redirect, the ACM certificate-arn and SSL policy, health checks, target-group attributes, WAF/Shield, and IngressGroup ordering), the NLB side via service.beta.kubernetes.io/aws-load-balancer-*, TargetGroupBinding, ExternalDNS for Route 53, and the readiness gate that keeps rolling deploys from dropping traffic. You will build the real thing with aws, kubectl, helm, and Terraform, verify a healthy ip target group, add a second Ingress to the same IngressGroup, and tear it down — mind the ALB cost. Because you will return to this mid-incident, the annotations, limits, error strings, and playbook are laid out as scannable tables.

By the end you will stop guessing. When an Ingress produces no ALB you will localise it to the exact hop — controller not running, IRSA denied, subnet tags missing, wrong ACM ARN, backend SG blocking the pod, or a health check pointed at the wrong path — and fix it because you understand what the controller is for, not by re-applying the manifest and hoping.

What problem this solves

You have a container running on EKS. Now it has to be reachable from the internet: on a stable DNS name, over HTTPS with a real certificate, load-balanced across pods that live in private subnets and get replaced constantly, without you hand-building an ALB and re-registering targets every deploy. Kubernetes gives you the Ingress and Service abstractions to declare that intent — but on a raw cluster those objects do nothing, because Kubernetes ships no load balancer of its own. Something has to translate them into AWS infrastructure.

The AWS Load Balancer Controller (formerly the AWS ALB Ingress Controller, rewritten as the v2 AWS Load Balancer Controller) is that translator. It runs as a Deployment inside your cluster, watches Ingress and Service objects, and calls the Elastic Load Balancing, EC2, ACM, and WAF APIs to create and continuously reconcile the matching AWS resources. Declare an Ingress with ingressClassName: alb and it provisions an ALB with listeners, rules, and target groups. Declare a Service of type: LoadBalancer with the right annotation and it provisions an NLB. As pods scale, roll, and die, the controller registers and deregisters their IPs in the target group so traffic only ever reaches healthy pods.

What breaks without it, or with it misconfigured: your Ingress sits with a blank ADDRESS forever because nothing reconciles it. You fall back to the legacy in-tree provider and every Service spins up a separate Classic Load Balancer — an old, expensive, per-Service sprawl with no path routing. You expose ten microservices and pay for ten ALBs because you never learned that an IngressGroup collapses them onto one. You point TLS at an ACM certificate in the wrong Region and the HTTPS listener silently never appears. You use target-type: ip but forget that the ALB now talks straight to pod IPs, so the pods’ security group blocks it and every target is unhealthy, and the ALB returns 503. You deploy a new version and drop in-flight requests because you never enabled the pod readiness gate. Every one of these is a controller or annotation mistake, three layers down from the symptom — and every one is in this guide.

Who hits this: essentially every team running web apps, APIs, or gRPC services on EKS. It bites hardest on teams who came from a managed PaaS and expect load balancers to appear by magic, and on teams who treat the controller as a black box — they copy annotations from a gist, it “works” once, and then they have no mental model when an Ingress produces no ALB or a target will not go healthy. The fix is almost never “re-apply.” It is “read the controller logs and find the object that is lying — the ServiceAccount, the subnet tags, the ACM ARN, the backend SG, or the health check — and make it tell the truth.”

To frame the field, here is the core mapping the controller implements — the Kubernetes object you declare, and the AWS resource it provisions and owns.

Learning objectives

By the end of this article you can:

• Explain what the AWS Load Balancer Controller does — how it watches Ingress → ALB and Service LoadBalancer → NLB, and why it replaced the legacy in-tree cloud provider (Classic Load Balancers).
• Install the controller with Helm on an IRSA identity: create the OIDC provider, attach the AWSLoadBalancerControllerIAMPolicy, annotate the ServiceAccount, and apply the subnet tags (kubernetes.io/role/elb, internal-elb, cluster/<name>) it depends on.
• Author an Ingress end to end: choose target-type: ip vs instance, set scheme, listen ports, SSL redirect, the ACM certificate-arn and SSL policy, health-check path, and target-group attributes.
• Share one ALB across many Ingresses with an IngressGroup (group.name / group.order) to cut cost, and understand how annotations merge across the group.
• Provision an NLB from a Service (aws-load-balancer-type: external, nlb-target-type: ip, scheme) and bind to an existing target group with TargetGroupBinding.
• Wire ExternalDNS for Route 53 records, enable the pod readiness gate, and reason about deregistration so rolling deploys never drop traffic.
• Build the whole stack in a hands-on lab with aws eks / iam / helm / kubectl and Terraform, verify healthy ip targets, add a second Ingress to the group, and tear it down with nothing billable left.
• Run a symptom → confirm → fix playbook for no ALB, unhealthy targets, 504 from the ALB, a cert that never applies, controller CrashLoop, IngressGroup conflicts, NotFound subnets, and ExternalDNS silence.

Prerequisites & where this fits

You need a running EKS cluster with worker nodes (managed node group or Fargate profile) and kubectl context pointed at it — the companion hands-on EKS Cluster Setup with eksctl (Hands-On) builds exactly that. You need to understand IRSA — how a Kubernetes ServiceAccount maps to an IAM role through the cluster’s OIDC provider — because the controller is an IRSA workload; that is covered in depth in EKS IRSA: Pod IAM Permissions (Hands-On). You should know VPC basics — public vs private subnets and how security groups are stateful allow-lists — from VPC, Subnets, Route Tables & Security Groups Explained, and how private subnets reach out via NAT Gateway & Private-Subnet Egress Hands-On. Comfort with helm, kubectl, the aws CLI v2, and applying a small Terraform config is assumed.

This sits in the Containers track, at the networking edge of EKS. For the load-balancer layer itself — listeners, rules, target-group attributes, health-check reason codes, and the ALB HTTP status codes — keep Application Load Balancer & Target Groups Hands-On nearby; this article drives an ALB through Kubernetes, but that one is the ALB reference. For DNS — ALIAS records, routing policies, health checks — read Route 53 Records & Routing Policies (Hands-On); ExternalDNS in this article automates exactly those records. For the platform decision of ECS vs EKS vs Fargate, see ECS vs EKS vs Fargate: Choosing Your Container Path; for the broader compute menu, AWS Compute Compared: EC2, Lambda, ECS & EKS. When the ALB starts returning 5xx, the general playbook in ALB 502/503/504 Troubleshooting complements the EKS-specific one below.

Here is where the controller fits in the build order — what must exist before each step.

Core concepts

The controller has a small but precise vocabulary. People blur “Ingress” (the Kubernetes object) with “ALB” (the AWS resource), or think the controller is the load balancer. It is not — it is a reconciler that turns declared intent into AWS resources and keeps them in sync. Nail these terms and every annotation later has an obvious home.

An Ingress is a Kubernetes object describing L7 HTTP routing (hosts, paths → Services). It is inert without a controller. An IngressClass (spec.controller: ingress.k8s.aws/alb) tells Kubernetes which controller owns Ingresses that reference it; you select it per-Ingress with spec.ingressClassName: alb. The AWS Load Balancer Controller watches those Ingresses and provisions an ALB. A Service of type: LoadBalancer (with the right annotation/loadBalancerClass) is watched and provisioned as an NLB. target-type decides what the target group registers: ip (pod IPs directly, via the VPC CNI) or instance (node instances on a NodePort). IRSA (IAM Roles for Service Accounts) is how the controller pod gets AWS permissions without static keys — its ServiceAccount is annotated with a role ARN and the cluster’s OIDC provider vouches for it. An IngressGroup lets several Ingresses share one ALB.

Here is the core vocabulary in one place.

What it replaced: the in-tree cloud provider

Before this controller, Kubernetes’ in-tree AWS cloud provider handled Service type: LoadBalancer by creating a Classic Load Balancer (CLB) per Service, and there was no first-class Ingress support at all. The v2 controller is a strict upgrade: modern ALB/NLB, pod-IP targeting, ACM/WAF integration, and shared ALBs.

The CRDs the controller installs

Installing the controller adds two Custom Resource Definitions. You rarely author IngressClassParams by hand, but TargetGroupBinding is the escape hatch for provisioning the ALB in Terraform and letting the controller only manage target registration.

Installing the controller: IRSA, Helm, and subnet tags

Installation is three things done in order: give the controller an AWS identity (IRSA), install the Helm chart, and make sure the subnets are tagged so the controller can place load balancers. Skip any one and you get a specific, recognisable failure.

Prerequisites checklist

The IAM policy — what the controller is allowed to do

The controller’s IAM policy is broad because it creates and mutates load balancers, listeners, target groups, rules, and security groups, reads subnets, and reads ACM/WAF/Shield. Download the official policy JSON from the controller’s GitHub release (match the version to the chart you install) rather than writing your own.

# Download the policy that matches your controller version, then create it once per account
curl -sSo iam_policy.json \
  https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.7.2/docs/install/iam_policy.json

aws iam create-policy \
  --policy-name AWSLoadBalancerControllerIAMPolicy \
  --policy-document file://iam_policy.json

Pin the version. The policy grows over releases; a controller newer than its policy fails a new API call with AccessDenied, and a controller older than an annotation you use ignores it. Match chart appVersion ↔ policy version ↔ the image.tag.

IRSA: the ServiceAccount ↔ role mapping

The controller is a pod, so it uses IRSA, not an instance profile. eksctl does the OIDC + role + ServiceAccount dance in one command; the annotation on the SA is what actually wires it.

# 1) Ensure the cluster has an IAM OIDC provider
eksctl utils associate-iam-oidc-provider --cluster kv-eks --approve

# 2) Create the IRSA ServiceAccount (role + trust + SA annotation) in kube-system
eksctl create iamserviceaccount \
  --cluster kv-eks \
  --namespace kube-system \
  --name aws-load-balancer-controller \
  --role-name AmazonEKSLoadBalancerControllerRole \
  --attach-policy-arn arn:aws:iam::123456789012:policy/AWSLoadBalancerControllerIAMPolicy \
  --approve

Install via Helm

helm repo add eks https://aws.github.io/eks-charts
helm repo update eks

helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
  -n kube-system \
  --set clusterName=kv-eks \
  --set serviceAccount.create=false \
  --set serviceAccount.name=aws-load-balancer-controller \
  --set region=ap-south-1 \
  --set vpcId=vpc-0abc123

Verify the install before touching Ingress:

kubectl -n kube-system get deploy aws-load-balancer-controller
kubectl -n kube-system rollout status deploy/aws-load-balancer-controller
kubectl -n kube-system logs deploy/aws-load-balancer-controller | tail -20

Expected: 2/2 replicas ready and logs ending in successfully ... leader election with no AccessDenied.

Subnet tags — the auto-discovery the controller depends on

When an Ingress or Service does not name its subnets, the controller auto-discovers them by tag. Internet-facing load balancers go in subnets tagged for public ELBs; internal ones go in subnets tagged for internal ELBs. Miss the tags and you get unable to discover at least one subnet.

aws ec2 create-tags --resources subnet-pub-a subnet-pub-b \
  --tags Key=kubernetes.io/role/elb,Value=1
aws ec2 create-tags --resources subnet-prv-a subnet-prv-b \
  --tags Key=kubernetes.io/role/internal-elb,Value=1

Ingress annotations, end to end

Everything you configure about the ALB lives in the Ingress’s alb.ingress.kubernetes.io/* annotations. This is the densest, most-referenced part of the controller — enumerate it once and keep it open. The two structural choices come first: target type and scheme.

target-type: ip vs instance

This is the single most important annotation. ip registers pod IPs directly in the target group — the ALB talks straight to the pod, one hop, and it is required for Fargate (no NodePorts) and for pod-level features. instance registers node instances on a NodePort — the ALB hits a node, then kube-proxy forwards to a pod, possibly on another node.

Traffic & listener annotations

TLS: ACM certificate + SSL policy

TLS on the ALB is terminated with an ACM certificate referenced by ARN — and the number-one mistake is a certificate in the wrong Region or not yet ISSUED. The ALB and the ACM cert must be in the same Region.

Common SSL policies — prefer a TLS 1.3 policy unless a client forces older.

Health-check annotations

The health check is per target group. Point it at a real endpoint that returns a code in success-codes or every target stays unhealthy and the ALB returns 503.

Target-group attributes

Set via one annotation as key=value pairs; these tune draining, stickiness, and the balancing algorithm.

alb.ingress.kubernetes.io/target-group-attributes: >-
  deregistration_delay.timeout_seconds=30,
  stickiness.enabled=true,
  load_balancing.algorithm.type=least_outstanding_requests

Security: WAF, Shield, SGs, and auth

The controller can associate a WAFv2 web ACL, enable Shield Advanced, restrict inbound CIDRs, and even offload authentication to Cognito or an OIDC IdP at the listener — the request is authenticated before it ever reaches a pod.

Advanced routing: actions and conditions

Beyond host/path, the controller supports ALB actions (redirect, fixed 200/503 response, weighted forward for canaries) and conditions (headers, query strings, source IP) via annotations referenced by an Ingress rule using the special use-annotation backend.

IngressGroup: one ALB across many Ingresses

By default, every Ingress = its own ALB. Ten services, ten ALBs, ten hourly charges. An IngressGroup collapses multiple Ingress resources — even across namespaces — onto one shared ALB, merging their rules by order. This is the biggest cost lever on EKS ingress and the reason teams do not run an ALB per microservice.

Add group.name to each Ingress that should share the ALB; group.order sets rule precedence (lower first). Annotations that configure the load balancer itself (scheme, certificate, WAF) must be consistent across the group or the controller reports a conflict.

Guardrail: because any Ingress can join a named group and inject rules onto a shared ALB, restrict who can create Ingresses (RBAC) and consider IngressClassParams with a fixed group, or the controller flag that limits which groups are allowed. A careless group.order can shadow another team’s path.

Service type: LoadBalancer → NLB

For L4 (raw TCP/UDP, TLS passthrough, ultra-low latency, or non-HTTP protocols) you want an NLB, and you get one from a Service of type: LoadBalancer — not an Ingress. The catch: by default the legacy in-tree provider grabs type: LoadBalancer Services and makes a CLB. To have the AWS Load Balancer Controller make an NLB instead, you set aws-load-balancer-type: external (and nlb-target-type), or the modern spec.loadBalancerClass: service.k8s.aws/nlb.

apiVersion: v1
kind: Service
metadata:
  name: web-nlb
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: external
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
    service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
  type: LoadBalancer
  loadBalancerClass: service.k8s.aws/nlb   # modern, explicit; avoids the legacy CLB
  selector: { app: web }
  ports:
    - port: 80
      targetPort: 8080

ALB vs NLB — pick by layer and need.

TargetGroupBinding — bind to an existing target group

Sometimes you want Terraform (or another team) to own the ALB, listeners, and target group, and only let the controller register pods into that group. TargetGroupBinding does exactly that: point it at a targetGroupARN and a Service, and the controller keeps the group’s targets in sync (and, optionally, manages the backend SG rules) without creating the load balancer.

apiVersion: elbv2.k8s.aws/v1beta1
kind: TargetGroupBinding
metadata:
  name: web-tgb
spec:
  serviceRef:
    name: web
    port: 80
  targetGroupARN: arn:aws:elasticloadbalancing:ap-south-1:123456789012:targetgroup/web/abc123
  targetType: ip
  networking:
    ingress:
      - from:
          - securityGroup:
              groupID: sg-alb-frontend
        ports:
          - protocol: TCP
            port: 8080

ExternalDNS, readiness gates, and pod deregistration

Three finishing pieces make ingress on EKS production-safe: automatic DNS, safe rollouts, and clean draining.

ExternalDNS — Route 53 records, automatically

The AWS Load Balancer Controller creates the ALB but does not create DNS records. ExternalDNS is a separate controller that watches Ingress/Service objects and writes Route 53 records (an ALIAS to the ALB) for the host you declare. It has its own IRSA identity with route53:ChangeResourceRecordSets and ListHostedZones on the target zone.

Pod readiness gate — don’t send traffic to a pod that isn’t a healthy target yet

By default a pod is Ready as soon as its container probes pass — but the ALB target group may not have marked it healthy yet, so a rolling deploy can shift traffic to a pod the ALB will 503. The pod readiness gate ties pod readiness to target-group health: label the namespace and the controller injects a readiness gate so a pod is Ready only once it is healthy in the target group. This is essential for zero-drop rollouts.

kubectl label namespace default elbv2.k8s.aws/pod-readiness-gate-inject=enabled

Deregistration & draining

On scale-in or a rolling update, the controller deregisters the pod IP from the target group and the ALB drains in-flight requests for deregistration_delay.timeout_seconds before the target is fully removed. Pair a sensible drain window with a preStop hook and terminationGracePeriodSeconds so the pod does not exit before the ALB stops sending it new connections.

Architecture at a glance

The diagram below is the exact system you build in the lab, read left to right along the request path. A client resolves app.kloudvin.com — an ExternalDNS-created Route 53 ALIAS pointing at the ALB — and hits an internet-facing ALB on :443. The ALB’s HTTPS listener terminates TLS with an ACM certificate (and a :80 listener 301-redirects to :443), then forwards to an IP target group whose members are pod IPs, landing on pods spread across the EKS nodes in two AZs. Crucially, the ALB is not in your manifests: the AWS Load Balancer Controller, running in kube-system under an IRSA role, watches the Ingress (ingressClassName: alb, group.name: kv-shared) and provisions the ALB, listeners, target group, and rules. The six numbered badges mark where this most often breaks — no ALB / controller CrashLoop, subnet tags / IngressGroup, the ACM cert, unhealthy ip targets, 504/rollout drops, and ExternalDNS silence — each narrated in the legend as symptom · confirm · fix.

Real-world scenario

LedgerLoop, a Pune fintech, ran eight microservices on EKS behind eight separate ALBs — one per team’s Ingress — created ad hoc as services shipped. The monthly bill showed roughly ₹1,700/service just in ALB hours plus LCUs before a single byte of useful traffic, and the security team could not get a consistent WAF applied because each ALB was configured differently. Worse, a Friday deploy of the payments service caused a two-minute burst of 504s: the rollout marked new pods Ready on their liveness probe, Kubernetes shifted traffic, but the ALB target group had not finished health-checking the new pod IPs, so requests hit initial targets and timed out.

The platform team did three things. First, they consolidated onto one shared ALB with an IngressGroup: every Ingress got alb.ingress.kubernetes.io/group.name: ll-prod and a distinct group.order, all using target-type: ip, scheme: internet-facing, and a single wildcard ACM certificate for *.ledgerloop.in. Eight ALBs became one; the ELB line on the bill dropped by roughly 80%, and because the certificate and WAF now lived on one load balancer, the security team attached a WAFv2 web ACL with alb.ingress.kubernetes.io/wafv2-acl-arn once and covered everything.

Second, they killed the 504 storm by enabling the pod readiness gate — kubectl label namespace payments elbv2.k8s.aws/pod-readiness-gate-inject=enabled — so a new pod became Ready only after the ALB target group reported it healthy. The rolling update now held the old pods until the new pods were real, healthy targets; the next payments deploy shifted zero failed requests. They also set deregistration_delay.timeout_seconds=30 and a 15-second preStop sleep so draining pods finished in-flight requests.

Third, they automated DNS. Instead of a human editing Route 53 after each new service, they installed ExternalDNS with its own IRSA role scoped to the ledgerloop.in hosted zone; each Ingress carried external-dns.alpha.kubernetes.io/hostname, and the ALIAS records appeared and updated automatically. The one incident during the migration was self-inflicted and instructive: a new service’s Ingress landed with a blank ADDRESS. The controller log read couldn't auto-discover subnets — the team had added two new private subnets for capacity but forgotten to tag them kubernetes.io/role/internal-elb. Two create-tags calls later, the service joined the shared ALB. The lesson stuck: on EKS, an Ingress that produces no ALB is almost always the controller, the IRSA policy, or a subnet tag — never “Kubernetes being slow.”

Advantages and disadvantages

The controller wins decisively for any real workload on EKS: the alternative is hand-managing ALBs and re-registering targets every deploy, or living with CLB sprawl. The disadvantages are almost all operational discipline items — version-pin the chart and policy together, tag subnets, allow the ALB to reach pods, and enable the readiness gate — which is exactly what the lab and playbook below drill.

Hands-on lab

You will install the controller (IRSA + Helm), deploy an app, expose it via an Ingress that provisions an internet-facing ALB with an ACM cert and SSL redirect, verify the ALB and healthy ip targets, then add a second Ingress in the same IngressGroup — and tear it all down. aws, eksctl, helm, kubectl, and Terraform are shown. ⚠️ Cost note: an ALB is not free — it bills per hour plus LCUs (a few rupees/hour). If you create a NAT gateway or interface endpoints for node egress they bill too. Tear down when done.

Lab variables

Step 1 — OIDC provider + IAM policy + IRSA ServiceAccount

# OIDC provider (idempotent)
eksctl utils associate-iam-oidc-provider --cluster kv-eks --approve

# IAM policy (once per account)
curl -sSo iam_policy.json \
  https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.7.2/docs/install/iam_policy.json
aws iam create-policy --policy-name AWSLoadBalancerControllerIAMPolicy \
  --policy-document file://iam_policy.json

# IRSA ServiceAccount in kube-system
eksctl create iamserviceaccount --cluster kv-eks \
  --namespace kube-system --name aws-load-balancer-controller \
  --role-name AmazonEKSLoadBalancerControllerRole \
  --attach-policy-arn arn:aws:iam::123456789012:policy/AWSLoadBalancerControllerIAMPolicy \
  --approve

Step 2 — Tag the subnets

aws ec2 create-tags --resources subnet-pub-a subnet-pub-b \
  --tags Key=kubernetes.io/role/elb,Value=1
aws ec2 create-tags --resources subnet-prv-a subnet-prv-b \
  --tags Key=kubernetes.io/role/internal-elb,Value=1
# (recommended) cluster association
aws ec2 create-tags --resources subnet-pub-a subnet-pub-b subnet-prv-a subnet-prv-b \
  --tags Key=kubernetes.io/cluster/kv-eks,Value=shared

Step 3 — Install the controller via Helm

helm repo add eks https://aws.github.io/eks-charts && helm repo update eks

helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
  -n kube-system \
  --set clusterName=kv-eks \
  --set serviceAccount.create=false \
  --set serviceAccount.name=aws-load-balancer-controller \
  --set region=ap-south-1 --set vpcId=vpc-0abc123

kubectl -n kube-system rollout status deploy/aws-load-balancer-controller

Expected: deployment "aws-load-balancer-controller" successfully rolled out, 2/2 ready.

Step 4 — Deploy the app + Service + IngressClass

# app.yaml
apiVersion: apps/v1
kind: Deployment
metadata: { name: web }
spec:
  replicas: 3
  selector: { matchLabels: { app: web } }
  template:
    metadata: { labels: { app: web } }
    spec:
      containers:
        - name: web
          image: public.ecr.aws/nginx/nginx:stable
          ports: [{ containerPort: 80 }]
---
apiVersion: v1
kind: Service
metadata: { name: web }
spec:
  selector: { app: web }
  ports: [{ port: 80, targetPort: 80 }]   # ClusterIP is fine for target-type: ip
---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata: { name: alb }
spec: { controller: ingress.k8s.aws/alb }

kubectl apply -f app.yaml
kubectl label namespace default elbv2.k8s.aws/pod-readiness-gate-inject=enabled

Step 5 — Ingress that provisions an internet-facing ALB (ACM + SSL redirect)

# ingress-web.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP":80},{"HTTPS":443}]'
    alb.ingress.kubernetes.io/ssl-redirect: '443'
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:ap-south-1:123456789012:certificate/abc
    alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-TLS13-1-2-2021-06
    alb.ingress.kubernetes.io/healthcheck-path: /
    alb.ingress.kubernetes.io/success-codes: '200'
    alb.ingress.kubernetes.io/group.name: kv-shared
    alb.ingress.kubernetes.io/group.order: '10'
    external-dns.alpha.kubernetes.io/hostname: app.kloudvin.com
spec:
  ingressClassName: alb
  rules:
    - host: app.kloudvin.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service: { name: web, port: { number: 80 } }

kubectl apply -f ingress-web.yaml

Step 6 — Verify the ALB and targets

# The Ingress ADDRESS appears within ~1-2 min = the ALB DNS name
kubectl get ingress web -w

# Find the ALB the controller created (tagged with the group/cluster)
ALB_ARN=$(aws elbv2 describe-load-balancers \
  --query "LoadBalancers[?contains(LoadBalancerName, 'k8s-kvshared')].LoadBalancerArn | [0]" --output text)

# Target group + health — expect "healthy" for 3 pod IPs
TG_ARN=$(aws elbv2 describe-target-groups --load-balancer-arn $ALB_ARN \
  --query 'TargetGroups[0].TargetGroupArn' --output text)
aws elbv2 describe-target-health --target-group-arn $TG_ARN \
  --query 'TargetHealthDescriptions[].{ip:Target.Id,state:TargetHealth.State}'

# Hit it (HTTP should 301 to HTTPS)
ADDR=$(kubectl get ingress web -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
curl -s -o /dev/null -w "%{http_code}\n" http://$ADDR/        # 301
curl -s -o /dev/null -w "%{http_code}\n" -k https://$ADDR/    # 200

Expected: three healthy pod-IP targets, 301 on HTTP, 200 on HTTPS.

Step 7 — Add a second Ingress in the SAME IngressGroup

Create a second app (api) and expose it on /api via a second Ingress sharing group.name: kv-shared. No new ALB is created — the rule is merged onto the existing one.

# ingress-api.yaml (after deploying an "api" Service on port 80)
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/group.name: kv-shared
    alb.ingress.kubernetes.io/group.order: '20'
spec:
  ingressClassName: alb
  rules:
    - host: app.kloudvin.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service: { name: api, port: { number: 80 } }

kubectl apply -f ingress-api.yaml
# Same ALB, now two rules; confirm only ONE ALB exists for the group
aws elbv2 describe-load-balancers \
  --query "length(LoadBalancers[?contains(LoadBalancerName,'k8s-kvshared')])"   # -> 1
aws elbv2 describe-rules --listener-arn <https-listener-arn> \
  --query 'Rules[].Conditions'

Step 8 — Teardown

⚠️ Delete the Ingresses first so the controller tears down the ALB; if you delete the controller while an Ingress exists, the ALB is orphaned and keeps billing.

The same install in Terraform

# Assumes the EKS cluster + OIDC provider already exist (data sources)
data "aws_eks_cluster" "this" { name = "kv-eks" }
data "aws_eks_cluster_auth" "this" { name = "kv-eks" }

provider "helm" {
  kubernetes {
    host                   = data.aws_eks_cluster.this.endpoint
    cluster_ca_certificate = base64decode(data.aws_eks_cluster.this.certificate_authority[0].data)
    token                  = data.aws_eks_cluster_auth.this.token
  }
}

# IAM policy from the downloaded JSON
resource "aws_iam_policy" "lbc" {
  name   = "AWSLoadBalancerControllerIAMPolicy"
  policy = file("${path.module}/iam_policy.json")
}

# IRSA role trusting the controller's ServiceAccount via the cluster OIDC provider
data "aws_iam_openid_connect_provider" "eks" {
  url = data.aws_eks_cluster.this.identity[0].oidc[0].issuer
}

data "aws_iam_policy_document" "trust" {
  statement {
    actions = ["sts:AssumeRoleWithWebIdentity"]
    effect  = "Allow"
    principals {
      type        = "Federated"
      identifiers = [data.aws_iam_openid_connect_provider.eks.arn]
    }
    condition {
      test     = "StringEquals"
      variable = "${replace(data.aws_iam_openid_connect_provider.eks.url, "https://", "")}:sub"
      values   = ["system:serviceaccount:kube-system:aws-load-balancer-controller"]
    }
    condition {
      test     = "StringEquals"
      variable = "${replace(data.aws_iam_openid_connect_provider.eks.url, "https://", "")}:aud"
      values   = ["sts.amazonaws.com"]
    }
  }
}

resource "aws_iam_role" "lbc" {
  name               = "AmazonEKSLoadBalancerControllerRole"
  assume_role_policy = data.aws_iam_policy_document.trust.json
}
resource "aws_iam_role_policy_attachment" "lbc" {
  role       = aws_iam_role.lbc.name
  policy_arn = aws_iam_policy.lbc.arn
}

resource "helm_release" "lbc" {
  name       = "aws-load-balancer-controller"
  repository = "https://aws.github.io/eks-charts"
  chart      = "aws-load-balancer-controller"
  namespace  = "kube-system"
  version    = "1.7.2" # chart version; pin it

  set {
    name  = "clusterName"
    value = "kv-eks"
  }
  set {
    name  = "region"
    value = "ap-south-1"
  }
  set {
    name  = "vpcId"
    value = "vpc-0abc123"
  }
  set {
    name  = "serviceAccount.create"
    value = "true"
  }
  set {
    name  = "serviceAccount.name"
    value = "aws-load-balancer-controller"
  }
  set {
    name  = "serviceAccount.annotations.eks\\.amazonaws\\.com/role-arn"
    value = aws_iam_role.lbc.arn
  }
  depends_on = [aws_iam_role_policy_attachment.lbc]
}

The provider is configured from the cluster endpoint + CA + token, which only exist after the cluster does — so on a cold apply that also builds the cluster, split into two applies (cluster first, then this) or you will hit Kubernetes cluster unreachable. terraform destroy removes the release and IRSA, but the ALB is created by the controller, not this state — delete Ingresses first.

Common mistakes & troubleshooting

This is the section you will return to. Each row maps a real failure to the exact command that confirms it and the fix. The controller’s own logs (kubectl -n kube-system logs deploy/aws-load-balancer-controller) and the Ingress events (kubectl describe ingress <name>) are your two primary instruments.

Controller log & event error reference

ALB HTTP status-code reference (what the ALB itself returns)

The two nastiest real failures deserve spelling out. The blank-ADDRESS Ingress (rows 1–3) is the classic first encounter: an Ingress applies cleanly, kubectl get ingress shows no ADDRESS, and nothing errors at the kubectl layer because the controller is where reconciliation happens. The discipline is always the same — kubectl -n kube-system logs deploy/aws-load-balancer-controller and kubectl describe ingress <name>; the answer is almost always controller-not-running, AccessDenied from a bad IRSA, or couldn't auto-discover subnets from a missing tag. The target-type: ip security-group trap (rows 4–5) is the sneakiest at scale: because ip mode makes the ALB talk directly to pod IPs (not to a node NodePort), the ALB’s traffic must be allowed into the pods’ backend security group on the container port. Teams that came from instance mode open the node SG, see targets stay unhealthy, and burn an hour before realising the traffic now lands on the pod ENI’s SG. The controller can manage this backend SG rule for you — but only if you did not hand it a custom frontend SG without also setting manage-backend-security-group-rules.

Best practices

• Version-pin the trio together — Helm chart, controller image, and the iam_policy.json — and upgrade them as a set; drift is the root of “annotation ignored” and “new AccessDenied” bugs.
• Run the controller as an IRSA workload, never on the node instance role — least privilege and clean auditing of who created which load balancer.
• Tag subnets once in your VPC IaC (role/elb, internal-elb, cluster/<name>) so every future Ingress auto-discovers placement — no per-Ingress subnets annotation.
• Default to target-type: ip for direct pod routing (and it is mandatory on Fargate); reach for instance only when you deliberately want NodePort semantics or fewer target registrations at very large scale.
• Collapse apps onto one ALB with an IngressGroup where scheme/cert/WAF are shared — it is the single biggest ingress cost lever on EKS.
• Always enable the pod readiness gate (ip mode + namespace label) so rolling deploys add pods to the ALB only when they are truly healthy targets — this eliminates deploy-time 5xx.
• Terminate TLS with ACM in the ALB’s Region, prefer a TLS 1.3 SSL policy, and set ssl-redirect: '443' so plain HTTP always bounces to HTTPS.
• Let the controller manage the backend SG rule (or set manage-backend-security-group-rules) so the ALB can reach pods on the container port — the most common 503 cause in ip mode.
• Automate DNS with ExternalDNS (its own scoped IRSA) rather than hand-editing Route 53 after each service.
• Use TargetGroupBinding when you want Terraform to own the ALB/TG and the controller to own only pod registration — it keeps the load balancer in IaC state.
• Restrict who can create Ingresses (RBAC) and constrain allowed group.names so a careless group.order cannot shadow another team’s routes on a shared ALB.
• Delete Ingresses before uninstalling the controller (or before terraform destroy) so ALBs are torn down, not orphaned and billing.

Security notes

Ingress on EKS is a public front door; secure it at identity, network, and edge layers.

Cost & sizing

You pay for the load balancers the controller creates (ALB/NLB hours + LCUs/NLCUs), plus data transfer, plus any NAT/endpoints node egress and, if enabled, WAF and Shield Advanced. The controller itself is just two small pods. The EKS control plane has its own hourly charge (separate topic).

Worked example — the ingress layer for a 10-service platform, contrasting the two models over ~730 hr/mo:

The headline lever is unmistakable: an IngressGroup turns ten ALBs into one and collapses the ingress bill by roughly 8×, while also letting one WAF ACL and one certificate cover everything. Secondary levers: keep NLB cross-zone off unless you need perfectly even spread (it adds per-GB data cost), scope Shield Advanced to only the ALBs that need it, and prefer ip targets to avoid an extra SNAT hop. On us-east-1 the same numbers run roughly 15–20% lower.

Interview & exam questions

Q1. What does the AWS Load Balancer Controller do, and what did it replace? It runs in-cluster and reconciles Kubernetes objects into AWS load balancers: an Ingress (ingressClassName: alb) into an ALB, and a Service type: LoadBalancer into an NLB. It replaces the legacy in-tree cloud provider, which only made a Classic Load Balancer per Service and had no Ingress support. (SAA-C03, DVA-C02)

Q2. What is the difference between target-type: ip and instance? ip registers pod IPs directly in the target group (via the VPC CNI), so the ALB talks straight to the pod and it works on Fargate; instance registers node instances on a NodePort and relies on kube-proxy for the final hop. ip needs the pods’ backend security group to allow the ALB. (SAA-C03, SOA-C02)

Q3. How does the controller get AWS permissions? Through IRSA: its kube-system/aws-load-balancer-controller ServiceAccount is annotated with an IAM role ARN, and the cluster’s OIDC provider lets the pod assume that role via AssumeRoleWithWebIdentity. The role has the AWSLoadBalancerControllerIAMPolicy. (DVA-C02, SCS-C02)

Q4. Your Ingress has a blank ADDRESS and no ALB appears. How do you diagnose it? Check the controller is running (kubectl -n kube-system get deploy aws-load-balancer-controller), read its logs for AccessDenied or couldn't auto-discover subnets, and kubectl describe ingress for events. The usual causes are controller-not-installed, bad IRSA, or missing subnet tags. (SOA-C02)

Q5. What subnet tags does the controller need and why? kubernetes.io/role/elb=1 on public subnets (internet-facing LBs) and kubernetes.io/role/internal-elb=1 on private subnets (internal LBs), so the controller can auto-discover where to place the load balancer; the kubernetes.io/cluster/<name> tag associates subnets with the cluster. (SAA-C03, SOA-C02)

Q6. How do you serve many apps from one ALB, and why? Give each Ingress the same alb.ingress.kubernetes.io/group.name (an IngressGroup), with distinct group.order for rule precedence. The controller merges them onto one shared ALB, cutting cost dramatically versus one ALB per Ingress and letting a single cert/WAF cover all. (SAA-C03)

Q7. How do you make a Service produce an NLB rather than a CLB? Set service.beta.kubernetes.io/aws-load-balancer-type: external with nlb-target-type (or, modern, spec.loadBalancerClass: service.k8s.aws/nlb). Without either, the legacy in-tree provider makes a Classic Load Balancer. (SAA-C03, DVA-C02)

Q8. What is a TargetGroupBinding and when would you use it? A CRD that binds a Kubernetes Service to an existing target group ARN; the controller then only manages target registration (and optionally backend SG rules), not the load balancer. Use it when Terraform owns the ALB/TG and you want it in IaC state. (DVA-C02)

Q9. How do you attach TLS to an ALB Ingress, and what is the most common mistake? Set alb.ingress.kubernetes.io/certificate-arn to an ACM cert and include {"HTTPS":443} in listen-ports. The most common mistake is a certificate in the wrong Region or not ISSUED, which silently yields no HTTPS listener. (SOA-C02, SCS-C02)

Q10. What is the pod readiness gate and what problem does it solve? Labeling a namespace elbv2.k8s.aws/pod-readiness-gate-inject=enabled makes the controller add a readiness gate so a pod is Ready only when it is healthy in the ALB target group. This prevents rolling deploys from shifting traffic to pods the ALB has not yet health-checked, eliminating deploy-time 5xx. (DVA-C02, SOA-C02)

Q11. Your ALB returns 503 with all targets unhealthy, but the app is fine. Name two likely causes. The pods’ backend security group does not allow the ALB on the container port (in ip mode the ALB reaches the pod directly), or the health-check path/matcher is wrong so the app returns a non-200. (SAA-C03, SOA-C02)

Q12. Why can deleting the controller before deleting Ingresses cost you money? The ALB is created out-of-band by the controller; if the controller is gone while an Ingress still exists, nothing reconciles the ALB away — it becomes orphaned and keeps billing hourly. Always delete Ingresses (or destroy the Ingress Terraform resource) first. (SOA-C02)

Quick check

1. Kubernetes ships no Ingress implementation — so what actually turns your Ingress into an ALB on EKS?
2. You need the ALB to send traffic straight to pods (and you run on Fargate). Which target-type do you set, and what must the pods’ security group allow?
3. You have ten services and ten ALBs. What one annotation collapses them onto a single ALB, and what sets rule order?
4. Your HTTPS listener never appears though you set certificate-arn. Name the two most likely reasons.
5. A rolling deploy briefly returns 5xx as new pods come up. What feature fixes it, and how do you enable it?

Answers

1. The AWS Load Balancer Controller — an in-cluster Deployment that watches Ingresses (ingressClassName: alb) and provisions/reconciles the ALB, listeners, target groups, and rules.
2. target-type: ip (mandatory on Fargate). The pods’ backend security group must allow the ALB’s frontend SG on the container port, since the ALB talks directly to pod IPs.
3. alb.ingress.kubernetes.io/group.name (an IngressGroup) shares one ALB; group.order sets rule precedence (lower first).
4. The ACM certificate is in the wrong Region (must match the ALB) or is not ISSUED; or HTTPS is not in listen-ports ({"HTTPS":443} missing).
5. The pod readiness gate — label the namespace elbv2.k8s.aws/pod-readiness-gate-inject=enabled (with target-type: ip) so a pod is Ready only when it is a healthy ALB target.

Glossary

Next steps

• Build the cluster first if you have not: EKS Cluster Setup with eksctl (Hands-On) gives you the cluster, node group, and OIDC provider this article assumes.
• Master the identity the controller relies on: EKS IRSA: Pod IAM Permissions (Hands-On) explains the ServiceAccount ↔ role ↔ OIDC trust that also secures your app pods.
• Go deep on the load balancer itself: Application Load Balancer & Target Groups Hands-On covers listeners, rules, target-group attributes, and health-check reason codes the controller drives — and ALB 502/503/504 Troubleshooting for 5xx incidents.
• Automate the DNS names: Route 53 Records & Routing Policies (Hands-On) is the reference behind the ALIAS records ExternalDNS creates.
• Reconsider the platform if needs change: ECS vs EKS vs Fargate: Choosing Your Container Path and AWS Compute Compared: EC2, Lambda, ECS & EKS.