What Does NLB Mean?

Imagine a busy pizza shop that gets dozens of delivery orders every minute. If only one person took all the orders, they would get overwhelmed and orders would be slow. Now imagine that the shop hires a team of order takers. But then the problem shifts: which order taker should the next customer call? If everyone calls the first number, that person is still overloaded. A Network Load Balancer (NLB) is like a smart phone system that automatically routes each incoming call to the order taker who is currently free or has the shortest queue. It keeps the system efficient and prevents any single worker from being bombarded.

In the same way, an NLB sits in front of a group of servers (called a server pool). When a user wants to visit a website or use an app, their request first hits the NLB. The NLB examines the request and, using a set of rules (like which server has the fewest active connections), forwards the request to the best server behind it. If one server becomes too busy or crashes, the NLB redirects traffic to the remaining healthy ones. This makes the whole system more resilient, faster, and able to handle more users at once. The user never knows which server handled their request, they just get a smooth experience.

A Network Load Balancer (NLB) operates at Layer 4 (Transport layer) of the OSI model, meaning it makes routing decisions based on TCP/UDP protocols, source and destination IP addresses, and port numbers. Unlike application load balancers (ALBs) that inspect HTTP headers, NLBs work with raw TCP/UDP traffic, making them ideal for handling millions of requests per second with extremely low latency.

Architecturally, an NLB is deployed in front of a target group, which consists of one or more servers (physical or virtual) running the same application or service. The NLB uses a predefined algorithm, most commonly round-robin, least connections, or source IP hash, to decide which target should receive each connection. In round-robin, requests are rotated evenly across servers. In least connections, the server with the fewest active sessions gets the next request. Source IP hash ensures that a given user is always sent to the same server, which is useful for session persistence.

NLBs can be either hardware-based (like a dedicated appliance from F5 or Citrix) or software-based (such as AWS Network Load Balancer, HAProxy, or NGINX). In cloud environments, NLBs are fully managed services that scale automatically. They also support health checks, which are periodic probes sent to each target server to verify it is still online and responsive. If a server fails a health check, the NLB stops sending traffic to it until it recovers.

Modern NLBs also offer cross-zone load balancing, which distributes traffic evenly across servers in multiple availability zones for fault tolerance. Sticky sessions (session affinity) can be implemented using the source IP hash algorithm or by inserting a cookie (though NLBs are limited compared to ALBs in this regard). Because NLBs operate at such a high speed, they are often used for real-time applications like gaming, VoIP, streaming, and financial trading platforms where every millisecond counts.

In modern IT infrastructure, applications must be always-on and responsive. A single server can only handle a limited number of simultaneous connections. Without an NLB, the server would become overloaded, response times would increase, and users would experience timeouts or errors. Worse, if that single server fails, the entire application goes down. NLBs solve both problems by spreading the load across multiple servers and providing automatic failover.

For IT professionals, understanding NLB is critical because nearly every production deployment uses some form of load balancing. Whether you are setting up a web application, a database cluster, or a microservices architecture, you will likely need to configure an NLB. It ensures high availability (the application stays up even if some servers fail) and scalability (you can add more servers to handle increased traffic without changing the user-facing address).

From a cost perspective, NLBs allow you to use standard, less expensive servers instead of one giant supercomputer. They also make maintenance easier, you can take a server offline for updates while the NLB continues routing traffic to the others. This is often called a rolling update. Without an NLB, you would have to schedule downtime or accept a degraded user experience during maintenance.

Exam questions about NLB fall into three main categories: architecture choice, feature identification, and troubleshooting.

Architecture choice questions present a scenario and ask you to pick the right load balancer. Example: "A company runs a real-time multiplayer game on EC2 instances. They need a load balancer that can handle 20 million concurrent connections with minimal latency. Which type of load balancer should they use?" The correct answer is Network Load Balancer because it operates at Layer 4 and can handle millions of requests per second with extremely low latency, unlike Application Load Balancers which operate at Layer 7 and introduce more overhead.

Feature identification questions may ask: "Which of the following is a characteristic of a Network Load Balancer? A) It can route based on HTTP headers B) It can perform TLS termination C) It operates at Layer 4 of the OSI model D) It can only be used with HTTP traffic." The correct answer is C. You must know that NLB does not inspect application-layer data.

Troubleshooting questions often involve health checks. Example: "After deploying an NLB, users report that some requests fail. The backend servers are running. What is the most likely cause?" The answer could be that the health check target is incorrectly configured, so the NLB marks healthy servers as unhealthy and stops sending traffic to them. Another tricky point: NLBs support cross-zone load balancing, but if it is disabled, traffic may be unevenly distributed even if backend servers are healthy.

Configuration questions may ask: "You need to ensure that a user’s session is always routed to the same server during the session. Which load balancing algorithm should you configure?" Answer: source IP hash. Or they might ask about sticky sessions, remember that NLBs support sticky sessions using source IP hashing, not cookies (that is ALB’s domain).

Finally, expect questions that ask you to compare NLBs with ALBs or Classic Load Balancers. Know the OSI layer, supported protocols (TCP/UDP vs HTTP/HTTPS), performance characteristics, and pricing model. NLB is typically more expensive per hour but cheaper per request at high scale.

When you start working with a Network Load Balancer in a real cloud environment, the first thing you need to understand is the target group. The target group is a logical grouping of your backend servers (EC2 instances, IP addresses, or Lambda functions). You define which port the servers listen on (e.g., 443 for HTTPS) and the protocol (TCP). Each target group can have a single health check configuration that applies to all its targets.

After creating the target group, you create the NLB itself. You must specify a scheme: internet-facing (public IP) or internal (private IP only for internal VPC traffic). You also choose IP address type (IPv4 or dual-stack). For internet-facing NLBs, AWS automatically assigns a public IP address per Availability Zone. This is important: an NLB is always zone-bound. If you enable multiple Availability Zones, you get an NLB node in each zone, and traffic is distributed across those nodes.

One common configuration pitfall is forgetting to configure the listener. A listener checks for connection requests on a specified port and protocol. For example, you create a TCP listener on port 443. Then you define a default action: forward requests to the target group you created. You can also define a default action that returns a fixed response (like 503) if you want to block traffic temporarily.

Health checks require careful tuning. The health check protocol can be TCP, HTTP, or HTTPS. For TCP health checks, the NLB tries to open a TCP connection to the target port. If the server accepts the connection within the timeout, it is considered healthy. For HTTP health checks, the server must return a 2xx or 3xx status code. The interval is how often the check runs (default 10 seconds). The unhealthy threshold is how many consecutive failures before marking the server as unhealthy (default 2). Setting these values too aggressive can cause healthy servers to be removed during brief pauses; setting them too lax can keep dead servers in the pool longer than necessary.

What can go wrong? First, security groups. The backend servers’ security groups must allow traffic from the NLB’s IP addresses (or from the VPC CIDR if cross-zone is disabled). Second, route tables: if the NLB is internet-facing, it must be deployed in a public subnet with an Internet Gateway. Third, timeouts: some applications have idle timeouts that drop connections if no data is sent for a while. NLB has an idle timeout of 350 seconds by default. If your application sends long-lived connections, you may need to adjust that.

In practice, professionals often pair NLB with Auto Scaling groups to automatically add or remove servers based on demand. The NLB’s target group can be attached to an Auto Scaling group so that new instances are automatically registered as targets, and terminated instances are deregistered. This creates a fully elastic, highly available architecture.