The fastest way to choose between an Application Load Balancer and a Network Load Balancer is to ask what the balancer must understand.
If it needs to inspect HTTP requests and make application-level routing decisions, start with ALB. If it needs to preserve a high-performance Layer 4 connection path for TCP, UDP, or TLS traffic, start with NLB.
ALB works at Layer 7
An Application Load Balancer understands HTTP and HTTPS. It can route by hostname, URL path, headers, query strings, and request method. That makes it a natural fit for websites, REST APIs, microservices, and container platforms.
One ALB can route api.example.com to an API target group and images.example.com to another. It can send /checkout and /catalog to different services. It supports WebSockets, HTTP/2, redirects, fixed responses, authentication integrations, and AWS WAF association.
NLB works at Layer 4
A Network Load Balancer handles TCP, UDP, TCP_UDP, and TLS connections. It is designed for very high connection rates and low forwarding latency. It does not provide the same content-based HTTP routing because it is not acting as an application proxy in the same way.
NLB supports static IP addresses per Availability Zone and Elastic IP addresses for internet-facing load balancers. That matters when clients or partner firewalls need predictable destination IPs. It also preserves the source IP for common target types, which can simplify network-level logging and policy.
Side-by-side decision table
| Requirement | ALB | NLB |
|---|---|---|
| HTTP and HTTPS routing | Best fit | Pass or terminate TLS without content routing |
| Host and path rules | Yes | No |
| TCP or UDP | No | Yes |
| Static IP per Availability Zone | No | Yes |
| AWS WAF | Yes | No direct WAF association |
| WebSockets | Yes | TCP path can carry them, but without HTTP features |
| Source IP preservation | Forwarded headers | Native for common target paths |
| Lambda targets | Yes | No |
TLS changes the decision less than people think
Both can participate in TLS. ALB terminates HTTPS and gives you HTTP routing features. NLB can terminate TLS with a certificate or pass encrypted TCP through to targets. Choose based on what must happen after the handshake, not simply on whether encryption exists.
Health checks and failure behavior
Both products route only to healthy targets, but you must choose a meaningful health check. A shallow TCP check can pass while an application is unable to serve real requests. ALB health checks can call an HTTP endpoint that represents readiness. NLB also supports HTTP and HTTPS health checks even when the listener protocol is TCP.
Spread load balancer subnets and targets across multiple Availability Zones. The production high-availability web platform shows this pattern with an ALB and private compute.
Common choices
- Choose ALB for browser traffic, REST APIs, host-based routing, path-based routing, WAF, and most HTTP microservices.
- Choose NLB for non-HTTP protocols, UDP, extreme connection scale, static IP allowlists, source IP requirements, and TLS pass-through.
- Use both when an NLB feature is required at the network edge but an ALB is still useful for HTTP routing behind it. Accept the extra cost and operational complexity only when the requirement is real.
The question that settles it
Write down the protocol, client behavior, target type, routing rule, source IP requirement, and security controls. Once those are explicit, ALB versus NLB usually stops being a debate and becomes a straightforward architecture decision.
