# Load balancer

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/load-balancer

## Quick definition

A load balancer spreads work evenly among multiple servers. It prevents any one server from getting too busy and breaking down. It makes websites and apps faster and more reliable for users. Think of it like a traffic cop directing cars to different lanes so no lane gets jammed.

## Simple meaning

Imagine a busy restaurant with one cashier. Customers line up, and the cashier takes orders one by one. This works until a lunch rush hits, and the line gets long. People get frustrated, some leave, and the cashier gets overwhelmed. Now imagine the restaurant has four cashiers. The manager (the load balancer) watches the line and sends each customer to the shortest available line. No one waits too long, the cashiers stay calm, and the restaurant serves more people. In IT, the same idea applies. A website or app runs on many servers instead of one. When millions of people try to access it at once, the load balancer decides which server handles each request. It checks which servers are healthy, how busy they are, and sends new traffic to the least loaded one. If a server gets sick (crashes) the load balancer stops sending traffic to it and sends all traffic to the remaining healthy servers. This makes the whole system fast, reliable, and able to grow when more users show up.

There are two main types: hardware load balancers and software load balancers. Hardware ones are physical appliances that sit in a data center. Software ones run on regular computers or in the cloud. Cloud providers like Amazon Web Services and Microsoft Azure offer load balancing as a service. You just configure it and it runs automatically. Load balancers also do other jobs. They can check the health of servers by sending test requests. They can terminate encrypted traffic and then send unencrypted traffic to internal servers, reducing the work on each server. They can also provide sticky sessions, which means a user who is shopping will keep going to the same server so their shopping cart doesn't disappear. In short, the load balancer is the intelligent traffic director that keeps applications fast, available, and scalable.

## Technical definition

A load balancer is a network device or software application that distributes client requests across a group of backend servers, known as a server pool or server farm. The primary goal is to optimize resource use, maximize throughput, minimize response time, and avoid overloading any single server. Load balancers operate at different layers of the OSI model. Layer 4 load balancers work at the transport layer, using information like IP addresses and TCP/UDP ports to make forwarding decisions. Layer 7 load balancers work at the application layer and can inspect the content of the request, such as HTTP headers, URLs, cookies, or even the body of the request, to route traffic intelligently.

Load balancers use various scheduling algorithms to decide how to distribute traffic. Round robin sends each new request to the next server in a circular list. Least connections sends traffic to the server with the fewest active connections. Weighted variations allow you to give more traffic to more powerful servers. IP hash uses the client IP to determine which server handles the request, ensuring the same client always goes to the same server. Load balancers also perform health checks, sending periodic requests (like ping, TCP connect, or HTTP GET) to each server. If a server does not respond correctly within a timeout, the load balancer marks it as unhealthy and stops sending traffic to it. When the server recovers, the load balancer marks it healthy again and resumes traffic.

In modern IT environments, load balancers are often deployed in a high-availability pair, where one active load balancer handles traffic and a passive one stands ready to take over if the active one fails. Virtual IP addresses are used, which float between the pair. Load balancers also handle SSL/TLS termination. Incoming encrypted HTTPS traffic is decrypted at the load balancer, and then unencrypted HTTP traffic is sent to backend servers. This offloads the cryptographic work from the servers and centralizes certificate management. Load balancers can also perform content caching, compression, and access control. They can be deployed on-premises as hardware appliances, as virtual appliances, or as cloud services like AWS Elastic Load Balancing or Azure Load Balancer. When used with auto-scaling groups, a load balancer automatically detects new servers that spin up and starts sending traffic to them, and removes servers that are terminated. This is critical for elastic cloud architectures where capacity changes dynamically based on demand.

Security features are also common. Load balancers can help mitigate distributed denial-of-service attacks by rate limiting, filtering malicious traffic, and absorbing some of the attack volume. They can also integrate with web application firewalls (WAF) to block application-layer attacks. For exam purposes, knowing the difference between Layer 4 and Layer 7, the common algorithms, health check methods, and the role of load balancers in high-availability and scaling scenarios is essential. The Network+ exam expects you to understand the basic purpose and types. The Security+ exam may ask about load balancers in the context of availability and redundancy. The Azure AZ-104 exam goes deep into configuring Azure Load Balancer, including frontend IP configurations, backend pools, health probes, load balancing rules, and NAT rules for inbound traffic.

## Real-life example

Think about a busy highway with multiple toll booths. On a normal day, each toll booth has a line of cars. But sometimes, a booth closes because a toll operator gets sick. Immediately, cars that were heading to that booth have to merge into the other lanes, causing a huge backup and angry drivers. Now imagine the highway has a Smart Toll Director. This director uses cameras and sensors to see how many cars are waiting at each booth. It also knows which booths are open and which are closed. When a car approaches, the director flashes a green arrow pointing to the booth with the shortest line. If a booth goes offline, the director stops sending cars there and redistributes them evenly across the remaining booths. Every car gets through faster, even during rush hour. If a new booth suddenly opens, the director instantly starts sending cars there. The Smart Toll Director is the load balancer. The booths are the servers. The cars are the user requests. The director’s job is to keep traffic flowing smoothly, avoid jams, and adapt to changes instantly.

Now map this to a real IT scenario. A popular e-commerce website runs on ten web servers. During a flash sale, millions of customers try to buy products at the same time. Without a load balancer, all requests might go to one server, which would crash under the load. With a load balancer, each new connection is directed to the server with the fewest active users. If one server becomes slow because its hard drive is failing, the load balancer notices it is not responding to health checks and stops sending traffic there. The server gets repaired while the other nine handle the load seamlessly. Users never notice the problem. The website stays up, sales continue, and customers are happy. This is the power of load balancing in real life.

## Why it matters

In modern IT, applications must serve thousands or millions of users simultaneously. A single server can only handle a limited number of connections and requests. If that server fails, the entire application goes down, causing lost revenue and frustrated users. Load balancers solve both problems: they distribute load so no server is overwhelmed, and they provide high availability by rerouting around failures. This is not a luxury; it is a necessity for any serious production system. Professionals must understand load balancing to design resilient architectures, optimize performance, and plan for growth.

load balancers are central to cloud computing. In Azure, AWS, and Google Cloud, load balancers are first-class services that integrate with virtual machines, containers, serverless functions, and auto-scaling groups. Certifications like Azure AZ-104 specifically require you to configure and manage load balancers. Even if you are not a network specialist, you will encounter load balancers in day-to-day operations, troubleshooting, and capacity planning. Knowing how they work helps you diagnose performance issues, plan for traffic spikes, and ensure business continuity.

## Why it matters in exams

Load balancers appear in multiple certification exams, each with a different emphasis. For the CompTIA Network+ (N10-008), load balancers are part of domain 2.0 (Infrastructure) and domain 3.0 (Network Operations). You need to know the basic function, the difference between hardware and software load balancers, and common algorithms like round robin and least connections. Questions are often conceptual or scenario-based, asking you to choose the best device for a given situation.

For the CompTIA Security+ (SY0-601), load balancers appear in domain 2.0 (Architecture and Design) under high availability and redundancy. They also appear in domain 4.0 (Operations and Incident Response) when discussing DDoS mitigation. You should understand how load balancers can improve availability but also introduce security considerations such as SSL termination points and sticky sessions. Security+ questions might ask you to identify which security goal (confidentiality, integrity, availability) is supported by a load balancer, or to recommend a mitigation technique.

For Microsoft Azure AZ-104 (Microsoft Azure Administrator), load balancers are a major objective. The exam includes creating and configuring Azure Load Balancer, including frontend IP configurations, backend pools, health probes, load balancing rules, and NAT rules. You must also know the differences between Azure Load Balancer, Application Gateway, and Traffic Manager. Expect scenario questions where you choose the correct load balancing solution based on requirements like SSL termination, global routing, or internal load balancing. You might be asked to troubleshoot a load balancer that is not distributing traffic correctly, which requires understanding of health probes and backend pool membership.

In all exams, common question types include definition matching, scenario-based selection, and troubleshooting. Being able to articulate why a particular load balancing algorithm is chosen and how health checks work will give you an edge.

## How it appears in exam questions

Exam questions rarely ask you to recite a definition. Instead, they present a scenario and ask you to choose the correct technology, algorithm, or configuration. For example, a Network+ question might describe a company with five web servers handling user requests. They need a device to evenly distribute traffic and automatically remove failed servers. The correct answer could be a Layer 4 load balancer with round robin algorithm. Another question might give you a server response time graph and ask which load balancing technique would best improve performance.

Security+ questions often focus on availability. For instance: A company wants to ensure their e-commerce site remains online during a DDoS attack that targets a single server. Which solution should they implement? Answer: A load balancer with multiple servers and health checks. Another security question might ask about the security risk of sticky sessions, where an attacker could hijack another user's session if they get the same server.

AZ-104 questions are more hands-on. A typical question: You need to configure an Azure Load Balancer to distribute HTTP traffic to two virtual machines in the same backend pool. The health probe should check the health of each VM every 15 seconds. What should you configure? You must know the probe protocol (HTTP on port 80), the interval, and the unhealthy threshold. Another question might show a load balancer configuration and ask why traffic is not reaching the backend VMs. Possible answers: the health probe is misconfigured, the backend pool is empty, or the NSG (network security group) is blocking the probe traffic.

Scenario questions may also require you to differentiate between load balancers and other network devices. For example: A router forwards packets based on IP address. A switch forwards based on MAC address. A load balancer forwards based on algorithm and server health. Understanding these distinctions helps you choose the right answer.

## Example scenario

Scenario: You are an IT intern at a mid-sized company that runs a customer support website. The site runs on a single web server in the office. Recently, the site became very slow during lunch hours when many customers log in. Twice in the past month, the server crashed and the site was down for an hour. Your manager asks you to propose a solution that can handle more traffic and keep the site up even if a server fails.

You propose using a load balancer with two web servers. The load balancer sits between the internet and the servers. It accepts all incoming requests and forwards them to one of the two servers. You configure the load balancer to use the least connections algorithm so that new requests go to the server with fewer active users. You also configure health checks: every 10 seconds, the load balancer sends a request to each server’s health endpoint. If a server does not respond in 5 seconds, the load balancer marks it as unhealthy and stops sending traffic to it. The remaining server handles all traffic until the failed server is repaired.

After implementing this solution, the website remains fast even during peak hours. When one server crashed due to a memory leak, the second server took over seamlessly, and users did not notice any downtime. Your manager is impressed, and you learn that load balancing is a simple yet powerful way to improve reliability and performance. This scenario is typical of the types of problems you will solve in the real world and on certification exams.

## Load Balancer Algorithm Types and Selection Criteria

Load balancers distribute incoming network traffic across multiple backend servers using specific algorithms. The choice of algorithm directly impacts performance, resource utilization, and user experience. Understanding these algorithms is critical for Azure AZ-104, Network+, and Security+ exams because they test both conceptual knowledge and practical configuration decisions.

Round Robin is the simplest algorithm, where each new request is sent to the next server in a circular list. It works well when all servers have identical capacity and the workload is uniform. However, it does not account for current server load, which can lead to uneven distribution if requests vary in processing time. In Azure Load Balancer, round robin is the default distribution mode for backend pools. Exam questions often ask when round robin is appropriate versus more advanced methods.

Least Connections directs traffic to the server with the fewest active connections. This is more intelligent than round robin because it accounts for current load. It is ideal for long-lived connections like database queries or streaming media. In an Azure Load Balancer scenario, you might choose least connections when your backend VMs handle variable-length sessions. Network+ exams test your ability to identify which algorithm prevents server overload in dynamic traffic patterns.

Source IP Affinity (also called session persistence) ensures that a client's requests always go to the same backend server. This is essential for applications that store session state locally, such as shopping carts or authentication tokens. Azure Load Balancer implements this by hashing the source IP to a specific backend. Security+ exams include this in discussions about maintaining state in stateless architectures. A common exam trick is to ask what happens if persistence is not configured: users may lose session data.

Weighted Round Robin and Weighted Least Connections allow administrators to assign higher weights to more powerful servers. For example, if you have one server with double the capacity, you can give it a weight of 200 while others get 100. This is tested in AZ-104 scenarios where you need to optimize a mixed-hardware backend pool. The exam expects you to understand that weights do not guarantee exact traffic ratios but approach them statistically over time.

Hash-based algorithms calculate a hash from packet attributes like source IP, port, or protocol. This is used in Azure Load Balancer's session persistence mode and in Content Delivery Networks. Network+ exams ask about how hash distribution ensures even load across multiple cache servers. A key concept is that hash consistency is important: changing the number of backend servers causes rehashing and potential cache misses.

Finally, the Least Response Time algorithm sends requests to the server with the fastest recent response time. This is common in cloud-native load balancers and application gateways. It requires continuous health probing to measure response latency. Security+ exams may include this under resilience and failover strategies.

In Azure, the standard Load Balancer supports round robin and source IP affinity. For advanced algorithms, you would use Azure Application Gateway or Traffic Manager. Understanding these distinctions is crucial: AZ-104 questions often describe a scenario and ask which Azure service or algorithm meets the requirement. Network+ expects you to know the basic algorithms by name and use case. Security+ focuses on the implications of persistence and state management.

## Health Probes: The Backbone of Load Balancer Reliability

Health probes are the mechanism by which load balancers determine the operational status of each backend server. Without accurate health probes, a load balancer would continue sending traffic to failed servers, causing application outages. This topic is heavily tested in AZ-104, Network+, and Security+ exams because it touches on monitoring, resilience, and security.

A health probe sends periodic requests to a specified endpoint on each backend server. The endpoint can be an HTTP page, a TCP port, or an HTTPS endpoint. The probe expects a specific response within a timeout period. If the server does not respond or returns an error, it is marked as unhealthy and removed from the load balancer's rotation. Once the probe succeeds again, the server is reinstated. Azure Load Balancer uses this mechanism for both public and internal load balancers.

HTTP health probes are the most common. They test a specific URL path, like /health or /status. The backend application must return a 200 OK response for the probe to consider it healthy. Any other response (404, 500, or even a redirect) will mark the server as unhealthy. In AZ-104 exams, you must know that HTTP probes check the application layer, making them more accurate than TCP probes for web applications. For example, if a web server is running but the application pool is down, a TCP probe would still return success because the port is open, whereas an HTTP probe would fail. This is a classic exam question.

TCP health probes simply check whether a TCP port is open and accepting connections. They are faster and simpler than HTTP probes but less precise. Use TCP probes when the backend application is not HTTP-based, such as a database or custom service. Network+ exams test your understanding that TCP probes only verify network-level connectivity, not application health. A typical question might ask: You have a load-balanced web application that shows errors. TCP probes show all servers healthy. What is wrong? The answer is likely that TCP probes are passing but the application is crashing.

HTTPS health probes work like HTTP probes but with TLS termination. They require valid certificates on the backend, which can add complexity. Security+ exams discuss this in the context of encrypted traffic inspection: the load balancer must trust the backend certificate or use a self-signed certificate configured within the probe definition.

Probe frequency and thresholds are configurable. The interval between probes, the number of consecutive failures to mark unhealthy, and the number of successes to mark healthy all affect how quickly a load balancer reacts to failures. Shorter intervals improve detection speed but increase backend load. AZ-104 scenarios often ask you to adjust these values based on application sensitivity. For example, a real-time application might need a 5-second interval with 2 failures threshold, while a background service might use a 30-second interval with 5 failures.

A critical security aspect is that health probes can be exploited if not properly secured. The probe endpoint should not expose sensitive data or be accessible from the internet. Azure automatically restricts internal load balancer probes to Azure's own infrastructure, but for public load balancers the probe IP range is documented and should be allowed in firewalls. Security+ will test that you must whitelist the Azure Load Balancer probe IPs (168.63.129.16) in your network security groups. Missing this is a common misconfiguration that leads to unhealthy backends.

Finally, consider probe design for high availability. Multiple probes per pool can be used, but typically a single probe is associated with an entire backend pool. Advanced setups use separate probes for different ports. The exam expects you to know that a backend VM can be part of multiple load balancer pools with different probes.

## Session Persistence in Load Balancers: Sticky Sessions and Their Impact

Session persistence, commonly called sticky sessions, ensures that all requests from a single client are directed to the same backend server for the duration of a session. This is crucial for stateful applications that store user data locally, such as shopping carts, login tokens, or multi-step forms. Without persistence, a user might add an item to their cart, then get redirected to a different server where the cart is empty. This concept appears in AZ-104, Network+, and Security+ exams, with emphasis on when to use it and its security implications.

Azure Load Balancer offers three modes of session persistence: None (default), Client IP, and Client IP and Protocol. The None mode disables persistence, meaning each request can go to any backend server. This is suitable for stateless applications where session data is stored in a central database or cache like Redis. Exam questions often ask why an administrator would choose None: to avoid server load imbalance caused by sticky sessions.

Client IP persistence uses the source IP address to determine which backend server receives the request. The load balancer hashes the source IP to a specific server. This works well when clients have stable IP addresses, but it can cause problems behind NAT gateways or corporate proxies where multiple users share the same IP, concentrating load on one server. AZ-104 tests your ability to identify this risk: if you have a client VPN with thousands of users behind a single IP, Client IP persistence will overload one backend.

Client IP and Protocol persistence adds the protocol (TCP or UDP) to the hash. This ensures that a client's HTTP session stays on one server, while a separate FTP session could go to another. This mode is rarely needed but appears in advanced networking exams. A common Network+ question asks which persistence mode prevents a user from being bounced between servers during a file upload.

Cookie-based persistence is used by Layer 7 load balancers like Azure Application Gateway and third-party solutions (e.g., F5, NGINX). The load balancer inserts a cookie into the client's browser, and subsequent requests include that cookie for server selection. This is more reliable than IP-based persistence because it works even when clients change networks or use different devices. Security+ exams highlight that cookie-based persistence introduces security considerations: cookies can be stolen or manipulated, so they must be encrypted and signed.

A key exam point is that session persistence can cause uneven load distribution. If one user generates many requests (e.g., a web scraper or a user with many tabs), that server may become overloaded while others are idle. This is called the "sticky server problem." AZ-104 questions ask how to mitigate this: use a shared state store like Azure Cache for Redis instead of relying on the backend server's memory.

session persistence affects failover. If a server fails, the client's session is lost unless the application stores state externally. The load balancer does not replicate sessions. This is a critical troubleshooting clue: after a server crash, users report being logged out or losing data. The solution is to implement stateless design or use an external session store.

Security implications are tested in Security+. An attacker could exploit persistence to target a specific server and then use session fixation to hijack another user's session. The exam expects you to understand that persistence should be combined with proper authentication and session timeouts. Also, in load balancers that support SSL offloading, the persistence cookie must be set after decryption, as the original SSL session ID is not visible.

Finally, remember that Azure Load Balancer (Layer 4) does not support cookie-based persistence; you must use Azure Application Gateway (Layer 7) for that. Choosing between them is a common AZ-104 decision scenario.

## High Availability Ports in Azure Load Balancer: Concept and Configuration

High Availability (HA) Ports is a feature of Azure Load Balancer's Standard SKU that simplifies load balancing of all ports and protocols to a set of backend virtual machines. Instead of creating individual load balancing rules for each port, a single rule with protocol set to All and port set to 0 enables traffic on all ports (1-65535) to be distributed across the backend pool. This is a game-changer for virtual appliances like firewalls, intrusion detection systems, and routers that handle multiple protocols and ports. This concept is tested in AZ-104 and Network+ due to its impact on network design and simplification.

The primary benefit of HA Ports is configuration reduction. In a traditional setup, if you need to load balance traffic for HTTP (80), HTTPS (443), DNS (53), and a custom app on port 8080, you would create four separate rules. With HA Ports, one rule covers all. This reduces complexity and the risk of misconfiguration. AZ-104 exams ask when HA Ports are appropriate: when the backend appliance must process all traffic types without port filtering at the load balancer level.

However, HA Ports do not provide any traffic filtering. They simply distribute all inbound traffic. Security must be implemented at the backend or with Network Security Groups (NSGs). This is a key exam point: you cannot use HA Ports with a public load balancer to allow all ports through a firewall because you would expose your entire backend to the internet. Instead, you typically use HA Ports with internal load balancers, directing traffic to a network virtual appliance (NVA) that then inspects and forwards traffic.

The HA Ports rule uses the same distribution algorithm as standard rules (round robin by default). You can also configure session persistence (Client IP) if needed. The health probe still applies, usually on a specific port like 80 or 443, to verify the appliance is operational. Network+ questions test that the health probe is a separate configuration from the HA Ports rule.

A common exam scenario: You are deploying a next-generation firewall (NGFW) as an NVA. You want all traffic from an internal subnet to pass through the NGFW for inspection. You create an internal load balancer, add the NGFW VMs to the backend pool, configure HA Ports rule, and then point the subnet's route table to the load balancer's frontend IP. This is a classic Azure hub-and-spoke design. The exam expects you to know that HA Ports handle both TCP and UDP traffic-something individual rules do not easily do for multiple protocols.

Limitations also appear in exam questions. HA Ports are not supported on Basic SKU load balancers. They require Standard SKU and at least one backend VM to be healthy. Also, you cannot combine HA Ports with outbound rules on the same load balancer frontend; you need separate load balancers for inbound and outbound flow. This is a common trick question in AZ-104: can you have an outbound rule and an HA Ports rule on the same frontend IP? Answer: No.

Troubleshooting HA Ports involves verifying that the backend VMs are listening on the expected ports. Even though the rule covers all ports, the backend must actually run services on those ports. If a VM is not listening on port 12345, traffic for that port will be dropped. The load balancer only distributes; it does not generate traffic. This is a subtle point: HA Ports do not open firewall ports; the NSG and the VM's own firewall must allow the traffic.

Security+ implications: Since HA Ports forward all traffic, any unsecured service on the backend VM could be exploited. Therefore, HA Ports should be used only when the backend is a hardened appliance with its own security policies. In practice, this means the backend VMs should not have public IPs, and NSGs should restrict traffic to only what the NVA needs.

Finally, remember that HA Ports do not work with Floating IP (Direct Server Return) because the backend must be able to listen on the same IP as the load balancer frontend-which is usually not the case for NVAs. This advanced point appears in some exam depth questions.

## Common mistakes

- **Mistake:** Thinking that a load balancer makes servers faster by doing the work for them.
  - Why it is wrong: A load balancer does not process the actual request; it only distributes the requests. The servers still do all the work. The performance gain comes from spreading the load so no server is overwhelmed.
  - Fix: Understand that load balancers optimize resource utilization, not the speed of each individual server.
- **Mistake:** Confusing a load balancer with a router.
  - Why it is wrong: A router forwards packets based on IP address destination. A load balancer makes intelligent forwarding decisions based on server health, load, and application data. Routers do not have health checks or algorithms.
  - Fix: Remember that a load balancer is a specialized device that monitors server health and distributes traffic intelligently.
- **Mistake:** Believing that a load balancer can prevent all types of server failures.
  - Why it is wrong: A load balancer can redirect traffic away from a failed server, but it cannot fix the failed server. It also cannot protect against failures like a corrupt database or buggy application code that affects all servers.
  - Fix: Use load balancers as part of a broader high-availability strategy that includes redundancy, monitoring, and automated recovery.
- **Mistake:** Assuming that adding more servers always improves performance without adjusting the load balancer configuration.
  - Why it is wrong: If you add servers but do not update the backend pool, the load balancer will not send traffic to them. Health probes must also be correctly configured for new servers.
  - Fix: Always register new servers in the backend pool and ensure health probes are correctly targeting them.
- **Mistake:** Setting the health probe interval too long, causing slow failure detection.
  - Why it is wrong: If the probe interval is 60 seconds, it could take over a minute to detect a failed server. During that time, traffic is still sent to the failed server, resulting in errors.
  - Fix: Set interval to a shorter value like 5 or 10 seconds, and configure a low number of failed probes before marking a server as unhealthy.
- **Mistake:** Using sticky sessions without understanding the security risks.
  - Why it is wrong: Sticky sessions route a user to the same server using a cookie or source IP hash. If the cookie is not secure, an attacker could intercept or forge it. Also, if the server fails, the user loses session state.
  - Fix: Use sticky sessions only when necessary for stateful applications, and secure the session cookie with encryption and HttpOnly flags. Consider using a shared session store (like Redis) instead.

## Exam trap

{"trap":"Choosing a router or switch when a load balancer is needed.","why_learners_choose_it":"Learners see that traffic needs to be distributed among multiple servers and think any networking device can do it. They confuse forwarding with distribution.","how_to_avoid_it":"Remember that only load balancers have built-in health checks, load balancing algorithms, and the ability to route based on application-layer data. A router forwards packets, a switch forwards frames, but they do not monitor server health."}

## Commonly confused with

- **Load balancer vs Router:** A router forwards packets between networks based on IP addresses, using routing tables. It does not monitor server health or distribute traffic based on load. A load balancer uses health checks and algorithms to distribute traffic across multiple servers. (Example: A router sends your request to the ISP. A load balancer sends your request to the least busy web server in your data center.)
- **Load balancer vs Network switch:** A switch forwards Ethernet frames within the same network based on MAC addresses. It does not make application-level decisions. A load balancer can make decisions based on HTTP headers, URLs, or server health. (Example: A switch connects all servers to the same network. A load balancer decides which server handles the request.)
- **Load balancer vs Reverse proxy:** A reverse proxy can do many of the same things as a load balancer, such as caching, SSL termination, and forwarding. However, a load balancer focuses specifically on distribution and high availability. A reverse proxy may also serve content from cache. (Example: A load balancer distributes traffic evenly. A reverse proxy may also cache static resources so the request never reaches a server.)
- **Load balancer vs Content delivery network (CDN):** A CDN caches content at edge locations close to users to reduce latency. A load balancer distributes traffic among servers in a data center. CDN improves performance for static content; load balancer improves reliability and scalability of dynamic content. (Example: A CDN stores a copy of your logo on a server near the user. A load balancer sends the user's login request to the server with the lowest load.)
- **Load balancer vs Firewall:** A firewall filters traffic based on security rules. A load balancer distributes traffic based on performance goals. A firewall can block malicious IPs. A load balancer can help mitigate DDoS by absorbing traffic but does not inspect packets for threats. (Example: A firewall blocks traffic from a known attacker. A load balancer sends traffic from unknown users to the least loaded server.)

## Step-by-step breakdown

1. **Client makes a request** — A user types a URL into a browser or an app sends an API call. The request goes to the domain name system (DNS) which resolves the domain to the public IP address of the load balancer. The request arrives at the load balancer's frontend IP and port (e.g., 203.0.113.1:443).
2. **Load balancer receives the request** — The load balancer accepts the incoming TCP connection or HTTP request. It sees the source IP, destination IP, protocol, and port. If it is a Layer 7 load balancer, it also sees the HTTP method, path, headers, cookies, and sometimes the request body.
3. **Health check verification** — Before forwarding, the load balancer checks its list of backend servers and their health status. Each server is periodically tested via a health probe (e.g., HTTP GET to /health). Only servers that respond with a 200 OK within the timeout are considered healthy and eligible to receive traffic.
4. **Algorithm selection** — The load balancer applies a scheduling algorithm to choose which healthy server should handle the request. For example, round robin would send the request to the next server in the list. Least connections would send it to the server with the fewest active connections.
5. **Sticky session check (optional)** — If sticky sessions are enabled, the load balancer checks for a session cookie or uses the source IP hash to determine whether this client should be routed to the same server as before. If a matching entry exists, the request is sent to that server regardless of the algorithm.
6. **Forwarding the request** — The load balancer rewrites the destination IP address to the chosen backend server's private IP address and forwards the request. For Layer 4, it maps the TCP connection. For Layer 7, it creates a new HTTP request to the backend server, optionally modifying headers (e.g., adding X-Forwarded-For).
7. **Backend server processes the request** — The backend server receives the request, processes it (e.g., queries a database, renders a page), and sends the response back to the load balancer. The load balancer may also cache the response or compress it before sending back.
8. **Response returned to client** — The load balancer receives the response from the backend server and forwards it to the original client. The client sees this as a direct response from the load balancer's IP address. The client is unaware that a backend server handled the actual work.
9. **Connection closing and logging** — The TCP connection is closed or kept alive depending on configuration. The load balancer logs the request details (timestamp, source IP, backend server, response code, response time). These logs help with monitoring and troubleshooting.

## Practical mini-lesson

In practice, deploying a load balancer involves careful planning around your application architecture. First, decide whether you need a Layer 4 or Layer 7 load balancer. Layer 4 is simpler and faster, ideal for TCP/UDP traffic. Layer 7 gives you more control for HTTP/HTTPS applications, such as URL-based routing or header inspection. Most modern applications use Layer 7 because it allows you to route /api/* requests to a separate pool of backend servers than /static/* requests, improving performance and security.

Next, configure the health probe. This is the single most common cause of load balancer issues. If the health probe is misconfigured, the load balancer may mark all servers as unhealthy, resulting in no traffic being served, or it may fail to detect a failed server, causing errors. Always test the health endpoint on each server independently before configuring the probe. Use a simple, fast endpoint like /health that returns a 200 OK only if the server is fully healthy (database connected, temp directory writable, etc.). Avoid probing a complex page that could fail for non-critical reasons.

Another key decision is the load balancing algorithm. Round robin works well when all servers have equal capacity and requests take similar time. Least connections is better when request processing time varies widely. Weighted algorithms let you assign more traffic to larger servers. In cloud environments like Azure, you often use the default hash-based distribution that ensures even distribution across VMs.

Finally, plan for high availability of the load balancer itself. A single load balancer can be a single point of failure. Deploy a pair in active-passive mode with a virtual IP that floats between them. In Azure, this is handled automatically when you configure a standard SKU load balancer with availability zones. Always monitor the load balancer metrics (packet drop, health probe status, data path availability) to catch issues early.

Common mistakes in real environments include forgetting to update backend pools when scaling out, setting health probe timeouts too high, and not configuring the network security group (firewall) to allow health probe traffic from the load balancer's IP range. Professionals should also document the exact routing rules and algorithms used so that troubleshooting is faster during an incident.

## Commands

```
az network lb create --name MyLB --resource-group MyRG --sku Standard --public-ip-address MyPublicIP --frontend-ip-name MyFrontEnd --backend-pool-name MyBackendPool
```
Creates a Standard SKU Azure Load Balancer with a public frontend IP and a backend pool. Used for internet-facing load balancing.

*Exam note: AZ-104 tests your ability to specify --sku Standard vs Basic. Standard SKU is required for availability zones and HA Ports. Missing --sku defaults to Basic, which may fail advanced scenarios.*

```
az network lb probe create --lb-name MyLB --resource-group MyRG --name HTTPProbe --protocol Http --port 80 --path "/health" --interval 15 --threshold 2
```
Creates an HTTP health probe on port 80 with a 15-second interval and a threshold of 2 consecutive failures to mark unhealthy.

*Exam note: Network+ and AZ-104 ask about probe parameters: interval and threshold affect failover speed. Too short causes false positives; too long delays detection. The path /health must return 200.*

```
az network lb rule create --lb-name MyLB --resource-group MyRG --name HTTPRule --protocol Tcp --frontend-port 80 --backend-port 80 --frontend-ip-name MyFrontEnd --backend-pool-name MyBackendPool --probe-name HTTPProbe
```
Creates a load balancing rule mapping port 80 from the frontend to port 80 on the backend pool, using the HTTP probe defined earlier.

*Exam note: AZ-104 expects you to associate rules with probes. A common mistake is omitting --probe-name, which causes all backends to be considered healthy. Also, frontend-port and backend-port can differ.*

```
az network lb rule create --lb-name MyLB --resource-group MyRG --name AllPortsRule --protocol All --frontend-port 0 --backend-port 0 --frontend-ip-name MyFrontEnd --backend-pool-name MyBackendPool
```
Creates a High Availability Ports rule by setting --protocol All and --frontend-port 0. This distributes traffic on all ports.

*Exam note: This is a defining command for HA Ports in AZ-104. You must remember that protocol All is only available with Standard SKU. Setting --frontend-port 0 is the key syntax. This appears in scenario questions about network virtual appliances.*

```
az network lb inbound-nat-rule create --lb-name MyLB --resource-group MyRG --name RDPAccess --protocol Tcp --frontend-port 3389 --backend-port 3389 --frontend-ip-name MyFrontEnd --enable-floating-ip false
```
Creates an inbound NAT rule for RDP access to a single backend VM, using port mapping. This is for direct management access, not for load balancing.

*Exam note: Inbound NAT rules are often confused with load balancing rules. The exam tests that NAT rules target a specific VM (by default, the first in the pool) while LB rules distribute. Floating IP (enable-floating-ip) is used for Direct Server Return scenarios.*

```
sudo apt-get install nginx -y && sudo systemctl start nginx
```
Installs and starts an Nginx web server on a Linux backend VM, which can serve as the health probe endpoint or application.

*Exam note: Not a load balancer command but essential for labs. Network+ and Security+ practical exams may ask you to prepare backend servers for health probes. Knowing that Nginx listens on port 80 is fundamental.*

```
az network lb rule update --lb-name MyLB --resource-group MyRG --name HTTPRule --set "loadDistribution=SourceIP"
```
Updates an existing load balancing rule to use session persistence based on source IP.

*Exam note: AZ-104 tests loadDistribution options: Default, SourceIP, SourceIPProtocol. The command uses --set with JSON syntax. Session persistence is a common exam scenario for stateful applications.*

```
Get-NetIpHttpProbe | Where-Object {$_.ProbeNumber -eq 1} | Format-List
```
Windows PowerShell command to view health probe configuration on a Windows Server backend running IIS. Used for local verification.

*Exam note: Network+ may include Windows-based scenarios. Knowing how to check probe settings locally helps troubleshooting. The probe is configured by the load balancer, so local commands verify the backend is responsive.*

## Troubleshooting clues

- **Backend VMs Show as Unhealthy in Load Balancer** — symptom: The load balancer portal or CLI shows all backend VMs with 'Unhealthy' status, even though they appear running.. This happens when the health probe fails. Common causes: the probe endpoint doesn't exist (e.g., path /health returns 404), the port is blocked by a firewall or NSG, or the probe interval is too short causing timeouts. The load balancer probe source IP (168.63.129.16 for Azure) must be allowed. (Exam clue: AZ-104 and Network+ both ask: 'Why are all VMs unhealthy after adding a load balancer?' The answer is almost always an NSG blocking probe traffic or missing the /health endpoint.)
- **Session Persistence Not Working (Users Lose Session Data)** — symptom: Users report being randomly logged out or losing shopping cart items during a session.. The load balancer is likely using round robin (default) without session persistence. Requests from the same client go to different backends that don't share session state. The fix is to enable source IP persistence or move session state to a central store like Redis. (Exam clue: Security+ and AZ-104 test the difference between stateful and stateless architectures. A classic question: 'A web app loses user sessions when scaled. What is the best fix?' Answer: Implement a shared session store.)
- **One Backend VM Receives Most of the Traffic** — symptom: Monitoring shows one server is overloaded while others are idle.. With source IP persistence, clients behind the same NAT or proxy share the same IP, causing the hash to always point to one server. Alternatively, weighted distribution may be misconfigured with too high a weight on one server. Also, the health probe might be too aggressive, marking other servers as unhealthy. (Exam clue: Network+ exams present a scenario: 'A corporate network with 100 users behind a single public IP. Load balancer uses source IP affinity. What is the problem?' Answer: Uneven load distribution.)
- **Connection Timeouts to Load Balanced Application** — symptom: Users experience intermittent timeouts when connecting to the application.. Possible causes: The load balancer's idle timeout is too low (default 4 minutes). Long-lived connections like WebSockets or file uploads exceed this timeout and are dropped. Another cause: The backend server is slow, causing the health probe to fail, removing it temporarily. Also, firewall or NSG may be dropping packets after some period. (Exam clue: AZ-104 tests idle timeout settings. A common question: 'WebSocket connections disconnect after 4 minutes. How to fix?' Answer: Increase idle timeout or use a layer 7 load balancer that supports WebSocket passthrough.)
- **Outbound Connectivity Fails for Backend VMs Behind Load Balancer** — symptom: Backend VMs can't access the internet (e.g., cannot download updates).. Azure Load Balancer does not provide outbound connectivity by default unless configured with outbound rules or a NAT gateway. The backend VMs' source IP for outbound traffic becomes the load balancer's frontend IP only if outbound rules are set. Without it, VMs have no public IP and cannot reach the internet. (Exam clue: This is a classic AZ-104 question: 'After deploying internal load balanced VMs, they cannot connect to the internet.' Answer: Configure outbound rules on the load balancer or add a NAT gateway.)
- **HA Ports Rule Not Working** — symptom: Traffic to non-standard ports is dropped, even though HA Ports rule is configured.. HA Ports rule only distributes traffic; it does not automatically open firewall ports. The backend VM's firewall and the NSG must explicitly allow the traffic on those ports. Also, HA Ports require Standard SKU; using Basic SKU will cause rule creation failure. (Exam clue: AZ-104 question: 'You created an HA Ports rule but traffic on port 8080 is blocked. What is missing?' Answer: The NSG on the backend subnet does not allow port 8080.)
- **Floating IP (Direct Server Return) Not Working** — symptom: Backend servers cannot send traffic directly to the client; replies go through the load balancer instead.. Floating IP requires the backend server to listen on the load balancer's frontend IP address. The backend must have that IP assigned to a loopback interface or be able to respond to ARP requests for that IP. If the backend does not have the IP configured, traffic will be dropped. (Exam clue: Security+ and Network+: 'What is required for Direct Server Return to work?' Answer: The backend must have the load balancer's virtual IP configured on a loopback adapter.)

## Memory tip

Think of a restaurant host who seats you at the nearest empty table. The host is the load balancer, tables are servers. If a table is broken (server down) the host doesn't seat anyone there.

## FAQ

**Can a load balancer improve security?**

Yes, indirectly. By distributing traffic, it can help absorb DDoS attacks. Some load balancers also offer built-in web application firewall features and SSL termination, which centralizes certificate management.

**What happens if the load balancer itself fails?**

That is why production systems use a pair of load balancers in a high-availability configuration. The secondary load balancer takes over the virtual IP and continues distributing traffic with minimal interruption.

**Do I need a load balancer if I have only one server?**

A single server cannot benefit from load balancing because there is nowhere to distribute traffic. However, if you plan to add a second server for redundancy or scaling, a load balancer becomes necessary.

**What is the difference between round robin and least connections?**

Round robin sends requests to servers in a fixed sequence. Least connections sends requests to the server with the fewest active connections. Least connections is better when request processing time varies.

**Can a load balancer work with UDP traffic?**

Yes, Layer 4 load balancers can handle UDP traffic. They forward UDP datagrams based on IP and port but do not maintain connection state the same way as TCP.

**What is a health probe?**

A health probe is a test that the load balancer performs periodically to check whether a backend server is alive and able to handle requests. It can be a simple ping, a TCP port check, or an HTTP GET request.

**What is sticky session?**

Sticky session, also known as session persistence, ensures that a user's requests are always sent to the same backend server. This is useful for applications that store session data locally on the server.

**How do I choose between a hardware and software load balancer?**

Hardware load balancers are physical appliances with dedicated resources, good for high-traffic on-premises environments. Software load balancers are more flexible, easier to scale, and often cheaper. Most cloud deployments use software load balancers.

## Summary

A load balancer is a critical component in modern IT infrastructure that distributes incoming network traffic across multiple backend servers. It ensures that no single server becomes overloaded, which improves application performance, availability, and reliability. Load balancers can operate at Layer 4 (transport) or Layer 7 (application) of the OSI model and use various algorithms such as round robin and least connections to make forwarding decisions. They also perform health checks to automatically remove failed servers from the pool.

Understanding load balancers is essential for IT professionals and certification candidates. The Network+ exam tests the basic concepts and types. The Security+ exam focuses on availability and DDoS mitigation. The Azure AZ-104 exam requires hands-on configuration of Azure Load Balancer. Common mistakes include confusing load balancers with routers or switches, misconfiguring health probes, and overlooking security implications of sticky sessions.

For exam success, focus on knowing the algorithms, the difference between Layer 4 and Layer 7, the role of health probes, and how load balancers fit into high-availability and scaling architectures. Use the memory tip of the restaurant host seating guests at available tables to keep the concept simple. By mastering load balancing, you build a foundation for designing robust, scalable systems that keep users happy and systems running smoothly.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/load-balancer