AWS Load Balancer Controller: one reconciler, three resource kinds, two load balancer types
A Kubernetes controller for Elastic Load Balancers
At a glance
- What is it?
- AWS Load Balancer Controller reconciles Ingress, Service and Gateway resources into AWS load balancers, and the AWS API surface it links against in go.mod is far wider than those three mappings. That width is the thing to check before adopting it.
- Who is it for?
- Adopt AWS Load Balancer Controller when the cluster runs on AWS and its Ingress, Service or Gateway objects already describe the ALB and NLB resources you want, and when the IAM identity behind the controller carries permissions for ACM, Route 53, Shield, App Mesh, WAF and Global Accelerator rather than EC2 and ELB alone.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on November 14, 2026, and from our analysis. They are not legal advice.
Star history
- kubernetes-sigs/aws-load-balancer-controller4,345 ★ · +17
| Repository | 2026-09-23 | 2026-11-14 |
|---|---|---|
| kubernetes-sigs/aws-load-balancer-controller | 4.3k | 4.3k |
17 Stars in the last 52 days, measured from the daily GitHub snapshot. Compare with other projects
Editorial analysis
One controller, three resource kinds, two load balancer families
The mapping is the whole design, and it is short enough to state exactly. Ingress resources become Application Load Balancers. Service resources become Network Load Balancers. Gateway resources become either, and the choice is left to the Gateway configuration rather than to the resource kind. That is three entries, and the interesting engineering sits in what the controller does after it reads them.
The repository layout shows where the weight falls. There is a controllers/ directory, a webhooks/ directory, and a pkg/ tree that carries most of the code. The module path is sigs.k8s.io/aws-load-balancer-controller/v3, so this is the third major line of the project, and a webhooks/ directory means the controller is not only reconciling on a timer. It validates and mutates objects before anything reaches AWS.
The AWS API surface in go.mod is the real specification
Read go.mod before the README and you learn what the controller touches. The obvious entries are github.com/aws/aws-sdk-go-v2/service/ec2 v1.173.0 and elasticloadbalancingv2 v1.54.0. Then there are acm v1.28.4, route53 v1.62.1, servicediscovery v1.31.7, and globalaccelerator v1.26.3.
Further down sit appmesh v1.27.7, shield v1.27.3, wafregional v1.23.3 and wafv2 v1.51.4, plus resourcegroupstaggingapi and sts for identity. A dependency is not proof that every code path runs by default. It is proof that the IAM policy attached to the controller's service account can be much wider than a first-time user expects, and that removing or narrowing permissions after the fact may break features they never enabled.
Where to get it: the README has no install command
The README contains no kubectl apply, no helm install, and no image reference. It points readers to the live documentation at kubernetes-sigs.github.io/aws-load-balancer-controller and to CONTRIBUTING.md for contributors.
What the repository does contain is the chart. The Makefile copies Gateway API CRDs into helm/aws-load-balancer-controller/crds/gateway-crds.yaml, which tells you the Helm chart directory is helm/aws-load-balancer-controller and that Gateway API support ships as bundled CRDs inside that chart. The Makefile's default image is public.ecr.aws/eks/aws-load-balancer-controller:v3.6.2, and IMG_PLATFORM lists linux/amd64 and linux/arm64. Anyone publishing a mirror should match those two.
A badge still pointing at the pre-rebrand image name
The README carries a Docker Hub badge whose target is hub.docker.com/r/amazon/aws-alb-ingress-controller. The repository was renamed from AWS ALB Ingress Controller to AWS Load Balancer Controller, and SIG-AWS accepted the donation on June 1, 2018. The badge kept the old name.
That is a small detail a skim misses, and it has a consequence. Anyone who resolves the badge and pulls amazon/aws-alb-ingress-controller is deploying a repository name from before the rename, not the image the Makefile builds. The correct artifact for the current line is the ECR path. When writing installation notes for a team, write the ECR reference rather than copying a link out of the README.
Gateway API support is packaged apart from the base CRDs
The Makefile separates Gateway API CRDs and AGA CRDs out of config/crd/bases rather than shipping one flat list. MOVE_GATEWAY_CRDS moves config/crd/bases/gateway.k8s.aws_* into config/crd/gateway/, and a second rule does the same for aga.k8s.aws_* into config/crd/aga/ before the combined Gateway CRDs are copied into the Helm chart.
Two consequences follow. Anyone applying CRDs by hand from config/crd/bases gets the controller's own custom resources but not the Gateway API group, and then wonders why Gateway objects are rejected by the API server. And an upgrade that only diffs the base directory misses changes to the Gateway and AGA sets entirely.
Go 1.26.5 and a static PIE build narrow your build environment
go.mod declares go 1.26.5, and the Makefile exports GOTOOLCHAIN as go$(GOLANG_VERSION), where the value is read from the .go-version file. A developer with an older Go toolchain installed does not silently downgrade; the toolchain directive selects another one, which matters on hosts with no outbound network access to the module proxy.
The Dockerfile shows the shipped binary is built with -buildmode=pie and the tag set 'osusergo,netgo,static_build', linked externally as static-pie with RELRO and NOW flags set through CGO_LDFLAGS. The final stage copies one file, /out/controller, and sets ENTRYPOINT ["/controller"].
Where it is the wrong tool
The controller is AWS-only. There is no code path in the repository layout for GKE, AKS or any other provider; the AWS SDK dependencies sit under the service/ tree with no abstraction layer visible above them, and the load balancer types it provisions are ALB and NLB, not Azure Load Balancer or Google Cloud Load Balancing. A multi-cloud cluster that wants one ingress abstraction across all of its clusters cannot use this.
There is a second, quieter case. WAFv2, App Mesh, Shield and Global Accelerator all appear as dependencies, so features exist that attach AWS services to the load balancers this controller creates. If another team in the same account already owns WAF web ACL associations or Global Accelerator accelerators, two controllers writing the same load balancer attributes will produce a reconcile loop neither side wrote. Check ownership before installing, not after the first duplicated rule appears.
The latest release, v3.6.2, is dated 2026-10-25 and the last push was on 2026-10-28, so this is a project with current releases, under the Apache-2.0 licence with no copyleft obligations on the consuming cluster.
Editorial conclusion
Adopt AWS Load Balancer Controller when the cluster runs on AWS and its Ingress, Service or Gateway objects already describe the ALB and NLB resources you want, and when the IAM identity behind the controller carries permissions for ACM, Route 53, Shield, App Mesh, WAF and Global Accelerator rather than EC2 and ELB alone. Leave it out of a multi-cloud cluster, since no provider other than AWS appears in the code or the SDK dependencies, and leave it out where another component in the same account already writes WAF associations or accelerator rules to the same load balancer. Before installing, confirm two things: that your cluster version accepts the Gateway API CRDs the chart copies in from helm/aws-load-balancer-controller/crds/gateway-crds.yaml, and that your IAM policy covers the AWS services listed in go.mod rather than the two you assumed were needed.
Frequently asked questions
what is aws load balancer controller
It is a Kubernetes controller that manages Elastic Load Balancers for a cluster, satisfying Ingress resources with Application Load Balancers, Service resources with Network Load Balancers, and Gateway resources with either type. It was formerly called the AWS ALB Ingress Controller.
how aws load balancer controller works
It watches Kubernetes resources and provisions the matching AWS load balancer for each. The repository pairs a controllers/ tree with a webhooks/ tree, so incoming objects are handled by admission webhooks before the reconciler acts on them.
how to install aws load balancer controller
The README contains no install command and points to the live documentation at kubernetes-sigs.github.io/aws-load-balancer-controller. The Helm chart lives in the repository at helm/aws-load-balancer-controller, and the repository Makefile's default image is public.ecr.aws/eks/aws-load-balancer-controller:v3.6.2.
how to use aws load balancer controller
You create Ingress, Service or Gateway objects in the cluster and the controller provisions the load balancer for each resource kind. Which features are available depends on the AWS permissions granted to the controller's IAM identity, and go.mod pulls in ACM, Route 53, Shield, App Mesh, WAF and Global Accelerator clients alongside EC2 and ELB.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/kubernetes-sigs-aws-load-balancer-controller)Star history chart for your README
[](https://hysenlabs.com/projects/kubernetes-sigs-aws-load-balancer-controller)Was this useful?