Network Load Balancer (NLB)

A Network Load Balancer (NLB) is a Layer 4 load balancer that distributes incoming TCP and UDP connections across backend targets based purely on network-layer information — IP addresses and ports — without inspecting the actual content of the traffic, which allows it to operate with extremely low latency and handle very high throughput.

Why Layer 4 Instead of Layer 7

Because an NLB doesn’t parse HTTP requests or any other application-layer protocol, it can forward connections with minimal processing overhead, typically adding only microseconds of latency — an important property for latency-sensitive workloads like real-time gaming backends, financial trading systems, or high-throughput IoT ingestion, where even the small additional latency of Layer 7 processing in an Application Load Balancer would be meaningful.

Additional Characteristics

NLBs preserve the client’s source IP address by default (rather than replacing it with the load balancer’s own IP, as is common with Layer 7 proxies), which matters for backend systems that need to see the actual originating client address for logging, security, or protocol reasons. They also support static IP addresses per availability zone and can handle protocols beyond HTTP/HTTPS, including raw TCP and UDP traffic for non-web protocols.

NLB vs. ALB

The tradeoff for this speed and simplicity is a lack of content-aware routing: an NLB can’t route based on URL path or hostname the way an Application Load Balancer can, since it never looks past the network and transport layer headers. In practice, most standard web application traffic uses an ALB for its routing flexibility, while an NLB is reserved for cases specifically requiring extreme low latency, non-HTTP protocols, or preserved client IP addresses — and the two are sometimes combined in a single architecture, with an NLB in front of an ALB for scenarios needing both a static IP and Layer 7 routing.

When NLB’s Static IPs Matter Most

Beyond raw performance, NLB’s support for a fixed static IP address per availability zone is itself a common deciding factor: some enterprise firewalls and partner integrations require allowlisting specific, unchanging IP addresses rather than a domain name, which an ALB’s dynamically changing IP pool can’t reliably support. This makes NLB the default choice not just for latency-sensitive workloads but for any integration requiring IP-based allowlisting, independent of whether the traffic itself needs Layer 7 routing.

This same static-IP property is also why NLBs are frequently used as the entry point for VPN and Direct Connect based hybrid architectures, where predictable addressing on both ends of the connection is a hard requirement rather than a nice-to-have.