Load Balancer Selection Guide: ALB vs NLB vs CLB

Choosing the right AWS load balancer affects performance, cost, and feature availability. This guide compares Application Load Balancer (ALB), Network Load Balancer (NLB), and Classic Load Balancer (CLB) to help you make the right choice.

Quick Comparison

Application Load Balancer (ALB)

When to Use ALB

• HTTP/HTTPS workloads
• Need path-based or host-based routing
• Microservices architecture
• Modern web applications
• Container workloads (ECS, EKS)

Key Features

• Content-based routing: Route by path, host, headers, query strings
• Target groups: Route to different services
• Authentication: Native OIDC, Cognito integration
• WAF integration: Attach AWS WAF for protection
• HTTP/2 and gRPC: Modern protocol support

ALB Routing Example

# Rule 1: API traffic
Host: api.example.com
Path: /v1/* → Target Group: api-v1

# Rule 2: API v2
Host: api.example.com
Path: /v2/* → Target Group: api-v2

# Rule 3: Static content
Host: static.example.com → Target Group: cdn

# Default: Main application
* → Target Group: web-frontend

Network Load Balancer (NLB)

When to Use NLB

• Ultra-low latency required
• Millions of requests per second
• Static IP addresses needed
• Non-HTTP protocols (TCP, UDP)
• Gaming, IoT, financial applications
• VPN termination

Key Features

• Static IP: One Elastic IP per AZ
• Preserve source IP: Client IP visible to targets
• Connection-based: TCP connections maintained
• PrivateLink: Expose services via VPC endpoints
• TLS offloading: Terminate TLS at NLB

Performance Characteristics

• Millions of requests per second
• Ultra-low latency (microseconds added)
• Scales instantly (no pre-warming)
• Handles sudden spikes better than ALB

Classic Load Balancer (CLB)

Legacy—Avoid for New Deployments

• Status: Previous generation
• Recommendation: Migrate to ALB or NLB
• Use case: Only for EC2-Classic (deprecated)

Migration Path

• HTTP/HTTPS workloads → ALB
• TCP workloads → NLB
• AWS provides migration wizard

Decision Matrix

Choose ALB When:

• ✅ HTTP/HTTPS traffic
• ✅ Need path or host routing
• ✅ Want WAF integration
• ✅ Using containers (ECS/EKS)
• ✅ Need authentication at LB

Choose NLB When:

• ✅ Ultra-low latency critical
• ✅ Need static IP addresses
• ✅ Non-HTTP protocols (TCP/UDP)
• ✅ Millions of RPS
• ✅ Need to preserve source IP
• ✅ VPC PrivateLink exposure

Cost Considerations

Pricing Model

• ALB: Per hour + LCU (Load Balancer Capacity Units)
• NLB: Per hour + NLCU (Network LB Capacity Units)
• CLB: Per hour + Data processed

Cost Optimization Tips

• Consolidate multiple CLBs into one ALB with target groups
• Use NLB for high-throughput to avoid LCU costs
• Review idle load balancers

ALB + NLB Pattern

Use both for different purposes:

Internet Traffic
       │
       ├── HTTPS (web) ───► ALB ───► Web Tier
       │                    │
       │                    └───► API Tier
       │
       └── TCP (gaming) ──► NLB ───► Game Servers
       
Internal Traffic
       │
       └── gRPC services ─► Internal ALB ───► Microservices

Health Checks

ALB Health Checks

• HTTP/HTTPS based
• Match response codes (200-399 default)
• Match response body text

NLB Health Checks

• TCP: Connection success
• HTTP/HTTPS: Path and response code
• Lower intervals possible for faster failover

Key Takeaways

• ALB for HTTP workloads with content-based routing
• NLB for ultra-low latency and non-HTTP protocols
• Avoid CLB—migrate existing to ALB/NLB
• Consider cost: LCU-based pricing vs. NLCU
• Use both ALB and NLB for different traffic types