ALB vs NLB: Which AWS Load Balancer Should You Use?

Definition

AWS Elastic Load Balancing (ELB) offers three modern load balancer types: Application Load Balancer (ALB), Network Load Balancer (NLB), and Gateway Load Balancer (GWLB). The common choice for web and network workloads is between ALB and NLB:

ALB operates at Layer 7 (HTTP/HTTPS), understands requests, and can route based on path, host, headers, method, or query string.
NLB operates at Layer 4 (TCP/UDP/TLS), is protocol-agnostic above TCP, delivers ultra-low latency, preserves the client's source IP, and can publish static IPs.

Choosing the right one comes down to the application protocol, latency requirements, and whether you need advanced HTTP features or raw TCP/UDP.

How Each Works

Application Load Balancer (ALB)

When a request arrives, the ALB terminates the TLS handshake, parses the HTTP request, and consults listener rules to pick a target group. Rules can match on:

Host header (api.example.com vs www.example.com)
Path (/api/* → microservice A, /images/* → microservice B)
Headers or query string parameters
HTTP method
Source IP (CIDR)

Targets can be EC2 instances, IP addresses, Lambda functions, or containers registered by ECS / EKS. The ALB supports HTTP/2, gRPC, WebSockets, server-sent events, and authentication via Amazon Cognito or any OIDC provider.

Network Load Balancer (NLB)

The NLB is a Layer 4 connection-level load balancer that forwards TCP or UDP connections to a target group with minimal processing. Because it doesn't parse HTTP, it can handle millions of requests per second at sub-millisecond latency. Traffic is distributed using a flow hash of source IP, source port, destination IP, destination port, and protocol. The NLB preserves the client source IP and exposes one static IP per Availability Zone (you can also assign Elastic IPs). TLS termination is optional.

Feature Comparison

| Feature | Application Load Balancer (ALB) | Network Load Balancer (NLB) | | --- | --- | --- | | OSI Layer | Layer 7 | Layer 4 | | Supported protocols | HTTP, HTTPS, HTTP/2, gRPC, WebSockets | TCP, UDP, TLS, TCP_UDP | | Routing features | Host / path / header / method / query string / source IP | Flow hash only | | TLS termination | Yes | Yes (passthrough or terminate) | | WebSockets | Yes | Yes (at Layer 4) | | Static IP | No (uses AWS-managed DNS) | Yes — one per AZ, can use Elastic IPs | | Source IP preserved | No (X-Forwarded-For header) | Yes — client IP arrives at target | | Performance | Good (ms-level latency) | Excellent (sub-ms, 10M+ req/s) | | Authentication | Built-in with Cognito / OIDC | No | | Request-level logs | Yes (ALB access logs) | Flow logs via VPC Flow Logs | | Target types | EC2, IP, Lambda, containers | EC2, IP, containers (no Lambda) | | Target groups | Route-based selection | Single target group per listener | | Sticky sessions | Yes (cookies) | Yes (source-IP affinity) | | Security groups | Yes | No (NLB has no SG itself; target SG sees true client IP) | | Pricing | Per hour + LCU | Per hour + NLCU |

When to Choose ALB

Web applications and APIs behind HTTP/HTTPS.
Microservices and containers where path-based or host-based routing splits traffic across services.
WebSockets / gRPC apps that still want HTTP-aware routing.
Auth at the edge via Cognito or any OIDC provider.
Workloads that benefit from WAF integration (ALB + WAF is a common pattern).

When to Choose NLB

Non-HTTP protocols: MQTT, Postgres, MySQL, SMTP, SSH, game protocols.
Ultra-low latency / high-throughput workloads needing millions of connections per second.
Static IPs required — for corporate firewalls that allowlist specific IPs, or for DNS-less clients.
True client source IP is needed without X-Forwarded-For gymnastics.
TLS passthrough — terminate TLS at the application rather than the load balancer.
PrivateLink providers — NLB is the only way to expose your service via AWS PrivateLink.

Pricing Model

Both balancers charge an hourly fee plus a usage metric:

ALB: per hour + Load Balancer Capacity Units (LCU), measured on new connections, active connections, processed bytes, and rule evaluations.
NLB: per hour + Network Load Balancer Capacity Units (NLCU), measured on new connections/flows, active flows, processed bytes, and TLS capacity.

For comparable steady web traffic, ALB is usually slightly cheaper; for very high connection churn or raw throughput, NLB's pricing model scales better.

Pros and Cons

ALB

Pros: rich HTTP routing, WebSockets / gRPC / HTTP/2, Lambda targets, Cognito auth, WAF integration.
Cons: higher latency than NLB, no static IP, does not preserve source IP at the TCP layer, does not support non-HTTP protocols.

NLB

Pros: ultra-low latency, millions of RPS, static IPs, source-IP preservation, TCP / UDP / TLS support, required for PrivateLink.
Cons: no HTTP routing, no authentication, no WAF integration at the balancer, no Lambda targets.

Common Patterns

HTTP microservices — one ALB, many target groups routed by path and host.
Global high-throughput API — CloudFront → ALB → ECS tasks (with WAF at CloudFront).
Game servers / MQTT — NLB with a TLS listener pointing to an Auto Scaling Group.
Postgres / MySQL for SaaS — NLB fronting an RDS or self-managed database (e.g., in a bastion pattern); clients get a stable endpoint.
Multi-protocol architecture — ALB for web traffic, NLB for administrative non-HTTP ports, both sharing the same VPC.
Hybrid ALB + NLB ("ALB-as-target") — NLB fronts static IPs and forwards to an ALB for HTTP routing, giving you a single stable IP plus Layer 7 richness.

Exam Relevance

Solutions Architect Associate (SAA-C03) — huge topic: picking the right balancer, target types, sticky sessions, TLS termination, cross-zone load balancing, security-group implications on ALB vs NLB.
Developer Associate (DVA-C02) — using ALB with Lambda targets, health checks, ALB + Cognito integration.
Advanced Networking Specialty (ANS-C01) — NLB + PrivateLink, hybrid architectures, source-IP preservation, cross-Region patterns with Global Accelerator.

Classic exam trap: if the scenario mentions "UDP", "static IP", "preserve source IP", "millions of connections", or a non-HTTP protocol, the answer is NLB. If it mentions "path-based routing", "host-based routing", "Cognito auth", "gRPC", or "WebSockets with HTTP routing", the answer is ALB.

Frequently Asked Questions

Q: Does NLB preserve the client IP address?

A: Yes — this is one of the main reasons to choose NLB over ALB. Because NLB operates at Layer 4 and forwards connections largely as-is, targets see the client's true source IP, which is invaluable for analytics, rate limiting, geo-blocking, and some legacy applications. ALB, by contrast, terminates the HTTP request and adds the client IP to the X-Forwarded-For header; the underlying TCP connection your application sees comes from the ALB.

Q: Can ALB handle non-HTTP traffic?

A: No. ALB is HTTP/HTTPS-only (with support for WebSockets and gRPC, which run on top of HTTP). For TCP or UDP workloads — databases, SSH, MQTT, DNS, gaming, VoIP — use NLB. If you need both HTTP routing and static IPs, a common pattern is NLB in front of an ALB (NLB's ALB-target-type support), combining NLB's static IPs with ALB's Layer 7 features.

Q: Do security groups apply to Network Load Balancers?

A: NLBs now support security groups (a relatively recent feature as of 2023+), but the behavior differs from ALB. Historically, NLBs had no SG of their own, and targets saw the client's IP — so target security groups had to allow traffic from client CIDRs rather than from the NLB. With NLB security groups, you can now attach an SG directly to the NLB and follow the same pattern as ALB. On older setups without NLB SGs, configure the target instance's SG to allow traffic from the expected client CIDRs.

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official ELB documentation before making production decisions.