search

ALB vs NLB

chevron-rightcomparehashtag

Got it 👍 You want a complete comparison of ALB (Application Load Balancer) vs NLB (Network Load Balancer) — including features, use cases, performance, integrations, etc.

Here’s the deep-dive comparison (organized in a table + explanation):

hashtag
🔹 ALB vs NLB — Full Comparison

Feature
Application Load Balancer (ALB)
Network Load Balancer (NLB)

OSI Layer

Operates at Layer 7 (Application layer)

Operates at Layer 4 (Transport layer)

Protocol Support

HTTP, HTTPS, gRPC, WebSockets

TCP, UDP, TLS

Routing

Content-based routing (host-based, path-based, query params, headers, HTTP methods)

Connection-based routing (routes traffic purely based on IP and port)

Ingress for Kubernetes

✅ Yes, supports as Ingress controller

❌ No (cannot act as Ingress, only service load balancer)

Target Types

EC2 instances, IP addresses, Lambda functions, Containers (ECS/EKS)

EC2 instances, IP addresses, Containers (ECS/EKS)

TLS Termination

✅ Yes (offloads SSL/TLS at the ALB)

✅ Yes (optional), but usually passes TLS to target

Performance

High throughput but adds Layer 7 processing overhead

Ultra-high performance, millions of requests per second, low latency (sub-millisecond)

Sticky Sessions (Session Affinity)

✅ Supported (via cookies)

✅ Supported (via 5-tuple: source/destination IP, port, protocol)

Cross-Zone Load Balancing

✅ Enabled by default (no extra cost)

✅ Optional, but extra charges per GB

Security Features

Integrates with AWS WAF, Shield, Security Groups

Shield integration only, no WAF support

WebSockets

✅ Supported

❌ Not supported directly

gRPC

✅ Supported

❌ Not supported

Health Checks

Application-level (HTTP/HTTPS response codes)

Transport-level (TCP/UDP, TLS handshake)

Logging

Access logs (detailed: path, headers, response codes, latency, etc.)

Flow logs (connection-level: IP, port, protocol, bytes transferred)

IP Target Support

✅ Yes

✅ Yes

Static IP

❌ Only DNS hostname (CNAME provided by AWS)

✅ Yes (static IPs per AZ or assign Elastic IPs)

PrivateLink

❌ Not supported

✅ Supported (can be used as endpoint service with PrivateLink)

Pricing

Charged based on: 1. Load balancer hours2. LCU (Load Balancer Capacity Units: new connections, active connections, processed bytes, rule evaluations)

Charged based on:1. Load balancer hours2. NLCU (New connections, active flows, data processed in GB)

Best for

Layer 7 applications: web apps, APIs, microservices

Extreme performance: gaming, IoT, real-time apps, VoIP, financial trading

Typical Latency

~milliseconds (adds routing overhead)

Sub-millisecond (fastest AWS LB)

Integration with Lambda

✅ Yes

❌ No

HTTP/2 Support

✅ Yes

❌ No

Target Groups

HTTP/HTTPS/gRPC listeners with advanced rules

TCP/UDP/TLS listeners with simple rules

ECS/EKS Use Case

Best for exposing services/APIs

Best for services requiring static IP or very high throughput

hashtag
🔹 When to Use What

✅ Use ALB if:

  • You need Ingress for Kubernetes/EKS.

  • You want path-based or host-based routing.

  • You need TLS termination + WAF integration.

  • You are running web apps, APIs, microservices.

  • You want WebSocket or gRPC support.

✅ Use NLB if:

  • You need ultra-low latency and millions of requests per second.

  • You require static IP or Elastic IP support.

  • You are handling non-HTTP traffic (TCP, UDP, TLS).

  • You want to use AWS PrivateLink.

  • You’re running gaming servers, IoT apps, real-time trading systems.

👉 In short:

  • ALB = Smart Layer 7 load balancer (application-aware)

  • NLB = Super-fast Layer 4 load balancer (connection-aware)

Do you want me to also include real-time enterprise examples (like how fintechs, gaming companies, or SaaS apps use ALB vs NLB)?

PreviousALB and ASGNextVG ALB

Last updated