Network Load Balancer (NLB)

An NLB routes traffic at the connection level, not the request level. It examines the header of each TCP or UDP packet—specifically the source and destination IP addresses and port numbers—to make a forwarding decision. Once a connection is established to a backend target, all packets for that connection are sent to the same target for its duration. This is ideal for protocols where a persistent socket is important, such as gaming, IoT messaging, or financial trading systems.

• Key Mechanism: Uses a flow hash algorithm (often a 5-tuple hash: Source IP, Destination IP, Source Port, Destination Port, Protocol).
• Contrast with ALB: Unlike an Application Load Balancer (which operates at Layer 7), an NLB does not inspect the contents of HTTP headers, URLs, or cookies.

NLBs are engineered for raw performance, offering single-digit millisecond latency and the ability to handle millions of requests per second. They achieve this by operating statelessly at the packet level and often leveraging underlying hardware or kernel-level optimizations.

• Performance Drivers: Bypasses complex HTTP parsing, uses efficient packet-forwarding paths, and can handle sudden, volatile traffic spikes ("flash crowds") without performance degradation.
• Use Case: Critical for latency-sensitive applications like real-time bidding, multiplayer gaming backends, and high-frequency trading platforms where every millisecond counts.

A defining feature of an NLB is its ability to preserve the original source IP address of the client in the packets forwarded to the backend targets. It does this by using Network Address Translation (NAT) at the packet level without proxying the connection.

• Technical Detail: The backend server sees the client's real IP as the source, not the IP of the load balancer. This is crucial for security analysis, geo-blocking, and any application logic that depends on the client's IP.
• Contrast: Many Layer 7 load balancers and reverse proxies terminate the TCP connection, making the load balancer's IP the apparent source to the backend, requiring headers like X-Forwarded-For to pass the original IP.

NLBs are assigned static IP addresses that do not change for the life of the load balancer. Furthermore, they can be associated with Elastic IP addresses, providing a fixed, stable endpoint for clients. This is essential for scenarios where firewall rules must be pre-configured to allow traffic from specific, known IPs.

• Enterprise Integration: Simplifies whitelisting for corporate networks, legacy on-premises systems, and third-party APIs that require IP-based authentication.
• Contrast with ALB: Application Load Balancers typically use dynamic DNS hostnames, and their underlying IPs can change, making IP-based firewall rules impractical.

An NLB is deployed within a specific Availability Zone (AZ) and receives a static IP per subnet in that zone. It can be configured for zonal isolation (handling traffic only within its zone) or cross-zone load balancing.

• Zonal Isolation: Provides fault isolation; failure in one zone does not affect the NLB in another. Offers the highest performance by keeping traffic within a single zone.
• Cross-Zone Load Balancing: When enabled, the NLB can distribute traffic evenly across registered targets in all enabled Availability Zones, improving fleet utilization and availability. This may incur inter-zone data transfer costs.

NLBs are protocol-agnostic at the application layer. They can load balance any TCP or UDP-based traffic, including non-HTTP protocols like:

• FTP, SSH, RDP
• Custom binary protocols for gaming or IoT
• Database replication traffic (e.g., MySQL, Redis)
• Streaming media protocols (RTMP, RTP)

They excel at handling long-lived connections (e.g., WebSocket, IoT device tunnels, VPNs) efficiently because they maintain simple flow state without the overhead of parsing application-layer handshakes.

NLBs are engineered for massive packet-per-second (PPS) throughput with ultra-low latency, making them the optimal choice for non-HTTP protocols. They handle the raw data streams of:

• Financial trading systems requiring microsecond-order routing.
• Gaming servers managing millions of concurrent UDP connections.
• IoT data ingestion from vast sensor networks transmitting telemetry via MQTT or custom protocols.
• Media streaming where preserving the underlying RTMP or RTP protocol is critical.

Unlike Application Load Balancers (ALBs), NLBs do not terminate TLS or parse HTTP headers, allowing them to forward packets with near-line speed.

A core architectural feature of an NLB is source IP address preservation. When forwarding a connection, the NLB does not replace the client's original IP address with its own. This is critical for use cases where backend applications must see the true client IP for:

• Security and audit logging, ensuring accurate attribution of requests.
• Geolocation-based routing or content personalization logic within the application.
• IP-based access control lists (ACLs) or rate-limiting logic implemented at the server level.
• Regulatory compliance requiring definitive audit trails of client origins.

This contrasts with proxy protocol or other methods needed with ALBs, simplifying backend application logic.

NLBs are designed for elastic scalability and can instantaneously adapt to sudden, massive fluctuations in traffic. Their stateless, connection-based routing allows them to seamlessly integrate with auto-scaling groups. Key scenarios include:

• Black Friday e-commerce events, where connection rates can spike 1000x in seconds.
• Viral social media events driving unpredictable load to APIs or services.
• Scientific computing bursts where data processing jobs initiate millions of parallel TCP connections.
• Disaster recovery failover, rapidly shifting entire data center traffic loads.

The NLB's ability to register and deregister targets (servers) in real-time, without causing connection drops for existing flows, is a fundamental advantage for dynamic environments.

For applications maintaining persistent, stateful connections, NLBs provide stability through static IP per Availability Zone and direct port mapping. This is essential for:

• Database replication streams (e.g., MySQL, PostgreSQL) that maintain continuous TCP connections between primary and replica instances.
• File transfer protocols like FTP or SFTP sessions that remain open for extended periods.
• VPN and secure shell (SSH) gateways where sessions last for hours or days.
• Legacy applications that cannot handle changing backend IP addresses or require firewall rules to be pinned to specific NLB IPs.

The NLB acts as a stable network endpoint, forwarding packets for these long-lived flows without interruption, even during backend maintenance.

NLBs can route traffic to targets outside their native cloud environment, enabling hybrid cloud architectures. This is achieved by registering IP addresses from on-premises data centers as targets. Common patterns include:

• Cloud bursting, where overflow traffic from on-prem applications is directed to cloud-based resources.
• Migration bridging, allowing a phased application migration by load balancing between old on-prem and new cloud servers.
• Unified API front-end for services distributed across cloud and corporate data centers.
• Disaster recovery, where the NLB can failover traffic to a standby environment in a different physical location.

This capability provides a single point of ingress for clients, abstracting the complexity of a geographically dispersed backend fleet.

NLBs are inherently zone-aware. When configured, they create a network interface (and a static IP) in each selected Availability Zone. This architecture provides built-in fault isolation:

• If an entire Availability Zone fails, the NLB automatically routes traffic only to healthy zones.
• Cross-zone load balancing can be enabled to distribute traffic evenly across all registered targets in all zones, or disabled to route zone-local traffic to targets in the same zone only (preserving inter-zone data transfer costs).
• This design is foundational for high-availability (HA) architectures, ensuring the load balancer itself is not a single point of failure.

This makes NLBs a resilient foundation for multi-zone deployments where uptime is critical.

Layer 4 Load Balancing is the foundational category of traffic distribution that includes NLBs. It operates at the transport layer of the OSI model, dealing with TCP and UDP protocols. Decisions are made solely on:

• Source and destination IP addresses
• Source and destination port numbers
• Protocol type (TCP/UDP) This approach is extremely fast and efficient because it does not inspect packet payloads. It provides transparent pass-through of traffic, preserving the original source IP address of the client, which is critical for security auditing and backend logic.

A Health Check is a periodic probe sent by a load balancer to its registered targets (e.g., servers, containers) to determine their operational status. For an NLB, these are typically TCP connection attempts or custom TCP request/response validations sent to a configured port. A target is marked healthy if it responds within the timeout period and with the expected response; otherwise, it is marked unhealthy and automatically removed from the traffic rotation. This is the core mechanism ensuring high availability and fault tolerance by routing traffic only to capable endpoints.

Connection Draining (also called deregistration delay) is a process that gracefully removes a backend instance from service. When an instance is deregistered or fails a health check, the NLB stops sending new connections to it but allows existing, in-flight connections to complete for a configurable timeout period (e.g., 300 seconds). This prevents client sessions from being abruptly terminated during deployments, maintenance, or instance scaling events. It is essential for maintaining a zero-downtime user experience and ensuring stateful transactions are not interrupted.

A Virtual IP Address (VIP) is a single IP address that is not tied to a specific physical network interface but is instead fronted by a load balancer. Clients send requests to the VIP, and the NLB distributes those requests to a pool of backend servers with their own real IPs. The VIP provides a stable entry point for a service, abstracting away the underlying, potentially changing, server infrastructure. This enables seamless scaling, maintenance, and failover—servers can be added or removed without clients needing to update their connection endpoints.

SSL/TLS Termination is the process of decrypting encrypted traffic at the load balancer. While a basic NLB operates on encrypted packets without decrypting them (pass-through), many NLB implementations offer an optional TLS listener. When configured, the NLB handles the TLS handshake, offloading the cryptographic overhead from backend servers. The traffic is then forwarded to the backend as plain TCP or re-encrypted with a separate certificate. This centralizes certificate management and improves backend server performance, though it shifts the trust boundary to the load balancer.