ALB vs NLB: which AWS load balancer should you use?

What a load balancer does, briefly

Our what is a load balancer explainer covers the general idea in depth: a load balancer sits in front of a group of servers and spreads incoming traffic across them, so no single server is overwhelmed and the group can survive one of them failing. ALB and NLB are two flavours of that same idea inside AWS, each tuned for a different kind of traffic.

Layer 7 vs layer 4, in plain terms

Networking is often described in layers, and the two that matter here are layer 4 (the transport layer — TCP and UDP, concerned only with getting packets between two endpoints) and layer 7 (the application layer — HTTP and HTTPS, where the actual request content lives). An ALB operates at layer 7: it can see inside a request and read things like the URL path, the hostname, or a header, and route based on that content. An NLB operates at layer 4: it sees connections and packets, not requests, and routes purely on that lower-level information without inspecting what is inside.

That single distinction explains almost everything else about when to use each one.

What ALB is built for

Because an ALB understands HTTP/HTTPS, it can make routing decisions a layer-4 balancer simply cannot: send /api requests to one set of servers and /images requests to another, route different hostnames to different backend services, or direct traffic based on a cookie. This makes it the natural fit for web applications and microservices architectures, where several logical services often sit behind one entry point and need to be reached by path or host rather than by a single flat pool of identical servers.

What NLB is built for

An NLB does not read request content at all — it forwards connections based on IP address and port, which makes it extremely fast and well suited to traffic that either is not HTTP (raw TCP or UDP protocols) or needs the lowest possible overhead and the highest possible throughput a routing layer can offer. It is also the right tool when a client needs to see the original client IP address preserved end to end, or when an application needs a static IP or an Elastic IP attached to the load balancer itself, which an ALB does not provide directly.

When to choose which

The short version: if your traffic is HTTP or HTTPS and you want to route by path, hostname, or other request content, reach for an ALB. If your traffic is not HTTP, needs the lowest possible latency and overhead, or you specifically need a static IP or client-IP preservation, reach for an NLB. The two are not mutually exclusive within one architecture either — a common pattern chains an NLB in front of an ALB to get a static entry-point IP while still keeping layer-7 routing behind it. As with most AWS service pairs, the honest answer is “it depends on the job,” and both are worth understanding rather than picking by habit.

• OSI layer — ALB: layer 7 (application). NLB: layer 4 (transport).
• Protocols — ALB: HTTP, HTTPS, WebSocket. NLB: TCP, UDP, TLS passthrough.
• Routes on — ALB: path, hostname, headers, request content. NLB: IP address and port only.
• Best fit — ALB: web apps, microservices, content-based routing. NLB: non-HTTP protocols, extreme performance needs, static IP requirements.
• Client IP — ALB: preserved via headers. NLB: preserved natively at the connection level.