principlejavascriptTip
ALB vs NLB: application vs network load balancer selection criteria
Viewed 0 times
ALBNLBapplication load balancernetwork load balancerLayer 7Layer 4path routingstatic IPgRPC
Problem
Teams default to ALB for all workloads without considering NLB's advantages for TCP/UDP, low latency, and static IP requirements. Using the wrong load balancer leads to unnecessary complexity or missing features.
Solution
Use ALB for HTTP/HTTPS workloads that need path-based routing, host-based routing, authentication (Cognito/OIDC), or WebSocket support. Use NLB for TCP/UDP workloads, ultra-low latency, static IP requirements, or TLS passthrough to backend services.
Why
ALB operates at Layer 7 (HTTP) and can inspect and route based on content. NLB operates at Layer 4 (TCP/UDP) and achieves latency in the microseconds range with millions of requests per second. NLB preserves source IP natively; ALB requires X-Forwarded-For.
Gotchas
- NLB does not have a Security Group — use VPC Security Groups on the targets instead; ALB has its own Security Group
- ALB is not suitable for non-HTTP protocols — use NLB for gRPC over TCP or custom TCP protocols
- NLB supports static Elastic IPs — useful for whitelisting in partner/enterprise firewall rules
- ALB has a built-in WAF integration; NLB does not — use WAF on ALB for application-layer protection
- Both ALBs and NLBs charge per LCU (Load Balancer Capacity Units) — choose based on traffic profile, not just upfront cost
Context
Selecting a load balancer type for a new AWS application or service
Revisions (0)
No revisions yet.