ALB vs NLB: Picking the Right AWS Load Balancer

Quick Answer

Quick Answer: An Application Load Balancer (ALB) reads the actual HTTP request and routes by URL path, hostname, or headers (Layer 7); a Network Load Balancer (NLB) just forwards TCP/UDP packets at wire speed without looking inside them (Layer 4). Default to ALB for ordinary web apps and APIs; reach for NLB when you need a fixed IP address, raw non-HTTP protocols, or the lowest possible overhead.

Layer 7 vs Layer 4, in Practical Terms

"Layer 7" and "Layer 4" refer to the OSI networking model, but you don't need the whole seven-layer chart to use this distinction — you need one concrete fact: how much of the request can the load balancer actually see before it decides where to send it?

A Layer 4 device (NLB) looks at the TCP/UDP packet header: source IP, destination IP, source port, destination port, protocol. That's it. It has no idea whether the payload is an HTTP GET for /checkout or a raw database protocol frame — it just moves bytes toward a target based on connection-level information.

A Layer 7 device (ALB) actually terminates the connection, parses the HTTP request, and can see everything inside it: the URL path, the Host header, query parameters, cookies, even the HTTP method. That visibility is what lets it make content-aware routing decisions that a Layer 4 balancer structurally cannot make, no matter how it's configured — the information simply isn't available at that layer.

This single fact explains almost every practical difference between the two services: ALB can do intelligent routing because it reads the request; NLB is fast and protocol-agnostic because it deliberately doesn't.

ALB: Routing by What's Inside the Request

ALB operates over HTTP, HTTPS, gRPC, and WebSockets. Because it understands the request, it supports routing rules based on:

• Path — e.g. /api/* to one target group, /images/* to another
• Host header — e.g. api.example.com vs admin.example.com on the same load balancer
• HTTP method, query string, or source IP as additional conditions

Each routing rule points at a target group, which can be EC2 instances, IP addresses, ECS tasks, or even a Lambda function. This is what makes ALB the natural front door for a system that's split (or splitting) into multiple services under one domain: a single ALB can send /payments/* to a payments microservice, /search/* to a search service, and everything else to the original monolith — all while every client just sees one hostname and one TLS certificate.

ALB also handles TLS termination with SNI (multiple certificates on one load balancer), integrates directly with AWS WAF for request-level filtering, supports redirect and fixed-response rules without needing a backend at all (useful for simple HTTP-to-HTTPS redirects or maintenance pages), and performs cross-zone load balancing by default, at no extra charge — traffic is spread evenly across targets in every enabled Availability Zone regardless of which AZ the request first landed in.

The trade-off for all this intelligence: ALB has to actually parse and understand HTTP, which is simply more work per request than blindly forwarding packets.

NLB: Minimal Overhead, Maximum Throughput

NLB operates at Layer 4 over TCP, UDP, and TLS (as a pass-through, not an inspector). AWS designs and markets it specifically for extreme performance and very low latency, precisely because it skips the work of parsing payload content — it just forwards connections.

Three NLB characteristics matter most in real use:

• It preserves the client's source IP natively. ALB can do this too, but only by adding an X-Forwarded-For header since it terminates the connection; NLB passes the original IP straight through at the connection level.
• Cross-zone load balancing is off by default. This is a real, commonly-hit gotcha — if you don't explicitly enable it, traffic landing in one AZ only gets distributed to targets in that same AZ, which can produce uneven load if your targets aren't evenly spread. Enabling it is free for NLB as of a later AWS update, but it's not the out-of-the-box behavior, unlike ALB.
• It handles protocols ALB simply cannot route by content — raw TCP services like a custom game server protocol, an MQTT broker, a database connection proxy (e.g. PgBouncer), or any system where you need the literal bytes forwarded, not interpreted.

NLB is the right tool whenever "fast, dumb forwarding of whatever protocol this is" is exactly what you want, and any HTTP-aware behavior would be unnecessary overhead or simply wouldn't apply.

The Static IP Decision Most Teams Actually Make This On

In practice, a huge number of real ALB-vs-NLB decisions come down to one unglamorous requirement: a partner, a corporate firewall, or a compliance team needs a fixed IP address to allowlist.

ALB is fundamentally DNS-based. AWS explicitly does not guarantee a stable IP for an ALB — the underlying IPs can and do change, which is by design since ALB is meant to scale its own capacity transparently. You cannot simply "attach" an Elastic IP to an ALB.

NLB, by contrast, gives you an Elastic IP per Availability Zone when you create it in a VPC — a genuinely static public IP you can hand to a partner's firewall team or put in a compliance document, and it won't move.

So what happens when you need both — ALB's content-aware routing and a fixed IP? Since September 2021, AWS supports registering an ALB as a target behind an NLB using ALB-type target groups. You put the NLB in front (for the static Elastic IP) and let it forward to the ALB (for the path/host-based routing), getting both properties in one setup instead of having to choose.

Side-by-Side Comparison

Neither load balancer is strictly "better" — they're optimized for different jobs, and AWS deliberately kept both in the product line rather than merging them, because the Layer 7 vs Layer 4 trade-off is a real one, not a legacy accident.

A Practical Decision Checklist

When you're actually choosing, run through this in order:

• Is your traffic HTTP/HTTPS/WebSocket, and do you need to route by path or hostname? → ALB. This covers the large majority of typical web apps and APIs.
• Does something external need to allowlist a fixed IP? → NLB, or NLB in front of ALB if you also need path-based routing.
• Is the protocol not HTTP at all (raw TCP/UDP, a custom binary protocol, a database proxy)? → NLB, since ALB structurally cannot route traffic it can't parse.
• Is this a very high-throughput, latency-sensitive workload where every millisecond of processing matters? → NLB, since it skips HTTP parsing entirely.
• Still unsure, and it's a typical web application? → Start with ALB. It's what the large majority of new AWS workloads use by default, and you can always add an NLB in front later if a static-IP requirement shows up.

If you're working through system design practice as part of interview prep, this is a reliable exam-style question too: naming the correct OSI layer and one concrete feature each balancer has that the other structurally cannot (content routing vs static IP) usually demonstrates real understanding rather than memorized trivia. You can find more backend and systems-design practice on the Priodemy courses page.

Frequently Asked Questions