Self Learning: ALB vs NLB — I finally understood the real difference

For the longest time, I used to think:

ALB = “normal load balancer”

NLB = “faster load balancer”

But recently, while revisiting AWS networking fundamentals, I realized the decision is not about speed.

It’s about Layer 7 vs Layer 4.

What clicked for me

ALB (Application Load Balancer) works at Layer 7.

It understands HTTP.

That means it can:

• Route based on path (/api, /auth)
• Route based on hostname
• Inspect headers
• Integrate cleanly with WAF
• Support microservices-style routing

So ALB is not just balancing — it’s making routing decisions at request level.

This is why it’s perfect for:

• Web applications
• REST APIs
• Microservices behind one entry point

NLB (Network Load Balancer) works at Layer 4.

It doesn’t care about HTTP. It cares about TCP/UDP connections.

That means:

• Extremely low latency
• Handles sudden traffic spikes very well
• Preserves client IP
• Works for non-HTTP protocols
• Supports long-lived connections better

AWS even mentions NLB can handle millions of requests per second and scales automatically.

So NLB is not “smarter” — it’s more raw and connection-focused.

Another important realization

AWS doesn’t give fixed “max RPS” numbers.

Instead:

• ALB scales using LCU (Load Balancer Capacity Units)
• NLB scales using NLCU

Capacity depends on:

• New connections
• Active connections
• Bandwidth
• Rule evaluations (for ALB)

So the real question isn’t:

“How many RPS can it handle?”

It’s:

“What dimension of traffic is dominant in my system?”

My simple rule now

If I need:

• HTTP awareness
• Path-based routing
• Microservices behind one entry point

→ I choose ALB

If I need:

• TCP/UDP
• Very high throughput
• Low latency
• Long-lived connections
• Preserved client IP

→ I choose NLB