Upgrade & Secure Your Future with DevOps, SRE, DevSecOps, MLOps!
We spend hours scrolling social media and waste money on things we forget, but won’t spend 30 minutes a day earning certifications that can change our lives.
Master in DevOps, SRE, DevSecOps & MLOps by DevOps School!
Learn from Guru Rajesh Kumar and double your salary in just one year.
Here is a comprehensive, step-by-step tutorial on the AWS Load Balancer Controller for Kubernetes. This guide covers everything from the fundamentals to advanced, production-grade topics. Suitable for both beginners and seasoned DevOps engineers.
AWS Load Balancer Controller for Kubernetes: The Complete Guide
Table of Contents
- Introduction: What is AWS Load Balancer Controller?
- How It Works & Key Concepts
- Prerequisites
- IAM Permissions: What’s Required?
- Installation (Helm & YAML)
- Setting Up Ingress with ALB and NLB
- Annotating Services and Ingress Resources
- Configuring SSL/HTTPS with ACM
- Managing DNS with Route 53
- Advanced Routing Examples
- Target Group Bindings
- Security Best Practices
- Monitoring and Logging
- Troubleshooting Tips
- Real-World Use Cases
- Complete YAML Examples
- Summary & FAQ
1. Introduction: What is AWS Load Balancer Controller?
The AWS Load Balancer Controller is an open-source Kubernetes controller that automatically provisions and manages Elastic Load Balancers (ELBs)—specifically, Application Load Balancers (ALB) and Network Load Balancers (NLB)—in AWS for your Kubernetes workloads. It replaces the legacy ALB Ingress Controller and is the default for modern AWS EKS clusters.
2. How It Works & Key Concepts
- Ingress: Kubernetes resource defining HTTP/HTTPS routing to services.
- Controller: Watches Ingress, Service, and custom resources, then creates ALB/NLB as needed.
- ALB: Best for HTTP/HTTPS and advanced Layer 7 routing.
- NLB: Best for TCP/UDP traffic, high performance, static IPs.
3. Prerequisites
- AWS EKS (recommended) or Kubernetes cluster on AWS.
kubectl
,helm
, and AWS CLI installed.- AWS IAM user/role with sufficient permissions.
- (Optional) ACM certificate for HTTPS.
4. IAM Permissions: What’s Required?
The controller needs to manage AWS resources. Create an IAM policy for it:
Sample Policy (attach to controller’s service account):
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticloadbalancing:*",
"ec2:Describe*",
"ec2:CreateSecurityGroup",
"ec2:CreateTags",
"ec2:AuthorizeSecurityGroupIngress",
"iam:CreateServiceLinkedRole",
"acm:DescribeCertificate",
"acm:ListCertificates",
"acm:GetCertificate",
"waf-regional:GetWebACLForResource",
"waf-regional:AssociateWebACL",
"waf-regional:DisassociateWebACL",
"tag:GetResources",
"tag:TagResources",
"shield:GetSubscriptionState",
"shield:DescribeProtection",
"shield:CreateProtection",
"shield:DeleteProtection"
],
"Resource": "*"
}
]
}
Code language: JSON / JSON with Comments (json)
Attach this to an IAM role (using IRSA—IAM Roles for Service Accounts) in EKS, or use an instance profile.
5. Installation (Helm & YAML)
A. With Helm (Recommended)
# Add EKS Helm repo
helm repo add eks https://aws.github.io/eks-charts
helm repo update
# Create a namespace (if not exists)
kubectl create namespace kube-system
# Install the controller (replace clusterName with your cluster)
helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
-n kube-system \
--set clusterName=<YOUR_CLUSTER_NAME> \
--set serviceAccount.create=false \
--set serviceAccount.name=aws-load-balancer-controller
Code language: HTML, XML (xml)
Note: You need to pre-create a Kubernetes service account with the right IAM role attached.
B. With YAML
While Helm is strongly recommended, you can download YAML manifests from the releases page and apply them:
kubectl apply -f <controller-manifest>.yaml
Code language: HTML, XML (xml)
6. Setting Up Ingress with ALB and NLB
A. ALB (HTTP/HTTPS)
Example Ingress YAML:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-app
namespace: default
annotations:
kubernetes.io/ingress.class: alb
alb.ingress.kubernetes.io/scheme: internet-facing
spec:
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: my-app
port:
number: 80
Code language: JavaScript (javascript)
B. NLB (TCP/UDP)
For NLB, annotate a Service
:
apiVersion: v1
kind: Service
metadata:
name: my-tcp-service
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
spec:
type: LoadBalancer
ports:
- port: 3306
targetPort: 3306
protocol: TCP
selector:
app: mysql
Code language: JavaScript (javascript)
7. Annotating Services and Ingress Resources
- ALB Ingress annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
(orinternal
)alb.ingress.kubernetes.io/certificate-arn: <arn>
(for SSL)alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
alb.ingress.kubernetes.io/target-type: ip|instance
- NLB Service annotation:
service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
See all supported annotations.
8. Configuring SSL/HTTPS with ACM
- Request or import an ACM certificate in the AWS console (must be in the same region as EKS).
- Add to Ingress annotation:
alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:REGION:ACCOUNT:certificate/1234abcd-... alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
- Controller will provision an ALB listener on 443 with the cert.
9. Managing DNS with Route 53
- After creating the Ingress, find the ALB DNS name:
kubectl get ingress
- In Route 53, create a CNAME (or alias) record pointing your domain to the ALB’s DNS.
- For HTTPS, ensure your certificate matches the domain.
10. Advanced Routing Examples
A. Path-based Routing
spec:
rules:
- http:
paths:
- path: /api/*
backend:
service:
name: api-svc
port:
number: 80
- path: /web/*
backend:
service:
name: web-svc
port:
number: 80
Code language: JavaScript (javascript)
B. Host-based Routing
spec:
rules:
- host: api.example.com
http:
paths:
- path: /*
backend:
service:
name: api-svc
port:
number: 80
Code language: CSS (css)
11. Target Group Bindings
TargetGroupBinding is a CRD that lets you directly attach services/pods to AWS Target Groups (for advanced/legacy scenarios).
Example:
apiVersion: elbv2.k8s.aws/v1beta1
kind: TargetGroupBinding
metadata:
name: my-tgb
spec:
serviceRef:
name: my-app
port: 80
targetGroupARN: arn:aws:elasticloadbalancing:region:acct:targetgroup/...
12. Security Best Practices
- Use IRSA (IAM Roles for Service Accounts) for least-privilege access.
- Limit public (internet-facing) ALBs to only what’s needed.
- Restrict access with security groups.
- Rotate and scope ACM certificates properly.
- Use WAF for additional security on ALB.
13. Monitoring and Logging
- ALB access logs: Enable via AWS console or annotation (
alb.ingress.kubernetes.io/load-balancer-attributes: access_logs.s3.enabled=true,...
) - CloudWatch: ALB/NLB logs and metrics.
- Kubernetes events:
kubectl get events -A | grep LoadBalancer
- Controller logs:
kubectl logs deployment/aws-load-balancer-controller -n kube-system
14. Troubleshooting Tips
- No ALB provisioned? Check Ingress annotations, controller logs, IAM permissions.
- SSL/TLS errors? Double-check ACM certificate region/domain.
- Ingress stuck in “pending”? Usually IAM or subnet/tagging issues.
- 404/502 errors? Validate Service selectors, pod health, security groups.
15. Real-World Use Cases
- Public web applications with HTTPS, domain-based routing.
- Multi-tenant platforms with path or host-based traffic splitting.
- Internal APIs behind a private ALB or NLB.
- Hybrid architectures connecting legacy systems and modern apps.
16. Complete YAML Examples
A. Simple ALB Ingress (HTTP)
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: http-example
annotations:
kubernetes.io/ingress.class: alb
alb.ingress.kubernetes.io/scheme: internet-facing
spec:
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: my-app
port:
number: 80
B. HTTPS Ingress with ACM
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: https-example
annotations:
kubernetes.io/ingress.class: alb
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:REGION:ACCOUNT:certificate/ID
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP":80}, {"HTTPS":443}]'
spec:
rules:
- host: www.example.com
http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: my-app
port:
number: 80
Code language: JavaScript (javascript)
C. NLB for TCP
apiVersion: v1
kind: Service
metadata:
name: tcp-nlb-example
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
spec:
type: LoadBalancer
ports:
- port: 5432
targetPort: 5432
protocol: TCP
selector:
app: my-db
Code language: JavaScript (javascript)
17. Summary & FAQ
Summary
- The AWS Load Balancer Controller enables seamless ALB and NLB provisioning for Kubernetes workloads.
- Install via Helm, set up IRSA/IAM, and use Ingress/Service annotations to manage AWS load balancers.
- Supports advanced routing, SSL, security, and monitoring.
FAQ
Q1: Can I use both ALB and NLB in the same cluster?
A: Yes, configure ALB via Ingress and NLB via Service annotations.
Q2: Do I need to manually delete ALBs/NLBs if I delete the Ingress/Service?
A: No, the controller handles cleanup automatically.
Q3: How do I troubleshoot if no ALB is created?
A: Check controller logs, IAM permissions, subnet tags, and annotation spelling.
Q4: How do I update the controller?
A: Use Helm upgrade commands or apply new YAML manifests.
Q5: Is it production-ready?
A: Yes! It’s the AWS-recommended approach for EKS.
Further Reading: