"Three load balancers walk into a cloud... Which one do you choose?"
When building apps on AWS, choosing the right load balancer isn’t just a tech decision — it's the difference between blazing-fast traffic routing and a clogged request pipeline.
In this post, we’ll break down AWS's 3 load balancer types — ALB, NLB, and CLB — in beginner-friendly terms, backed by real-world analogies and practical use cases.
Ready to route your traffic like a pro? Let’s go. 🚦
🚀 What Is a Load Balancer?
A load balancer is like a smart traffic cop that:
- Distributes incoming traffic to healthy backend servers (EC2s, containers, etc.)
- Helps scale apps
- Increases fault tolerance
- Ensures high availability
Think of it like a receptionist at a clinic directing patients (users) to available doctors (EC2s).
🧠 Meet the Trio: ALB, NLB, CLB
1. ALB (Application Load Balancer)
- Works at Layer 7 (Application Layer)
- Smart routing: based on URL, headers, methods, etc.
- Best for HTTP/HTTPS apps, REST APIs, microservices
- Supports WebSockets, path-based routing, and host-based routing
2. NLB (Network Load Balancer)
- Works at Layer 4 (Transport Layer)
- Handles millions of requests/sec with ultra-low latency
- Ideal for TCP, TLS, and UDP traffic
- Supports static IP and Elastic IP
3. CLB (Classic Load Balancer)
- The OG balancer (pre-2016)
- Mix of Layer 4 and Layer 7
- Legacy workloads
- Not recommended for new architectures
🧭 Real-Life Analogy: Choosing the Right Receptionist
- ALB = Receptionist who listens to patient symptoms and directs based on specialization (e.g., "Go to ENT")
- NLB = Receptionist who routes based only on department number (e.g., "Cardiology = Room 5")
- CLB = Old receptionist who does both jobs but isn’t as efficient
📊 Feature Comparison Table
Feature | ALB | NLB | CLB |
---|---|---|---|
Layer | 7 (HTTP/HTTPS) | 4 (TCP, UDP, TLS) | 4 & 7 |
Target Types | Instance, IP, Lambda | Instance, IP | Instance |
Protocol Support | HTTP, HTTPS, WebSockets | TCP, UDP, TLS | HTTP, HTTPS, TCP |
Routing | Host, Path, Headers | IP:Port | Basic |
Performance | Good | High (millions of req/sec) | Moderate |
SSL Offloading | Yes | Yes | Yes |
Static IP Support | No | Yes | No |
Health Checks | App-level (HTTP) | Network-level (TCP) | Basic |
Use for Lambda Functions | ✅ Yes | ❌ No | ❌ No |
🧰 Use Cases: When to Use What?
✅ Use ALB When:
- You're running microservices or containerized apps (like ECS or EKS)
- You need host/path-based routing (e.g.,
/api
,/blog
) - You want to serve HTTPS traffic + SSL termination
- You need to route to Lambda functions
✅ Use NLB When:
- You need extremely low latency and high throughput
- You’re handling TCP or UDP traffic (e.g., game servers, VPNs)
- You require static IP addresses
- You want to support TLS passthrough
🚫 Avoid CLB Unless:
- You're dealing with legacy apps that were built around CLB
- You need a quick and dirty setup for basic web hosting (still not recommended long-term)
🧪 Quick Setup Tip (ALB + ECS)
# Sample ECS service creation with ALB
aws ecs create-service \
--cluster my-cluster \
--service-name my-service \
--load-balancers targetGroupArn=xxx,containerName=my-app,containerPort=80 \
--launch-type FARGATE \
--task-definition my-task \
--desired-count 2
📦 Summary: Make the Smart Call
Need | Use This LB |
---|---|
Smart HTTP routing? | ALB |
Crazy fast TCP traffic? | NLB |
Legacy apps? | CLB (last resort) |
In short: ALB = Smart HTTP, NLB = Speed Demon, CLB = Grandpa
💬 What’s Your Load Balancer Story?
Ever made the wrong choice and paid the price?
Or found a clever use for NLB in a real-time app?
👇 Drop your tips, questions, and war stories in the comments.
Smash that ❤️ if you learned something, and share with a dev buddy juggling load balancer chaos.
Let’s route traffic like pros. 🧡