This chapter covers the Network Load Balancer (NLB) in depth, focusing on its unique capabilities for static IP addressing, TLS termination, and ultra-low latency. For the SAA-C03 exam, NLB questions typically appear in 5-10% of the questions, often in the context of hybrid architectures, real-time applications, or when you must preserve the client source IP. Understanding NLB's Layer 4 operation, its stateless forwarding, and its integration with Global Accelerator and AWS PrivateLink is critical for designing high-performance and resilient architectures.
Jump to a section
Imagine a large warehouse with thousands of workers picking orders. The regular internet (like an ALB) uses a shared loading dock where every truck's arrival is noticed, but the address on the package is translated to an internal worker's name. This takes a bit of time for address lookup and rewriting. Now, NLB is like building a dedicated express lane directly from the highway to a specific loading bay. Each truck (packet) enters the express lane and is routed to a specific bay (target) based on a fixed lane number (the static IP and protocol/port). The lane doesn't inspect the cargo (no TLS termination at the lane entrance), it just moves the truck as fast as possible. The lane's entrance address never changes (static IP), and the lane itself has no traffic lights or slowdowns for address translation—it preserves the truck's original license plate (source IP) all the way to the bay. This express lane is built using specialized hardware (AWS's Nitro chip) that can switch trucks in microseconds, while the regular loading dock uses software that takes a few milliseconds per truck. In the warehouse, if a truck is destined for a bay that's closed (unhealthy target), the express lane simply blocks that lane and sends trucks to the next open bay (flow hashing). The key is that the express lane does not care what's inside the truck—it could be empty boxes (TCP health checks) or fragile electronics (HTTPS traffic)—it just moves it fast. This is why NLB is chosen when you need ultra-low latency (like real-time gaming, stock trading) and you want to keep the original source IP visible to the backend (e.g., for logging or geo-blocking).
What is the Network Load Balancer (NLB)?
The Network Load Balancer is a Layer 4 (Transport layer) load balancer that operates at the connection level, handling TCP, UDP, and TLS traffic. It is designed to handle millions of requests per second with ultra-low latencies (typically under 100 microseconds). Unlike the Application Load Balancer (ALB), which inspects HTTP/HTTPS headers and performs content-based routing, NLB simply forwards connections to targets based on the protocol, port, and a flow hash algorithm. This makes NLB ideal for scenarios where you need raw TCP/UDP performance, static IP addresses for whitelisting, or to offload TLS decryption while preserving client IP.
How NLB Works Internally
When a client sends a packet to the NLB's static IP address, the NLB's frontend (listener) receives the packet. The NLB uses a flow hash algorithm (based on source IP, source port, destination IP, destination port, and protocol) to select a target group and a specific target within that group. The NLB then rewrites the destination IP address to the target's private IP address (using DNAT) and forwards the packet. Critically, NLB does not modify the source IP address unless you configure proxy protocol. This means the target sees the original client IP, which is a key differentiator from ALB. The NLB is stateless per packet but stateful per flow: it maintains a connection tracking table for the duration of the TCP connection (or UDP flow) to ensure all packets of the same flow go to the same target. However, the NLB itself does not buffer packets or perform any Layer 7 processing.
Key Components and Defaults
Listeners: Define the protocol (TCP, UDP, TLS) and port (1-65535) on which the NLB accepts traffic. Each listener can forward to one target group.
Target Groups: A logical grouping of targets (EC2 instances, IP addresses, or Lambda functions for TCP only). Targets are registered by instance ID or IP address. Health checks are performed on each target using TCP, HTTP, or HTTPS on a configurable port and path.
Static IPs: Each NLB provides one static IP per Availability Zone (AZ) by default. You can optionally attach an Elastic IP (EIP) per AZ. These IPs do not change over the life of the load balancer.
Cross-zone load balancing: Disabled by default. When enabled, traffic is distributed evenly across all registered targets in all enabled AZs. When disabled, each AZ distributes traffic only to targets in its own AZ.
Flow Hash Algorithm: Uses a hash of the 5-tuple (source IP, source port, destination IP, destination port, protocol) to select a target. This ensures that all packets of a connection go to the same target, preserving connection affinity.
Proxy Protocol: An optional header (v2) that can be enabled on the target group to pass the client's source IP and port to the target. This is required when the target is behind another proxy or when the NLB's DNAT would otherwise hide the client IP.
TLS Termination: NLB supports TLS termination on the listener itself. You can upload a certificate (from ACM or IAM) and the NLB will decrypt TLS traffic before forwarding it to the targets as TCP. This offloads CPU-intensive decryption from the targets. However, NLB cannot do TLS passthrough (where the target handles TLS) if you terminate at the NLB; for passthrough, you use a TCP listener.
Preserve Client IP: By default, NLB preserves the client source IP when forwarding traffic to targets. This is a key difference from ALB, which always replaces the source IP with its own private IP. For IP targets (e.g., on-premises servers via Direct Connect), you must enable proxy protocol to see the client IP.
Idle Timeout: The default idle timeout for TCP connections is 350 seconds. For UDP, there is no timeout; the flow is maintained as long as traffic is seen. You can also set a custom idle timeout per listener (1-4000 seconds).
Connection Tracking: NLB maintains a table of active flows. The table size is automatically scaled. If a flow is idle beyond the timeout, it is removed.
Configuration and Verification
To create an NLB via AWS CLI:
aws elbv2 create-load-balancer --name my-nlb --type network --scheme internet-facing --subnets subnet-abc123 subnet-def456To create a TCP listener:
aws elbv2 create-listener --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/net/my-nlb/1234567890abcdef --protocol TCP --port 80 --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-tg/1234567890abcdefTo register targets:
aws elbv2 register-targets --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-tg/1234567890abcdef --targets Id=i-0123456789abcdef,Port=80To verify:
aws elbv2 describe-load-balancers --names my-nlb
aws elbv2 describe-target-health --target-group-arn arn:aws:...Interaction with Related Technologies
Global Accelerator: NLB can be used as a target for AWS Global Accelerator, which provides static anycast IPs and accelerates traffic over the AWS global network. This is a common exam scenario: NLB provides the static IPs for the backend, and Global Accelerator provides the frontend anycast IPs.
AWS PrivateLink: NLB is the service provider side of PrivateLink. When you create a VPC Endpoint Service, you associate an NLB that fronts your service. Consumers then create VPC Endpoints in their VPCs that connect to your NLB via PrivateLink.
Auto Scaling: NLB integrates with Auto Scaling groups. You can attach an Auto Scaling group to a target group, and the NLB will automatically register and deregister instances as they scale.
CloudWatch Metrics: NLB emits metrics such as ActiveFlowCount, NewFlowCount, ProcessedBytes, and TargetResponseTime.
Performance Characteristics
NLB is designed for high throughput and low latency. It uses AWS's Nitro chip for packet processing, achieving latencies in the microsecond range. It can handle millions of concurrent connections and up to 25 Gbps per NLB. There is no pre-warming required; NLB scales automatically. However, for very large spikes, it's recommended to pre-create connections if possible.
Common Exam Scenarios
Hybrid Architecture: You have an on-premises server that needs to be load balanced with EC2 instances. NLB supports IP targets, so you can register on-premises IP addresses as targets (via Direct Connect or VPN).
Real-time Gaming or Stock Trading: Applications that require ultra-low latency and cannot tolerate the overhead of Layer 7 processing.
Static IP for Whitelisting: When clients need to whitelist the load balancer's IP addresses (e.g., for firewall rules). NLB provides static IPs per AZ.
TLS Offload with Client IP Preservation: You want to offload TLS decryption to the load balancer, but the backend needs to see the original client IP. With NLB, you can terminate TLS at the listener and then forward TCP to targets; the client IP is preserved by default.
Important Limitations
NLB does not support sticky sessions (session affinity) based on cookies. It only supports flow hash affinity, which is based on the 5-tuple. If you need cookie-based stickiness, you must use ALB.
NLB does not support HTTP routing (path-based or host-based). It routes based on protocol and port only.
NLB does not provide a fixed DNS name that changes with IP changes (like ALB's dualstack DNS). The DNS name resolves to the static IPs.
NLB cannot be used with Lambda as a target for UDP; Lambda targets are only supported for TCP.
NLB does not support WebSockets natively (though TCP passthrough works).
Client sends SYN packet
A client initiates a TCP connection to the NLB's static IP address on port 443 (HTTPS). The SYN packet arrives at the NLB's frontend in the chosen Availability Zone. The NLB's Nitro chip inspects the 5-tuple (source IP, source port, destination IP, destination port, protocol). Using a hash of these fields, it determines which target group and which specific target (e.g., EC2 instance) should handle the connection. The NLB then rewrites the destination IP to the target's private IP address and forwards the SYN packet. No SYN-ACK is sent back to the client yet; the NLB is effectively performing a DNAT operation at the packet level. The NLB also creates an entry in its connection tracking table with the flow's 5-tuple, a timeout of 350 seconds (default), and the chosen target's identifier.
Target receives SYN and responds
The target EC2 instance receives the SYN packet with the source IP still being the client's original IP (because NLB does not change the source IP by default). The target's TCP stack processes the SYN and sends back a SYN-ACK packet. This SYN-ACK is destined for the client's IP address. However, the packet first arrives at the NLB (since the target's default route points to the NLB's subnet or via a transit gateway). The NLB's connection tracking table already has an entry for this flow. The NLB recognizes the SYN-ACK as belonging to the existing flow (based on the 5-tuple, reversed). It then rewrites the source IP to the NLB's own private IP (or the client-facing IP if the NLB is internet-facing, it uses the public IP of the NLB's ENI) and forwards the SYN-ACK back to the client. The client receives the SYN-ACK and completes the TCP handshake. At this point, the TCP connection is established between the client and the target, but with the NLB acting as a transparent proxy at Layer 4.
Data transfer occurs
Once the TCP connection is established, data packets flow bidirectionally. For each packet, the NLB consults its connection tracking table to determine the correct target. Because the NLB is stateless in terms of buffering, it forwards each packet immediately after the DNAT/SNAT operation. The NLB does not inspect or modify the payload. This is in contrast to an ALB, which would buffer the HTTP request and parse headers. The NLB's latency is therefore extremely low, typically under 100 microseconds. The connection tracking table is maintained until the connection is closed (FIN/RST) or the idle timeout expires. For UDP flows, the NLB maintains a similar table but with no timeout; it keeps the mapping as long as traffic is seen.
Connection termination or timeout
When the client or target sends a FIN packet to close the TCP connection, the NLB forwards it and continues to forward any remaining packets. After the connection is fully closed, the NLB removes the entry from its connection tracking table. If the connection becomes idle and exceeds the idle timeout (default 350 seconds), the NLB removes the entry. Subsequent packets for that flow will be treated as a new connection, potentially being directed to a different target (if the flow hash selects a different target). This is important for long-lived connections like WebSockets or database connections: you must ensure the idle timeout is set appropriately, or configure keep-alive packets to maintain the flow.
Health check monitoring
The NLB periodically sends health check requests to each target. By default, health checks are performed every 10 seconds with a timeout of 10 seconds and an unhealthy threshold of 3 consecutive failures. The health check is sent from the NLB's private IP addresses within the VPC. For TCP health checks, the NLB attempts to open a TCP connection to the target's IP and port. If the connection succeeds, the target is healthy. For HTTP/HTTPS health checks, the NLB sends an HTTP GET request and expects a 200 response. If a target fails health checks, the NLB marks it as unhealthy and stops sending new connections to it. However, existing connections to the unhealthy target are not terminated; they continue until the client or target closes them or the idle timeout expires. This is a common exam trap: candidates often think NLB immediately drops existing connections to unhealthy targets, but it does not.
Scenario 1: Real-Time Gaming Platform
A game company hosts a multiplayer game that requires sub-millisecond latency for real-time state synchronization. They use NLB to load balance game server instances across multiple Availability Zones. The game uses UDP for fast packet delivery. The NLB's static IP addresses are used by the game client to connect, and because the NLB preserves the client IP, the game server can log the client's IP for geo-location and cheating detection. The company configures cross-zone load balancing to evenly distribute players across all servers. They set the idle timeout to 60 seconds to quickly free up resources for short-lived UDP sessions. A common misconfiguration is forgetting to enable cross-zone load balancing, causing uneven distribution where one AZ's servers are overloaded while others are idle. Another issue is not using proxy protocol when the game servers are behind a NAT gateway or another load balancer, causing the server to see the NLB's IP instead of the client's IP.
Scenario 2: On-Premises Legacy Application Migration
An enterprise is migrating a legacy application that uses a proprietary TCP protocol to AWS. The application cannot be modified to use HTTP or to handle dynamic IP addresses. They deploy NLB with IP targets to include on-premises servers (connected via Direct Connect) alongside EC2 instances in the cloud. The NLB's static IPs are whitelisted in the on-premises firewall. They use TLS termination at the NLB to offload encryption, but the backend servers need to see the client IP for auditing. Because the targets are IP addresses, the default preserve client IP feature does not work (NLB cannot replace the destination IP with an IP target's IP without losing the source IP). They must enable proxy protocol on the target group to pass the client IP. A common mistake is assuming that preserve client IP works for IP targets, which it does not. The NLB's health checks are configured to use TCP on the same port, and the on-premises servers must allow traffic from the NLB's private IPs.
Scenario 3: High-Frequency Trading (HFT) Infrastructure
A financial services firm requires the lowest possible latency for order execution. They use NLB with a TLS listener to decrypt market data feeds, then forward the raw TCP data to trading engines. The NLB is deployed in a single AZ to minimize cross-AZ latency (since cross-zone load balancing adds latency). They attach Elastic IPs to the NLB for consistent addressing. The trading engines are EC2 instances with enhanced networking (ENA) and are placed in a placement group for low latency. The firm monitors NLB metrics like NewFlowCount and TargetResponseTime to detect anomalies. A common problem is that the NLB's flow hash can cause uneven distribution if the 5-tuple entropy is low (e.g., many connections from the same client IP and port range). They mitigate this by using multiple NLB listeners or by spreading traffic across multiple target groups.
What the SAA-C03 Tests on NLB
The exam tests your ability to choose the correct load balancer type for a given scenario. Key objective codes: 2.2 (Design highly available and/or fault-tolerant architectures), 2.3 (Design decoupling mechanisms using AWS services). You must know:
When to use NLB vs ALB vs Gateway Load Balancer.
That NLB operates at Layer 4 (TCP/UDP/TLS).
That NLB provides static IPs (one per AZ) and can use Elastic IPs.
That NLB preserves client IP by default (except for IP targets where proxy protocol is needed).
That NLB does not support path-based routing, host-based routing, or cookie-based stickiness.
That NLB can terminate TLS (offload) but cannot do TLS passthrough if you choose TLS listener.
That NLB can be used as a target for Global Accelerator and as a service provider for PrivateLink.
Common Wrong Answers and Why Candidates Choose Them
"Use ALB because it supports SSL termination." - Candidates forget that NLB also supports TLS termination. The exam will present a scenario where you need TLS offload AND client IP preservation AND static IPs. ALB cannot provide static IPs (its IPs change) and does not preserve client IP by default. The correct answer is NLB.
"Use NLB for HTTP traffic and path-based routing." - NLB does not support Layer 7 routing. Candidates confuse NLB's capabilities with ALB's. If the scenario mentions path-based routing, the answer is ALB.
"NLB provides a fixed DNS name that resolves to static IPs." - This is true, but some candidates think NLB's DNS name changes. The DNS name is static and always resolves to the same IPs (unless you change the subnets). This is a trick: the DNS name is fixed, but the IPs are also static. Both are true.
"NLB automatically distributes traffic evenly across all targets in all AZs." - By default, cross-zone load balancing is disabled. Each AZ sends traffic only to targets in that AZ. Candidates often assume it's enabled by default like ALB.
Specific Numbers and Terms
Default idle timeout: 350 seconds.
Health check default: interval 10 seconds, timeout 10 seconds, unhealthy threshold 3, healthy threshold 3.
Maximum connection duration: no limit, but idle timeout applies.
Supported protocols: TCP, UDP, TLS (for listeners).
Target types: instance, ip, lambda (TCP only).
Cross-zone load balancing: disabled by default.
Flow hash algorithm: 5-tuple hash.
Edge Cases and Exceptions
When using IP targets, preserve client IP does not work; you must use proxy protocol.
When using Lambda targets, only TCP is supported (not UDP).
NLB does not support Security Groups directly; security is controlled via network ACLs and security groups on the targets.
NLB cannot be used with AWS WAF (Web Application Firewall) because it operates at Layer 4.
NLB does not support HTTP/2 or WebSocket upgrade headers; for that, use ALB.
How to Eliminate Wrong Answers
If the scenario mentions "static IP addresses for whitelisting," eliminate ALB and Gateway Load Balancer. If it mentions "preserve client IP," eliminate ALB. If it mentions "ultra-low latency" or "millions of requests per second," NLB is the best choice. If it mentions "path-based routing" or "host-based routing," eliminate NLB. If it mentions "WebSocket" or "HTTP/2," eliminate NLB (unless it's a TCP passthrough scenario).
NLB is a Layer 4 load balancer for TCP/UDP/TLS traffic with ultra-low latency.
NLB provides one static IP per Availability Zone; you can attach an Elastic IP per AZ.
NLB preserves the client source IP by default (except for IP targets, which require proxy protocol).
Cross-zone load balancing is disabled by default for NLB (opposite of ALB).
NLB supports TLS termination but does not re-encrypt to targets; use TCP listener for passthrough.
NLB does not support path-based routing, host-based routing, or cookie-based stickiness.
NLB can be used as a target for AWS Global Accelerator and as a service provider for PrivateLink.
Default idle timeout is 350 seconds; health check interval is 10 seconds by default.
NLB cannot be associated with AWS WAF; use ALB for web application firewall.
When a target is unhealthy, existing connections are not terminated; only new connections are stopped.
These come up on the exam all the time. Here's how to tell them apart.
Network Load Balancer (NLB)
Operates at Layer 4 (TCP/UDP/TLS)
Provides static IP addresses per AZ (can attach Elastic IPs)
Preserves client source IP by default
Ultra-low latency (microseconds)
Supports TCP, UDP, TLS listeners only
Application Load Balancer (ALB)
Operates at Layer 7 (HTTP/HTTPS/gRPC)
Uses dynamic IP addresses (DNS name changes)
Replaces client source IP with its own private IP
Higher latency due to Layer 7 processing (milliseconds)
Supports HTTP, HTTPS, HTTP/2 listeners; path and host-based routing
Mistake
NLB supports session stickiness using cookies like ALB.
Correct
NLB does not support cookie-based stickiness. It only supports flow hash affinity based on the 5-tuple. All packets of a single TCP/UDP flow go to the same target, but connections from the same client can be distributed across different targets if the 5-tuple changes (e.g., different source port).
Mistake
NLB automatically enables cross-zone load balancing by default.
Correct
Cross-zone load balancing is disabled by default for NLB. This is opposite to ALB where it is enabled by default. You must explicitly enable it if you want traffic evenly distributed across all AZs.
Mistake
NLB terminates TLS and then re-encrypts traffic to targets.
Correct
NLB terminates TLS at the listener and forwards the decrypted traffic to targets as plain TCP. It does not re-encrypt. If you need end-to-end encryption, you must use a TCP listener and handle TLS on the targets (TLS passthrough).
Mistake
NLB preserves client IP for IP targets without any extra configuration.
Correct
When using IP targets (e.g., on-premises servers), NLB cannot preserve the client IP because it must replace the destination IP with the target's IP. To pass the client IP, you must enable proxy protocol on the target group.
Mistake
NLB can be used with AWS WAF for web traffic filtering.
Correct
NLB operates at Layer 4 and does not inspect HTTP headers. AWS WAF works at Layer 7 and requires an ALB (or CloudFront, API Gateway). You cannot associate a WAF ACL with an NLB.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
NLB does not support cookie-based sticky sessions like ALB. However, it provides flow hash affinity: all packets of a single TCP/UDP connection are sent to the same target based on a hash of the 5-tuple. If the client opens a new connection (different source port), it may go to a different target. For true sticky sessions, use ALB with stickiness enabled.
Yes, NLB supports TLS listeners that can terminate HTTPS traffic. You upload a certificate (from ACM or IAM) and the NLB decrypts the traffic before forwarding it as TCP to the targets. Alternatively, you can use a TCP listener and handle HTTPS on the targets (TLS passthrough).
NLB provides a static IP per Availability Zone automatically. You can also assign an Elastic IP (EIP) to each AZ for additional control. These IPs remain static for the life of the NLB. In contrast, ALB and CLB use dynamic IPs that can change.
Yes, NLB supports dualstack (IPv4 and IPv6) configurations. You can create an NLB with an IP address type of 'dualstack' to accept traffic over both IPv4 and IPv6. The static IPs are provided per AZ for both protocols.
Yes, but only for TCP listeners. Lambda targets are not supported for UDP. When using Lambda, the NLB invokes the Lambda function and passes the TCP payload. This is useful for lightweight processing without managing servers.
NLB does not perform UDP health checks. For UDP target groups, you must use TCP or HTTP/HTTPS health checks on a separate port, or you can use TCP health checks on the same port if the target also listens on TCP. Alternatively, you can disable health checks, but that is not recommended.
Gateway Load Balancer (GWLB) operates at Layer 3 (Network layer) and is used to deploy, scale, and manage third-party virtual appliances (e.g., firewalls, IDS/IPS). NLB operates at Layer 4 and is used for load balancing TCP/UDP traffic. GWLB uses the GENEVE protocol and preserves the original packet, while NLB uses DNAT.
You've just covered NLB: Static IPs, TLS Termination, Ultra-Low Latency — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?