Kubernetes AWS Load Balancer Controller

The AWS Load Balancer Controller integrates Kubernetes ingress and service resources with AWS Application Load Balancers (ALB) and Network Load Balancers (NLB). For teams running Kubernetes on AWS, it is one of the most natural ways to expose traffic using AWS-managed load balancing.

It is especially useful if you want to stay close to native AWS networking features and reduce the amount of additional ingress infrastructure you run in-cluster.

Why Use the AWS Load Balancer Controller?

The controller gives you:

• managed AWS load balancers for ingress and service exposure
• support for ALB and NLB use cases
• ingress grouping to share a single ALB across multiple services
• direct alignment with AWS networking, scaling, and availability features

It is a good fit for teams that want AWS-native ingress rather than a separate ingress stack with its own proxy layer.

Installation

The exact installation steps evolve over time, so it is best to follow the current project documentation for the chart, CRDs, and IAM policy. In most EKS clusters, the recommended shape is:

1. Create the IAM policy required by the controller.
2. Bind that policy to a service account using IRSA.
3. Install the controller with Helm.

Add the Helm repository:

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

Then install the controller:

helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
  -n kube-system \
  --set clusterName=<cluster-name> \
  --set serviceAccount.create=false \
  --set serviceAccount.name=aws-load-balancer-controller

For current IAM policy and install guidance, use the official docs: AWS Load Balancer Controller installation.

Ingress

When you use the controller with ingress resources, it can create ALBs and manage the listener rules for you.

A simple example looks like this:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echoserver
  namespace: default
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/group.name: myalb
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: echoserver
                port:
                  number: 80

By default, one ingress can create one ALB, but alb.ingress.kubernetes.io/group.name lets you group multiple ingress resources onto the same ALB where that model makes sense.

Useful Ingress Annotations

Some of the most useful annotations are:

• alb.ingress.kubernetes.io/group.name
• alb.ingress.kubernetes.io/security-groups
• alb.ingress.kubernetes.io/subnets
• alb.ingress.kubernetes.io/scheme
• alb.ingress.kubernetes.io/target-type

For a full list, use the official reference: Ingress annotations.

Troubleshooting

If the controller creates the load balancer but traffic does not reach the pods, the first things to check are:

• service type and target type alignment
• subnet discovery tags
• security groups attached to the ALB
• ingress annotations and class
• controller logs in kube-system

Older setups sometimes required NodePort for certain controller patterns. On current versions, target type and service wiring are the more important things to validate first.

Considerations

The AWS Load Balancer Controller is limited by what AWS load balancers support. That means it is a strong fit for many workloads, but it may not be the best option if you need more advanced ingress features such as complex rewrites or behaviours that are easier to express in a dedicated proxy layer.

Conclusion

If your workloads fit well with AWS-native networking, the AWS Load Balancer Controller is a strong ingress option for Kubernetes on AWS. It keeps the traffic path close to the platform, integrates neatly with ALB and NLB capabilities, and can simplify ingress management when its feature set matches what your applications need.