# HTTP(S) Load Balancer

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

## Quick definition

An HTTP(S) load balancer acts like a smart traffic cop for web traffic. It sits in front of your web servers and decides which server gets each visitor's request. It helps websites handle many visitors at once and stays up even if one server fails.

## Simple meaning

Imagine you are running a busy coffee shop with three baristas. When customers line up, you need a system to decide which barista serves each customer. Without a plan, one barista might be overwhelmed while the other two are idle. An HTTP(S) load balancer does this same job for websites and web applications. It sits between the internet and a group of web servers, called a server pool. When a person visits a website, the load balancer receives the request and forwards it to one of the servers, choosing the one that is least busy or healthiest. The load balancer also checks if servers are working properly. If a server crashes or becomes slow, the load balancer stops sending traffic to it, ensuring no visitors see an error page. For HTTPS traffic, the load balancer can also handle the encryption and decryption, taking that heavy work off the servers. This makes the whole system faster and more secure. Think of it like a receptionist in a busy office who answers all phone calls, decides which department the caller needs, and then directs the call. The receptionist keeps everyone from getting flooded with calls and makes sure no one is left waiting. That is exactly what an HTTP(S) load balancer does for web traffic.

In plain English, an HTTP(S) load balancer makes websites faster, more reliable, and easier to scale. Without it, a popular website could crash under heavy traffic. With it, even millions of visitors can be handled smoothly. It is a critical tool for any website that expects many users, such as online stores, streaming services, or social media platforms.

## Technical definition

An HTTP(S) load balancer is a type of application load balancer that operates at Layer 7 (the application layer) of the OSI model. Unlike basic load balancers that only look at IP addresses and ports, a Layer 7 load balancer can inspect the contents of HTTP or HTTPS requests. This means it can make routing decisions based on URL paths, HTTP headers, cookies, query parameters, and other application-level data. HTTP(S) load balancers use protocols such as HTTP/1.1, HTTP/2, and increasingly HTTP/3 (QUIC). They can also terminate TLS/SSL connections, decrypting incoming HTTPS traffic and then forwarding it as plain HTTP to backend servers, a process called SSL offloading. This reduces the CPU load on backend servers, which can then focus on serving content.

Load balancing algorithms determine how traffic is distributed. Common algorithms include round robin, least connections, least response time, IP hash, and weighted round robin. Round robin cycles through servers in order, while least connections sends new requests to the server handling the fewest active connections. Least response time sends traffic to the server with the fastest average response time. IP hash uses the client's IP address to consistently send the same client to the same server, which is useful for session persistence. Health checks are essential for reliability. The load balancer periodically sends requests to each server, such as a simple HTTP GET to a specific health check endpoint like /health. If a server fails to respond correctly within a timeout period, the load balancer marks it as unhealthy and stops sending traffic to it until it recovers.

In cloud environments like AWS, the Elastic Load Balancer (ELB) offers Application Load Balancers (ALB) for HTTP(S) traffic. In Google Cloud, the HTTP(S) Load Balancing service is global and supports cross-regional routing. In on-premises environments, popular software load balancers include HAProxy and Nginx, while hardware options include F5 BIG-IP and Citrix ADC. Configuration involves setting up listeners (ports and protocols), defining target groups (server pools), configuring health checks, and setting routing rules. For example, a listener on port 443 for HTTPS might route requests to different target groups depending on the URL path, such as /api/* going to API servers and /* going to web servers. Advanced features include sticky sessions (session affinity), which use cookies to ensure a user's requests are sent to the same server for the duration of their session. Another feature is content-based routing, where requests are distributed based on the content of the request, such as directing mobile users to a different server pool. Rate limiting can also be configured to protect against traffic spikes or denial-of-service attacks.

## Real-life example

Think of a busy hospital emergency room. Patients arrive at all hours with different needs. At the front desk, there is a triage nurse. This nurse does not treat patients directly but decides which doctor or unit can best help each patient. The triage nurse looks at the patient's symptoms, check their ID, and ask a few quick questions. Based on that information, the nurse sends chest pain patients to the cardiology team, broken bones to orthopedics, and minor cuts to the urgent care team. If one doctor is already overloaded, the nurse sends the next patient to a different doctor. The nurse also checks regularly to see if a doctor is still available-if a doctor steps out, the nurse stops sending new patients to that doctor.

Now map this to an HTTP(S) load balancer. The patients are web requests from visitors. The triage nurse is the load balancer. The doctors are your web servers. The symptoms and ID are the HTTP headers and cookies. The triage nurse's quick questions are the load balancer's health checks. The decision to send chest pain to cardiology is like routing based on URL path (/checkout to one server pool, /images to another). If one doctor gets overwhelmed, the nurse sends the next patient elsewhere-that is load distribution. And when a doctor steps out, the nurse knows not to send more patients-that is a health check failing and stopping traffic. The emergency room can handle many more patients with a good triage nurse than without one, just like a website can handle more visitors with a load balancer. Without the nurse, every patient would crowd the first doctor they see, causing chaos. Without a load balancer, web traffic would overwhelm a single server, causing crashes and slow load times.

## Why it matters

In the real world of IT, HTTP(S) load balancers are not optional for any application that expects more than a handful of users. They directly impact user experience, system reliability, and operational cost. For example, an e-commerce site during Black Friday can see traffic surges of 100x normal volume. Without a load balancer, the single server handling that traffic would quickly become overloaded, causing timeouts or crash. Visitors would see error pages, abandon their carts, and the company would lose revenue. With a load balancer, you can add new servers on the fly to handle the load, and the load balancer automatically distributes traffic among them. This is called horizontal scaling, and it is essential for modern cloud architectures.

Load balancers also improve security. They can hide the internal structure of your network from the internet. External users only see the load balancer's IP address, not the individual servers. This reduces the attack surface. Many load balancers can also perform SSL termination, decrypting traffic at the edge, which offloads the compute-heavy encryption work from the backend servers. They can integrate with Web Application Firewalls (WAF) to block malicious traffic before it reaches your servers. High availability is another critical advantage. If a server fails, the load balancer detects it through health checks and routes traffic to healthy servers. This can happen automatically in seconds, often without any visible outage to users. For compliance reasons, such as PCI DSS, load balancers help ensure that sensitive data is encrypted during transit and that session management is secure. In short, an HTTP(S) load balancer is essential for building scalable, secure, and resilient web applications.

## Why it matters in exams

HTTP(S) load balancers are a core topic in several major IT certification exams. For the AWS Certified Solutions Architect Associate exam, the Application Load Balancer (ALB) and Network Load Balancer (NLB) are frequently tested. You must understand when to use each type, how to configure listeners and target groups, and how to implement path-based routing. Scenario questions often ask you to design a high-availability architecture where an ALB distributes traffic across multiple Availability Zones. The AWS Certified Developer Associate exam also tests ALB integration with auto scaling groups and how to enable sticky sessions using cookies.

For the Google Cloud Associate Cloud Engineer and Professional Cloud Architect exams, HTTP(S) Load Balancing is a key service. You need to know the difference between global and regional load balancing, how to configure backend services and health checks, and how to use URL maps for content-based routing. The exam objective explicitly lists 'Configuring HTTP(S) load balancing' as a tested skill.

For the CompTIA Cloud+ exam, load balancing is covered in domain 2 about cloud operations. You need to understand load balancing algorithms (round robin, least connections) and concepts like affinity and persistence. Questions may ask you to choose the best load balancing method for a specific workload.

For the Cisco CCNA exam, load balancing is often discussed in the context of server load balancing and high availability. While not as deep as cloud-specific exams, you should understand basic concepts and how load balancers fit into a network topology.

For the Microsoft Azure Administrator (AZ-104) exam, Azure Load Balancer and Application Gateway are covered. You need to know the differences between Layer 4 and Layer 7 load balancing and when to use Application Gateway for HTTP(S) traffic. In all these exams, you will see multiple-choice questions asking you to identify the correct configuration for a given scenario, such as which load balancer supports cookie-based session persistence or which algorithm is best for long-lived connections.

## How it appears in exam questions

Exam questions about HTTP(S) load balancers typically fall into three categories: scenario-based design, configuration choices, and troubleshooting. In scenario-based design, you are given a business requirement and asked to select the correct load balancer type and settings. For example, 'A company runs a web application that uses sticky sessions. Which load balancer feature ensures a user's requests are sent to the same backend server?' The answer would be session affinity using a cookie. Another common question: 'You have a web application with two microservices: one for /api and one for /web. How can a single load balancer route requests to the correct service?' The expected answer is path-based routing.

Configuration questions often provide a partial configuration and ask for the missing parameter. For instance, 'An admin configures an ALB with a target group running on port 80. Health checks fail. What is the most likely cause?' The answer might be that the health check path is incorrect or the security group is blocking traffic. In AWS, security groups must allow health check traffic from the load balancer's subnet. Another configuration question: 'A load balancer is set to round robin, but one server is slower than others. What algorithm should be used instead?' The correct answer is least response time.

Troubleshooting questions present a symptom, such as users receiving 503 errors during peak hours. The cause could be that the load balancer's target group has reached its capacity, or the auto scaling group has not launched enough instances. Another troubleshooting scenario: 'After enabling SSL termination on the load balancer, backend servers start receiving plain HTTP traffic. Users report seeing mixed content warnings. What is the fix?' The advice would be to configure the backend application to use HTTPS or to have the load balancer set the X-Forwarded-Proto header. You might also see questions about session persistence where users are unexpectedly logged out because sticky sessions are not configured. The pattern is always to connect the symptom to the load balancer's configuration or lack thereof.

## Example scenario

You are the IT administrator for a growing online bookstore. The website currently runs on a single web server that hosts both the frontend and backend application. Lately, customers have complained about slow page loads during lunch hours and occasional 'Service Unavailable' errors. Your manager asks you to fix this so the website can handle more visitors and avoid downtime.

You decide to implement an HTTP(S) load balancer. You set up three identical web servers, each running the same bookstore application. You then configure an HTTP load balancer to distribute incoming traffic among them. You choose the least connections algorithm because the length of requests varies (some users browse, some check out). You also configure health checks to ping a /health endpoint every 30 seconds. If a server fails the health check twice, it is automatically removed from the pool.

After deploying the load balancer, you test it. When you visit the bookstore's URL, the load balancer sends your request to one of the three servers. You add a book to your cart and proceed to checkout. If sticky sessions were not configured, the checkout request could go to a different server, and your cart information might be lost. So you enable sticky sessions using a cookie. Now, all requests from your browser go to the same server for the duration of your session.

Next, you plan for Black Friday traffic. You configure the load balancer to work with an auto scaling group that automatically adds more servers when CPU usage exceeds 70%. The load balancer automatically starts sending traffic to the new servers. When traffic decreases, servers are terminated, and the load balancer stops sending them traffic. The result is a highly available, scalable bookstore that can handle thousands of simultaneous users without crashing.

## Common mistakes

- **Mistake:** Confusing layer 4 and layer 7 load balancers.
  - Why it is wrong: Layer 4 load balancers route traffic based on IP and port, and cannot inspect HTTP headers or URLs. Using a layer 4 balancer for HTTP traffic means you lose the ability to perform path-based routing or sticky sessions based on cookies.
  - Fix: Remember that HTTP(S) load balancers are layer 7. If your application needs to route based on URL or maintain session persistence, choose a layer 7 HTTP(S) load balancer.
- **Mistake:** Disabling stickiness (session affinity) when the application stores session data locally on each server.
  - Why it is wrong: Without stickiness, a user's requests may be sent to different servers. If session data is stored in local server memory, the user will lose their session, get logged out, or see an inconsistent experience.
  - Fix: Either enable sticky sessions on the load balancer or store session data in a centralized external store like Redis or a database.
- **Mistake:** Incorrectly setting the health check path or making it too simple.
  - Why it is wrong: If the health check endpoint only checks web server software but not the full application stack, the load balancer may keep sending traffic to a server whose database connection is broken. The server appears healthy but serves error pages.
  - Fix: Set the health check to a dedicated endpoint that tests critical dependencies, including database connectivity and external APIs.
- **Mistake:** Using round robin for connections with vastly different processing times.
  - Why it is wrong: Round robin sends each new request to the next server in line, regardless of current load. If some requests take longer (e.g., file uploads), one server can become overloaded while others are idle.
  - Fix: Use least connections or least response time algorithm instead, which sends new requests to the server with the fewest active connections.
- **Mistake:** Forgetting to update security group rules to allow health check traffic.
  - Why it is wrong: Load balancer health checks come from specific IP addresses (often the load balancer subnet). If the backend server's firewall blocks these IPs, health checks fail, and the server is marked unhealthy, causing traffic to be directed away.
  - Fix: Explicitly allow inbound traffic from the load balancer's source IP range or security group on the health check port.

## Exam trap

{"trap":"A question describes a scenario where a load balancer uses round robin and suddenly one server fails. The learner is asked what happens to the traffic that was being sent to that server.","why_learners_choose_it":"Learners mistakenly think that the traffic currently in flight to the failed server will be lost or cause errors. They choose an answer like 'The connection is dropped and the user gets a timeout.'","how_to_avoid_it":"In most modern load balancers (including AWS ALB), when a server becomes unhealthy, the load balancer stops sending new requests to it. However, existing in-flight connections are typically handled at the application level. The load balancer does not actively kill open connections. But for HTTP/1.1, if a request is in the middle of being processed, the user may experience a timeout if the server fails. The correct exam answer often depends on the specific load balancer technology. In general, assume that new traffic stops, and existing connections may be terminated if the server fails completely. Always read the question carefully to see if it mentions 'new requests' or 'existing connections.'"}

## Commonly confused with

- **HTTP(S) Load Balancer vs Network Load Balancer (NLB):** A Network Load Balancer operates at Layer 4 and routes traffic based on TCP/UDP protocols and IP addresses. It cannot inspect HTTP headers or perform content-based routing. HTTP(S) load balancers operate at Layer 7 and understand HTTP requests, enabling features like path-based routing and cookie-based session persistence. (Example: Use an NLB for a gaming server that uses UDP. Use an HTTP(S) load balancer for a website that needs to direct /api calls to one group of servers and /login to another.)
- **HTTP(S) Load Balancer vs Reverse Proxy:** A reverse proxy is a server that sits in front of web servers and forwards client requests. While an HTTP(S) load balancer is a type of reverse proxy, not all reverse proxies perform load balancing. A reverse proxy can also cache content, compress responses, or perform SSL termination without distributing traffic across multiple servers. (Example: Nginx configured as a single reverse proxy for a single backend server is not a load balancer. Nginx configured with the 'upstream' module pointing to multiple backends becomes a load balancer.)
- **HTTP(S) Load Balancer vs AWS Classic Load Balancer:** The Classic Load Balancer is an older AWS service that operates at both Layer 4 and Layer 7 but lacks advanced HTTP features like path-based routing, host-based routing, and redirect support. The modern Application Load Balancer (HTTP(S) load balancer) provides much richer HTTP routing capabilities. (Example: If you need to route traffic based on the URL path (e.g., /api vs /images), you must use an ALB, not a Classic Load Balancer.)
- **HTTP(S) Load Balancer vs Content Delivery Network (CDN):** A CDN like CloudFront or Akamai caches static content at edge locations close to users. It reduces latency by serving cached assets without hitting the origin server. An HTTP(S) load balancer distributes traffic across multiple origin servers but does not cache content. They are often used together: a CDN in front of a load balancer. (Example: For a website, use a CDN to serve images and videos quickly globally. Use an HTTP load balancer to distribute requests among backend servers for dynamic content like checkout.)

## Step-by-step breakdown

1. **Client sends an HTTP/HTTPS request** — A user enters a URL in their browser. The browser resolves the domain name to the load balancer's IP address (via DNS). The HTTP or HTTPS request is sent to the load balancer's listener (port 80 or 443).
2. **Load balancer terminates TLS (if HTTPS)** — If the listener is configured for HTTPS, the load balancer handles the TLS handshake, decrypts the request, and can inspect the plain HTTP content. This offloads the compute-heavy encryption work from backend servers. The load balancer may forward the request as HTTP to the backend, but can add headers like X-Forwarded-Proto to inform the backend that the original request was HTTPS.
3. **Load balancer selects a backend server using the configured algorithm** — Based on the algorithm (e.g., least connections, round robin), the load balancer chooses a healthy server from the target group. If routing rules are defined, the choice may also depend on the URL path, host header, or query string. For example, /images might go to a server group optimized for static content.
4. **Load balancer forwards the request to the chosen server** — The load balancer opens a new connection to the backend server (or uses a keep-alive connection) and forwards the original request, along with additional headers that carry client information (like the original IP via X-Forwarded-For).
5. **Backend server processes the request and sends a response** — The web application on the backend server processes the request (e.g., querying a database, generating HTML) and sends an HTTP response back to the load balancer. The load balancer may also process the response, for instance by compressing it or adding headers.
6. **Load balancer forwards the response to the client** — The load balancer sends the backend's response back to the original client. If the health check is performed in the background, the load balancer continues to monitor all backend servers periodically. If a server fails health checks, it is removed from the pool until it recovers.

## Practical mini-lesson

In practice, configuring an HTTP(S) load balancer requires careful planning beyond just turning it on. First, you must decide on the type of load balancer. In AWS, you choose between Application Load Balancer (ALB) and Network Load Balancer (NLB). For HTTP traffic, ALB is almost always the right choice because it offers layer 7 features. For example, you might configure two listeners: one on port 80 that redirects all traffic to HTTPS, and one on port 443 that terminates TLS. This ensures all traffic is encrypted.

Next, you define target groups. Each target group is a pool of backend servers that handle a specific type of request. For a microservices architecture, you might have a target group for web frontends and another for API servers. Then you create rules on the listener. A rule might listen for requests with a path prefix of /api/* and forward them to the API target group, while forwarding everything else to the web target group. This is called path-based routing.

Health checks are critical. A best practice is to create a dedicated health check endpoint, such as /health, which returns a 200 OK only if the application is fully functional, including database connections. The health check interval should be set low enough to detect failures quickly but high enough to avoid unnecessary load. For example, every 10 seconds with a timeout of 5 seconds and a healthy threshold of 2 consecutive successes.

SSL/TLS configuration is another key step. You must upload or reference a certificate (e.g., from AWS Certificate Manager). You also need to decide whether to use a single certificate for multiple domains (using SAN) or separate listeners. Security groups must be configured to allow inbound traffic from the load balancer to the backend servers on the application port (e.g., port 80). Also, allow internet traffic to the load balancer on ports 80 and 443.

What can go wrong? A common issue is a misconfigured security group that blocks health checks. Another is that the health check path returns a 200 even when the application is broken, because the health check only checks the web server, not the full stack. Performance issues arise when the load balancer's connection timeout is too short, causing premature closure of slow requests. For long-lived WebSocket connections, ensure the load balancer supports them (ALB does). Finally, scaling: you should integrate the load balancer with an auto scaling group so that new servers are automatically registered when traffic increases. Professionals use metrics like request count per target and target response time to fine-tune scaling policies.

## Memory tip

Layer 7 sees the URL, Layer 4 only sees the port. Think: HTTP load balancers are smart at the application level.

## FAQ

**Can one HTTP load balancer handle multiple domains?**

Yes, a single HTTP(S) load balancer can serve multiple domains by using host-based routing rules. You configure rules that look at the Host header in the request and forward traffic to the appropriate target group for each domain.

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

Round robin sends each new request to the next server in a repeating sequence, regardless of the current load on each server. Least connections sends new requests to the server with fewest active connections, which is better for workloads with varying request processing times.

**Does an HTTP load balancer encrypt traffic between itself and backend servers?**

Not by default. After terminating HTTPS at the load balancer, traffic between the load balancer and backend servers is typically plain HTTP. If you need end-to-end encryption, you can configure the load balancer to use HTTPS to the backend as well, known as 'back-end encryption' or 're-encryption'.

**What happens if all backend servers fail health checks?**

If all servers are unhealthy, the load balancer may have a 'fail-open' or 'fail-close' behavior depending on configuration. In many cases, the load balancer returns a 503 Service Unavailable error to the client. Some configurations allow a 'last server standing' mode where traffic is still sent to the last known healthy server, even if it fails health checks.

**What is sticky session and when should I use it?**

Sticky session, also called session affinity, ensures that all requests from a particular user are sent to the same backend server. Use it when your application stores session data locally on the server. If you use a centralized session store like Redis or database, you can disable sticky sessions for better load distribution.

**Can an HTTP load balancer help with DDoS attacks?**

Partially. Some load balancers offer rate limiting and can absorb small to medium attacks by distributing traffic. However, for large DDoS attacks, you typically need a more specialized service like AWS Shield or Cloudflare. The load balancer itself can be overwhelmed if targeted directly.

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

No, a load balancer is only useful when you have multiple servers. With a single server, the load balancer adds complexity and a single point of failure. It is better to use a reverse proxy or CDN for performance and security improvements on a single server.

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

Hardware load balancers (like F5) offer dedicated performance and advanced features but are expensive and less flexible. Software load balancers (like HAProxy or Nginx) run on commodity hardware or in the cloud, are more cost-effective, and offer easier scaling. In cloud environments, managed services like AWS ALB are the simplest option.

## Summary

An HTTP(S) load balancer is a critical component for any web application that needs to handle traffic reliably and scale efficiently. It operates at Layer 7 of the OSI model, allowing it to make intelligent routing decisions based on the content of HTTP requests, such as URL paths, headers, and cookies. This capability enables advanced features like path-based routing, host-based routing, sticky sessions, and SSL offloading. By distributing traffic across multiple backend servers, a load balancer ensures high availability and fault tolerance: if one server fails, traffic is automatically redirected to healthy ones. It also provides a layer of security by hiding internal server IP addresses and enabling SSL termination at the edge.

In exam contexts, HTTP(S) load balancers are a staple topic for cloud certifications like AWS Solutions Architect, Google Cloud Architect, and Azure Administrator. Questions frequently test your understanding of when to use Layer 7 vs Layer 4 load balancers, how to configure health checks, which algorithm to apply in different scenarios, and how to integrate load balancers with auto scaling groups. Common pitfalls include confusing load balancer types, misconfiguring health checks, and neglecting session persistence when the application requires it. The takeaway for exam preparation is to focus on the specific capabilities of the load balancer service in the cloud platform you are studying, and practice mapping business requirements to the correct configuration. In real-world IT, mastering HTTP(S) load balancers is essential for building resilient, high-performance web architectures that can grow with user demand.

---

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