NLB
AWS Network Load Balancer (NLB) is a fully managed, Layer 4 load balancing service designed to route raw TCP, UDP, and TLS traffic across targets—such as Amazon EC2 instances, microservices, container tasks, and specific IP addresses.
Operating at the Transport Layer (Layer 4 of the OSI model), an NLB focuses strictly on network connections and packet headers. It does not inspect the high-level application data payload inside the packets, making it capable of processing tens of millions of concurrent requests per second with ultra-low, sub-millisecond latencies.
Core Component Hierarchy
The operational architecture of an NLB mirrors the standard Elastic Load Balancing framework but executes at a lower protocol layer:
Listeners: Front-facing processes that monitor for incoming connection attempts based on transport protocols (TCP, UDP, TCP_UDP, or TLS) and explicit port numbers (e.g., port 53 for DNS or port 9000 for custom TCP applications).
Rules: Dictate how listener traffic is handled. While Layer 7 balancers support complex content evaluation rules, an NLB utilizes basic default forward actions, instantly passing incoming transport-layer packets straight to a designated backend target group.
Target Groups: Logical groupings of your backend worker assets. The NLB routes packets to these targets using a high-performance routing algorithm based on a 5-tuple hash of the packet properties (source IP, source port, destination IP, destination port, and protocol).
Key Technical Capabilities
Static IP and Elastic IP Bindings Unlike an Application Load Balancer, which uses dynamically shifting IP addresses, an NLB provides one fixed, static public IPv4 address for each Availability Zone in which it is enabled. Furthermore, you can assign a specific Elastic IP address directly to each zone's network interface. This is a critical architectural requirement for enterprise setups where external clients or corporate partners must explicitly whitelist fixed IP addresses in their on-premises firewalls.
Preservation of Client Source IP When using an NLB with instance-type target groups, the load balancer leaves the network packet headers completely intact. The backend EC2 instances receive the raw packets displaying the true, original Source IP address of the client rather than the IP of the load balancer. This removes the need to parse complex proxy protocol headers just to log client identities or run localized geo-location security logic.
TLS Offloading and Acceleration For security-sensitive applications running over encrypted lines, an NLB supports TLS termination. It integrates with AWS Certificate Manager (ACM) to decrypt incoming ciphertext connections at the load balancer layer before passing clean TCP packets to your backend servers. Because the NLB uses specialized hardware acceleration chips under the hood, it handles massive cryptographic handshakes efficiently without introducing latency.
Handling Volumetric Traffic Spikes An NLB is uniquely architected to handle sudden, massive shifts in traffic volume. While an ALB must progressively scale out its capacity over several minutes when a traffic spike hits, an NLB can absorb instantaneous surges of millions of requests per second—such as flash sales or sudden IoT device check-in storms—without dropping connections.
Health Check Mechanics and Connection Draining
To ensure reliable routing, the NLB continuously assesses the availability of every target in its registered pools:
Low-Level Probing: NLBs can execute both high-level HTTP health checks and raw transport-layer TCP handshakes. If you configure a TCP check on port 80, the NLB attempts to establish a basic three-way handshake with the host interface. If the host socket responds, the instance is verified as healthy.
Rapid Target Eviction: If an instance fails a configured number of consecutive health probes, the NLB shifts its status to unhealthy and immediately stops routing new connections to that node.
Connection Draining (Deregistration Delay): When an instance is marked unhealthy or is being removed due to an Auto Scaling downscale event, the NLB initiates Connection Draining. It stops sending brand-new client requests to that specific server but allows existing, active TCP connections to remain open for a configurable duration (e.g., 300 seconds) so live transactions can complete gracefully before the instance shuts down.