# Elastic Load Balancing

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

## Quick definition

Elastic Load Balancing is a cloud service that spreads incoming internet traffic across several servers so no single server gets overloaded. It helps keep websites and applications running smoothly even when lots of people visit at once. If a server fails, the load balancer automatically sends traffic to healthy servers. This way, users always get a fast response and the application stays available.

## Simple meaning

Imagine you run a popular food truck that serves lunch to hundreds of customers every day. If you only had one person at the window taking orders, the line would grow long, customers would get frustrated, and some would leave without buying anything. Now imagine you have three people at the window, all taking orders at the same time. You also have a smart manager standing at the front who constantly watches how many customers are in each line. The manager spots that line one has 10 people waiting, while line two and three have only two each. So the manager politely asks new customers to join the shorter lines. This distribution makes everything faster and everyone happier.

Elastic Load Balancing (ELB) does exactly that for computer applications. Instead of customers, it handles requests from web browsers or mobile apps. Instead of food truck workers, it directs traffic to multiple servers (called an Auto Scaling group or a fleet of EC2 instances). The load balancer constantly checks which servers are healthy and which are overloaded and routes new requests to the ones that can handle them best. If a server crashes, the load balancer stops sending traffic to it automatically. If traffic suddenly spikes, the load balancer can also help launch new servers to handle the extra load (when integrated with Auto Scaling). Users never notice a problem because they always get a quick response.

This is especially important for businesses that have variable traffic like an online store during a flash sale or a video streaming site on premiere night. Without a load balancer, the website might slow down or crash completely. With ELB, the app stays fast, reliable, and available, even under heavy load.

## Technical definition

Elastic Load Balancing (ELB) is a fully managed AWS service that automatically distributes incoming application or network traffic across multiple targets in one or more Availability Zones. It operates at different layers of the OSI model depending on the type of load balancer chosen. AWS offers three main types: Application Load Balancer (ALB) for HTTP and HTTPS traffic at Layer 7, Network Load Balancer (NLB) for TCP, UDP, and TLS traffic at Layer 4, and Classic Load Balancer (CLB) which is the legacy option supporting both Layer 4 and Layer 7 but with fewer features.

An ALB routes traffic based on content type, URL path, host header, or query string, making it ideal for microservices and containerized applications. It supports path-based routing, host-based routing, and redirect actions. NLB operates at the connection level and can handle millions of requests per second with very low latency, making it suitable for extreme performance scenarios. CLB is simpler but is not recommended for new applications because it lacks advanced features like path routing or integration with AWS WAF.

ELB integrates tightly with other AWS services. It works with Auto Scaling groups to automatically register new EC2 instances as they launch and deregister them when they terminate. It can also route traffic to AWS Lambda functions via ALB, enabling serverless architectures. Health checks are a critical component the load balancer periodically sends pings or connection requests to each target and only routes traffic to those that respond successfully within a configurable interval and threshold. If a target fails health checks, it is marked unhealthy and removed from the pool until it recovers.

ELB provides high availability by distributing traffic across multiple Availability Zones. This means if an entire AWS data center goes down, the load balancer redirects traffic to healthy targets in another zone. AWS manages the infrastructure behind ELB, so users do not need to patch or scale the load balancer itself. Advanced capabilities include sticky sessions (session affinity), SSL/TLS termination, Cross-zone load balancing, and connection draining, which ensures in-flight requests complete before a target is removed. From a security perspective, ELB supports integration with AWS Certificate Manager for HTTPS certificates and AWS WAF for web application firewall rules.

## Real-life example

Think about a busy airport with multiple check-in counters. Passengers arrive at the airport, and they all need to check their bags and get a boarding pass. If there were only one check-in counter, everyone would crowd around it, the line would stretch to the entrance, and many would miss their flights. To solve this, the airport opens many counters and has a friendly staff member standing near the entrance. This person looks at how long each line is and guides new passengers to the shortest line. If one counter closes because the agent needs a break, the staff member stops sending people there and directs them elsewhere.

Now imagine the airport gets extra busy during a holiday. Management opens more counters, and the staff member adapts instantly, pointing passengers to the new counters as they open. Passengers never wait too long because the work is spread across many counters. This is exactly how Elastic Load Balancing works. The load balancer is like that staff member standing at the entrance of a website. It sees all the incoming visitors and directs them to the healthiest, least busy server. If one server starts to slow down or fails, the load balancer stops sending new visitors there. When the cloud automatically adds more servers (thanks to Auto Scaling), the load balancer instantly starts using them. The result is a smooth, fast, and reliable experience for every user, no matter how many people show up at once.

## Why it matters

In modern IT, applications must be highly available and resilient to failure. Elastic Load Balancing is fundamental to achieving this. Without it, traffic would go to a single server, which becomes a single point of failure. If that server crashes, the entire application goes offline. If traffic spikes, that one server gets overloaded and becomes slow for everyone. ELB solves both problems by distributing the load and monitoring health.

From a cost perspective, ELB helps optimize resources. Instead of over-provisioning servers to handle peak traffic, you can provision just enough for normal load and let Auto Scaling launch extra servers only when needed. The load balancer ensures all those servers are used efficiently, so you do not waste money on idle capacity.

For security, ELB provides a single entry point for your application, making it easier to enforce security policies. You can terminate SSL/TLS at the load balancer, reducing the encryption burden on backend servers. You can also integrate AWS WAF to block malicious traffic before it reaches your application. ELB can be placed in public subnets while keeping your application servers in private subnets, adding an extra layer of security.

Finally, ELB simplifies maintenance. You can perform rolling updates or blue/green deployments behind a load balancer. You can take servers out of service for patching without causing downtime because the load balancer automatically stops sending traffic to them. This is critical for production environments that need continuous availability.

## Why it matters in exams

Elastic Load Balancing appears heavily in both the AWS Certified Cloud Practitioner and AWS Certified SysOps Administrator Associate exams. For Cloud Practitioner (CLF-C02), you need to understand ELB at a high level what it does, the three types, and its role in high availability and fault tolerance. Questions are often conceptual, asking you to identify the service that distributes traffic or ensures application availability. You might see multiple-choice questions that contrast ELB with Auto Scaling or Route 53.

For the SysOps Administrator Associate (SOA-C02), ELB is a core compute objective. You must know how to configure and troubleshoot ALBs and NLBs in detail. Expect scenario-based questions where you have to choose the correct load balancer type based on requirements. For example, a question might describe an application that needs path-based routing to different microservices the correct answer is ALB. Another scenario might require ultra-low latency for a gaming application NLB is the right choice.

You also need to understand health check configurations, cross-zone load balancing, connection draining, and how to integrate with Auto Scaling groups. Troubleshooting questions might ask why a target is marked unhealthy even though the application seems fine. The answer often involves checking the health check path, response timeout, or security group rules. Sticky sessions and their impact on even load distribution are another common trap.

In the SysOps exam, you might get a question about configuring an ALB with HTTPS listeners and SSL certificates from AWS Certificate Manager. Or you may need to analyze a scenario where traffic is not reaching targets because of incorrect subnet associations or missing security group inbound rules. Knowing that ELB requires at least two subnets in different Availability Zones for high availability is a must. Overall, for SysOps, you must be comfortable with both the architectural theory and the hands-on configuration details.

## How it appears in exam questions

ELB questions come in several patterns. The first pattern is type selection. The question will describe an application with specific traffic requirements, such as needing to route traffic based on URL path, and ask which load balancer type to use. The answer is ALB because it supports path-based routing. Another variant asks for the best load balancer for handling TCP traffic with very low latency that is NLB.

A second pattern is troubleshooting unhealthy targets. The scenario describes an ALB that marks all targets as unhealthy. The candidate must check possible causes: incorrect health check path, security group not allowing traffic from the load balancer, or the target in a different AZ without cross-zone load balancing enabled. Often the correct solution is to update the health check path to a valid endpoint like /health.

A third pattern is architecture and high availability. The question might ask how many subnets are required for an internet-facing ALB across two AZs. The answer is at least two public subnets, one in each AZ. Another question might ask why an application fails when an AZ goes down the answer could be that the application is deployed only in one AZ.

A fourth pattern is integration with Auto Scaling. Questions ask what ensures that newly launched EC2 instances automatically receive traffic. The answer is a load balancer target group associated with an Auto Scaling group. Or you might be asked what happens if all targets are unhealthy the load balancer returns a 503 Service Unavailable error.

Sticky sessions and connection draining also appear. A question may describe users being directed to different servers between requests and losing session data. The solution is to enable sticky sessions on the target group. Another question might ask about connection draining and its purpose to allow in-flight requests to complete before a target is deregistered.

Finally, security group questions are common. A question might ask which security group rule must exist for an ALB to communicate with EC2 instances. The correct rule is an inbound rule allowing traffic from the load balancer’s security group on the application port.

## Example scenario

A company runs an e-commerce website that sells shoes. The website is hosted on three EC2 instances, all running the same application code. The company wants to ensure that if one instance crashes, customers can still browse and buy shoes without interruption. Also, during a holiday sale, traffic might suddenly triple. The company needs a solution that distributes visitors evenly and automatically handles failures and spikes.

An Elastic Load Balancer is set up. It sits in front of the three EC2 instances and has a public DNS name that customers type into their browsers, like shoes.example.com. When a customer visits the site, the load balancer receives the request and checks the health of each EC2 instance by sending a request to the /health endpoint every 30 seconds. All three instances are healthy, so the load balancer sends the request to the instance with the fewest active connections. The customer sees the shoe catalog quickly.

During the holiday sale, traffic jumps from 100 visitors per minute to 10,000. The Auto Scaling group detects the increased load and launches seven more EC2 instances. The load balancer automatically registers these new instances in its target group and starts sending them traffic. The website stays fast. Meanwhile, one of the original instances suffers a hardware issue and stops responding properly. The load balancer’s health check fails for that instance, and it marks it as unhealthy. The load balancer stops sending new requests to that instance, but the other nine instances continue serving customers. The problematic instance is terminated by Auto Scaling and replaced with a new one. Customers never experience any disruption.

This scenario shows the core value of Elastic Load Balancing: automatic traffic distribution, health monitoring, and seamless integration with scaling, all of which ensure high availability and reliability for the application.

## Common mistakes

- **Mistake:** Thinking that only one type of load balancer exists and it works for all workloads.
  - Why it is wrong: AWS provides three types ALB, NLB, and CLB. Each is designed for different use cases. Using the wrong type can lead to missing features or poor performance.
  - Fix: Learn the characteristics of each type. ALB for HTTP/HTTPS path routing, NLB for extreme performance and TCP/UDP, CLB for legacy apps. Choose based on requirements.
- **Mistake:** Creating an internet-facing load balancer but placing backend servers in public subnets with no security group restrictions.
  - Why it is wrong: This exposes backend servers directly to the internet, defeating the purpose of the load balancer and creating security risks.
  - Fix: Place backend servers in private subnets. The load balancer should be in public subnets, and security groups should only allow traffic from the load balancer's security group.
- **Mistake:** Not enabling cross-zone load balancing and then wondering why traffic is unevenly distributed.
  - Why it is wrong: Without cross-zone load balancing, each load balancer node only distributes traffic to targets within its own Availability Zone, which can cause imbalance.
  - Fix: Enable cross-zone load balancing on the load balancer, especially when you have an unequal number of targets across zones.
- **Mistake:** Setting a health check path that does not exist or returns a non-200 status code.
  - Why it is wrong: The load balancer marks the target as unhealthy, and traffic is not sent to it, even if the application is actually working.
  - Fix: Use a dedicated endpoint like /health that returns a 200 OK status when the application is healthy. Ensure the target application responds correctly to that path.
- **Mistake:** Expecting the load balancer to automatically re-register terminated instances.
  - Why it is wrong: The load balancer does not launch instances. It only registers instances that exist. Auto Scaling launches new instances, and the load balancer registers them only if properly configured.
  - Fix: Create an Auto Scaling group with a launch template and attach a target group to it. The Auto Scaling group will automatically register new instances with the target group.

## Exam trap

{"trap":"A scenario says an ALB returns a 503 error. Learners often think the ALB itself is broken or needs to be restarted.","why_learners_choose_it":"They see a 503 as a server error and assume the load balancer is failing or misconfigured.","how_to_avoid_it":"Remember that a 503 from a load balancer usually means all targets are unhealthy. The ALB is working correctly, but no backend is available. Check health checks, target group, and instance health first."}

## Commonly confused with

- **Elastic Load Balancing vs Auto Scaling:** Elastic Load Balancing distributes traffic among existing instances. Auto Scaling automatically launches or terminates instances based on demand. They work together but are separate services. ELB handles traffic distribution, Auto Scaling handles capacity. (Example: ELB is like a traffic cop directing cars to multiple toll booths, while Auto Scaling is the manager who decides whether to open or close toll booths based on how many cars are waiting.)
- **Elastic Load Balancing vs Amazon Route 53:** Route 53 is a DNS service that translates domain names to IP addresses and can route traffic globally using policies like latency-based or geolocation routing. ELB distributes traffic across targets within a single region. Route 53 can point to an ELB, but they operate at different layers. (Example: Route 53 is like a highway sign that tells drivers which exit to take for a city (region). ELB, once they reach the city, directs them to the correct street (server).)
- **Elastic Load Balancing vs Amazon CloudFront:** CloudFront is a content delivery network that caches content at edge locations near users to reduce latency. It can forward requests to an ELB for dynamic content, but CloudFront’s primary role is caching and accelerating static and dynamic content globally. (Example: CloudFront is like a library branch in your neighborhood where you can grab a popular book quickly, while ELB is the main library that directs you to the right shelf when you need a rare book.)

## Step-by-step breakdown

1. **User request arrives** — A user's browser sends an HTTP request to the load balancer's public DNS name, such as app.example.com. The request contains details like the URL path (e.g., /images or /api) and headers.
2. **Load balancer listener receives the request** — The listener is configured on a specific port (e.g., 80 for HTTP, 443 for HTTPS) and protocol. It checks the request against its rules. For ALB, it evaluates path patterns or host headers to decide which target group should handle the request.
3. **Load balancer selects a target** — The load balancer uses its routing algorithm (usually round robin or least outstanding requests) to pick a healthy target from the chosen target group. It only considers targets that have passed health checks recently.
4. **Load balancer forwards the request** — The load balancer forwards the request to the selected target, preserving headers and connection information. If SSL termination is enabled, it decrypts the request before forwarding it to the backend in plain HTTP or re-encrypts it.
5. **Target processes and responds** — The backend server (e.g., EC2 instance, Lambda, or container) processes the request (e.g., querying a database, generating a page) and sends back a response to the load balancer.
6. **Load balancer sends response to user** — The load balancer forwards the response back to the user's browser. If SSL termination is enabled, it encrypts the response before sending it to the user. The user sees the web page or data without knowing the backend infrastructure.
7. **Health check monitoring continues** — Even while handling traffic, the load balancer continuously sends health check requests to all targets. If a target fails health checks, it is removed from rotation and no new requests are sent to it until it becomes healthy again.

## Practical mini-lesson

When working with Elastic Load Balancing in a real production environment, there are several key considerations that go beyond theory. First, choose the correct listener configuration. For ALB, you typically set up an HTTPS listener on port 443 and optionally redirect HTTP traffic to HTTPS. You need to attach a valid SSL/TLS certificate from AWS Certificate Manager or import a third-party certificate. The ALB terminates SSL, meaning decryption happens at the load balancer, which offloads CPU work from your backend instances.

Target groups are where you define which resources receive traffic. Each target group has a protocol and port, and you can configure health check settings including the path, interval, timeout, and unhealthy threshold. A common best practice is to create a custom health check endpoint like /health that checks application dependencies (database connectivity, cache, etc.) so that the load balancer only routes traffic to truly healthy instances. The default health check is often just a TCP connection check, which may not reveal application-level issues.

Security groups are critical. The load balancer’s security group must allow inbound traffic from the internet on the listener port (e.g., 443). The backend instances’ security group must allow inbound traffic from the load balancer’s security group (not from 0.0.0.0/0) on the application port. This prevents direct internet access to instances and forces all traffic through the load balancer.

Cross-zone load balancing is enabled by default for ALB and NLB, but it’s worth verifying. Without it, traffic distribution may become uneven if you have different numbers of instances per Availability Zone. Connection draining (also called deregistration delay) allows in-flight requests to complete when an instance is deregistering. Set this value appropriately (e.g., 60 seconds) to avoid dropping active connections.

What can go wrong? Misconfigured security groups are the most common issue. Another is forgetting to attach a target group to an Auto Scaling group, which means new instances will not be registered. Health checks with long intervals or high thresholds can delay failover. Also, if you use multiple target groups, ensure listener rules are correctly ordered and match the intended paths. Finally, monitor CloudWatch metrics like HealthyHostCount, UnhealthyHostCount, and TargetResponseTime to proactively detect issues.

## Memory tip

Think ELB = Even Load Balancer. It keeps traffic Even, prevents crashes, and ensures the app stays up.

## FAQ

**Does Elastic Load Balancing automatically scale itself?**

Yes, ELB is a fully managed service that automatically scales to handle changes in traffic. You do not need to provision or manage the load balancer’s capacity.

**Can I use a single load balancer for both HTTP and HTTPS traffic?**

Yes, you can add multiple listeners to a single load balancer, for example one for HTTP on port 80 and another for HTTPS on port 443.

**What happens if all my backend instances are unhealthy?**

If all targets are unhealthy, the ALB returns a 503 Service Unavailable error to clients. You need to investigate why the instances are failing health checks.

**Can I use a load balancer with on-premises servers?**

Yes, you can register on-premises servers as targets using IP addresses, but they must be reachable from the VPC, typically via VPN or Direct Connect.

**Does ELB support sticky sessions?**

Yes, ALB and CLB support sticky sessions (session affinity) using a cookie. This ensures a user’s requests are always sent to the same target during a session.

**What is the difference between internet-facing and internal load balancers?**

An internet-facing load balancer has a public DNS name and can receive traffic from the internet. An internal load balancer has a private IP and only routes traffic within the VPC.

## Summary

Elastic Load Balancing is a cornerstone of AWS cloud architecture, ensuring that applications remain highly available, scalable, and fault-tolerant. It automatically distributes incoming traffic across multiple targets, monitors their health, and integrates with Auto Scaling to handle varying loads. Whether you are studying for the AWS Cloud Practitioner or SysOps Administrator exam, understanding ELB is essential. For the Cloud Practitioner exam, focus on the high-level benefits and the three types of load balancers. For the SysOps exam, dig deeper into configuration details, health checks, security groups, and troubleshooting.

Common pitfalls include confusing ELB with other services like Route 53 or Auto Scaling, misconfiguring security groups, and neglecting health check settings. The most important exam trap is the 503 error, which always points to unhealthy targets, not a broken load balancer. By mastering ELB, you will be well prepared for questions on high availability, scaling, and resilient architecture. In practice, ELB is a daily tool for cloud professionals, enabling zero-downtime deployments and smooth traffic management. Keep the simple food truck or airport analogy in mind to anchor your understanding, and remember that ELB is the traffic cop that keeps your application running smoothly.

---

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