What Does Elastic Load Balancer Mean?
On This Page
Quick Definition
An Elastic Load Balancer acts as a single point of contact for users and spreads incoming traffic across multiple servers. This helps keep applications available and responsive even if one server fails or gets too busy. It also performs health checks to make sure traffic is only sent to healthy servers.
Commonly Confused With
Route 53 is a DNS service that directs users to the closest or healthiest endpoint, but it does not actually distribute traffic at the application level. An ELB actively manages and distributes each request across targets, while Route 53 simply resolves a domain name to an IP address.
Route 53 is like a directory that tells you which store to go to, while an ELB is like the employee at the store door who directs you to the shortest checkout line.
Auto Scaling automatically adds or removes EC2 instances based on demand, but it does not distribute incoming traffic. The ELB works with Auto Scaling to send traffic to the instances that Auto Scaling launches. They are complementary services, not alternatives.
Auto Scaling is like a manager who hires more staff when the store gets busy. The ELB is the floor manager who tells each customer which staff member to see.
Global Accelerator uses static IP addresses and the AWS global network to route traffic to the closest healthy endpoint, improving performance for global users. An ELB distributes traffic within a single region. Global Accelerator can be placed in front of an ELB to provide both global performance and regional load balancing.
Global Accelerator is like a highway system that gets you to the right city, while the ELB is like the local traffic system that directs you to the correct building within that city.
Must Know for Exams
For the AWS Certified Solutions Architect – Associate (SAA-C03) exam, Elastic Load Balancers are a core compute and networking concept. The exam explicitly tests your knowledge of when to use each type of load balancer, how to configure listeners and target groups, and how ELB integrates with Auto Scaling, Route 53, and security groups. You can expect questions that present a scenario and ask you to select the most appropriate load balancer type.
For example, a scenario describing a web application that needs to route requests based on URL path would point to an Application Load Balancer, while a scenario requiring static IP addresses for whitelisting by a partner would point to a Network Load Balancer. The exam also tests your understanding of health checks, cross-zone load balancing, session stickiness, and connection draining. Another common question type is around securing the ELB.
You might be asked how to encrypt traffic between the client and the load balancer, and between the load balancer and the backend instances. The correct answer often involves using an HTTPS listener with an SSL certificate on the ALB, and then placing the backend instances in a private subnet that only accepts traffic from the load balancer's security group. The SAA exam also expects you to know that ALB can authenticate users using Amazon Cognito or corporate identities via OIDC, which is a newer objective.
For the AWS Certified Developer – Associate (DVA-C02) exam, you need to understand how ELB interacts with Lambda functions as targets, and how to use ALB path-based routing to serve multiple microservices from a single load balancer. The AWS Certified SysOps Administrator – Associate (SOA-C02) exam goes deeper into operational aspects, such as configuring access logs, monitoring with CloudWatch metrics, troubleshooting slow connections, and understanding how ELB handles IP addresses. In all exams, a common trap is that learners forget that an ALB can also handle HTTP/2 and WebSocket traffic, or that an NLB can preserve the client source IP, which is vital for applications that need to log or filter by client IP.
The breadth and depth of ELB concepts make it a high-yield topic, with at least 3 to 5 questions appearing on most exams.
Simple Meaning
Imagine you run a busy coffee shop. During the morning rush, customers line up at the counter. If you have only one barista, the line gets long and people get frustrated. Now imagine you have three baristas.
You need someone to direct each customer to the shortest line so everyone is served quickly and fairly. That person is like a load balancer. In the world of websites and apps, an Elastic Load Balancer does exactly that.
It sits in front of your web servers, or any other resources, and decides which server should handle each incoming request. It is called elastic because it can automatically grow or shrink to handle changes in traffic, just like a coffee shop that can add more baristas when a big crowd shows up. The load balancer also checks if a server is healthy.
If a barista spills a drink or runs out of coffee, the load balancer stops sending customers to that station until the problem is fixed. This keeps the overall service running smoothly. In AWS, an Elastic Load Balancer is a managed service, meaning you do not have to install or maintain the hardware or software yourself.
You simply configure it to listen on a specific port, like port 80 for web traffic, and define which servers should receive traffic. The load balancer then handles the rest, including encrypting traffic if you use HTTPS, and spreading requests across different physical locations to improve reliability. Because it distributes work, no single server gets overwhelmed.
This protects your application from crashing due to a sudden spike in visitors and ensures users get a fast, consistent experience.
Full Technical Definition
An Elastic Load Balancer (ELB) is a fully managed AWS service that automatically distributes incoming traffic across multiple targets within one or more Availability Zones. AWS offers three types of load balancers: Application Load Balancer (ALB), Network Load Balancer (NLB), and Gateway Load Balancer (GWLB). The ALB operates at Layer 7 of the OSI model and is ideal for HTTP and HTTPS traffic.
It supports content-based routing, meaning it can direct requests based on URL paths, host headers, query strings, or HTTP methods. This allows you to send API requests to one group of servers and image requests to another, all through the same load balancer. The NLB operates at Layer 4 and handles TCP, UDP, and TLS traffic.
It is designed for extreme performance and low latency, capable of handling millions of requests per second while preserving the source IP address of the client. The GWLB is used for deploying, scaling, and managing third-party virtual appliances, such as firewalls and intrusion detection systems, by acting as a single entry and exit point for traffic. All ELBs use listeners to define the port and protocol on which they accept traffic.
Each listener has rules that determine how to forward traffic to target groups. A target group is a logical grouping of resources, such as EC2 instances, AWS Lambda functions, or IP addresses. The load balancer performs health checks by sending periodic requests to each target and marking it unhealthy if it does not respond within a specified threshold.
When a target becomes unhealthy, the load balancer stops sending traffic to it until it passes health checks again. The cross-zone load balancing feature distributes traffic evenly across all registered targets in all enabled Availability Zones, rather than only within each zone. The ELB also integrates with AWS Auto Scaling, which can automatically add or remove targets based on load.
In a typical real-world setup, an ALB handles HTTPS traffic on port 443, terminates the SSL/TLS session using an AWS Certificate Manager certificate, and forwards decrypted HTTP traffic to backend EC2 instances running a web application. The load balancer also sends access logs to Amazon S3 for auditing and troubleshooting. Sticky sessions, also called session affinity, can be enabled to ensure a user's requests are always sent to the same target during a session.
This is important for stateful applications like shopping carts.
Real-Life Example
Think about a busy airport check-in counter. There are many counters, each staffed by an agent. Passengers arrive at the airport and need to check their bags and get boarding passes.
Without any organization, everyone would crowd around one agent, causing chaos and long waits. To solve this, the airport has a queuing system. As passengers enter the check-in area, a digital display tells them which counter to go to.
The system spreads people evenly, sending families with many bags to one agent and business travelers to another. If an agent needs a break or the printer at a counter breaks, the system stops sending passengers there and redirects them to other counters. The entire check-in process stays efficient even when a flight is delayed and a huge group arrives.
In the IT world, your application is the airport, and the servers are the check-in agents. The Elastic Load Balancer is the digital queuing system. It sees every new visitor coming to your website and decides which server should handle that person's request.
If one server is getting too many requests, the load balancer sends new visitors to a less busy server. If a server crashes or becomes slow, the load balancer stops sending traffic there and uses only the healthy servers. Just like the airport can open more counters during peak times, the load balancer can work with Auto Scaling to automatically launch new servers when traffic increases and shut them down when traffic drops.
This ensures passengers never wait too long and your website never goes down because of a sudden surge in visitors.
Why This Term Matters
In modern IT environments, applications must be highly available and scalable. A single server is a single point of failure. If that server goes down due to hardware failure, software crash, or a traffic spike, the entire application becomes unavailable.
An Elastic Load Balancer eliminates this risk by distributing traffic across multiple servers. If one server fails, the load balancer automatically routes traffic to the remaining healthy servers, ensuring business continuity. This is especially critical for e-commerce platforms, banking applications, and any service where downtime directly translates to lost revenue or customer trust.
Beyond fault tolerance, load balancing improves application performance. By spreading requests evenly, no single server becomes a bottleneck. Users experience faster response times because requests are handled by servers that are not overwhelmed.
This horizontal scaling approach is more cost-effective than buying a single massive server, as you can add many smaller, cheaper machines and use a load balancer to manage them. The elastic nature of AWS ELBs means the service scales automatically to handle unpredictable traffic patterns, such as flash sales, product launches, or denial-of-service attacks. From an operational perspective, load balancers simplify maintenance.
You can take a server out of service for updates or patching without affecting end users. The load balancer gracefully drains connections from the server being updated while continuing to serve traffic from other servers. This enables zero-downtime deployments.
For security, load balancers can offload SSL/TLS encryption, reducing the computational burden on backend servers. They also integrate with AWS Web Application Firewall (WAF) to filter malicious traffic before it reaches your application. For IT professionals, understanding load balancers is essential for designing resilient architectures that meet service-level agreements and compliance requirements.
How It Appears in Exam Questions
Exam questions about Elastic Load Balancers typically fall into three categories: scenario-based design, configuration steps, and troubleshooting. In scenario-based questions, you are given a description of an application's requirements and must choose the correct load balancer type and configuration. For example: A company runs a web application with a static website and an API that processes JSON data.
They want to serve the static content from one set of instances and the API from another set. Which load balancer should they use? The answer is an Application Load Balancer with path-based routing, directing requests to /static to one target group and /api to another.
Configuration questions ask you to put steps in the correct order or identify a missing step. For instance: A developer created an ALB and added EC2 instances to a target group, but users cannot reach the application. What is the most likely cause?
Possible answers include: the security group of the instances does not allow traffic from the ALB, the health check is failing because the path is wrong, or the listener is not configured. Troubleshooting questions often involve analyzing CloudWatch metrics or VPC Flow Logs. You might see a question where the ALB shows a 503 Service Unavailable error.
You need to determine that the target group has no healthy instances, possibly because the health check path returns a non-200 status or the instances are stopped. Another pattern is comparing ELB types. A question might ask: Which load balancer can handle millions of requests per second with the lowest latency and preserve the client source IP?
The correct choice is Network Load Balancer. Some questions combine ELB with Auto Scaling. For example: An application experiences increased latency during peak hours. A solutions architect recommends adding more instances and distributing traffic.
What should they configure? The answer is an Auto Scaling group with a launch template and an ALB attached to the group. Questions also test deeper knowledge, such as how an ALB's IP address can change over time, so you should not whitelist the ALB's IP in external firewalls.
Instead, you should use AWS Global Accelerator or a Network Load Balancer with an elastic IP. Understanding these question patterns is crucial because the exam often presents multiple correct-sounding answers, but only one that aligns perfectly with AWS best practices and service limitations.
Practise Elastic Load Balancer Questions
Test your understanding with exam-style practice questions.
Example Scenario
You are a solutions architect at a company that runs an online book store. The application is deployed on multiple EC2 instances spread across two Availability Zones. Your manager asks you to ensure the application remains available even if one entire Availability Zone goes down.
You decide to use an Application Load Balancer. First, you create a target group named Books-TG and register the EC2 instances from both AZs as targets. You configure the health check to hit the path /health and set the healthy threshold to 2 consecutive successful responses and the unhealthy threshold to 2 consecutive failures.
Then you create the ALB, assign it a security group that allows inbound HTTP (port 80) and HTTPS (port 443) from the internet, and attach it to your VPC with subnets in both AZs. You configure a listener on port 443 that terminates the SSL certificate. The listener forwards traffic to the Books-TG target group.
You also enable cross-zone load balancing so traffic is distributed evenly across all instances in both AZs. Finally, you attach the ALB to an Auto Scaling group that spans both AZs. If traffic spikes during a sale, Auto Scaling launches new instances, and the ALB automatically starts sending traffic to them.
If one AZ fails, the health checks mark instances in that AZ as unhealthy, and the ALB routes all traffic to the healthy AZ. Users never experience downtime. The bookstore's application remains fast and reliable, and the company avoids losing sales during peak events.
Common Mistakes
Thinking all AWS load balancers are the same
ALB, NLB, and GWLB have different OSI model layers, features, and use cases. Using the wrong type can cause application failures or higher costs.
Match the load balancer type to the application protocol and routing needs. Use ALB for HTTP/HTTPS, NLB for TCP/UDP with extreme performance, and GWLB for third-party appliances.
Forgetting to configure health checks
Without health checks, the load balancer will send traffic to unhealthy instances, causing errors for users and making the application unreliable.
Always define a health check path that returns a 200 OK status. Use a path that reflects the application health, such as /health or /index.html.
Assuming the load balancer's IP address is static
ALB and NLB (unless you use an Elastic IP for NLB) have IP addresses that can change. Whitelisting these IPs in external firewalls will break connectivity when the IP changes.
For ALB, always use its DNS name to connect. For NLB, assign an Elastic IP to each subnet to get a static IP, or use AWS Global Accelerator with static IP addresses.
Placing backend instances in a public subnet
This unnecessarily exposes the instances to the internet, increasing the attack surface. Best practice is to keep instances in private subnets that only accept traffic from the load balancer.
Launch EC2 instances in private subnets. Configure the security group of the instances to allow inbound traffic only from the ALB's security group (or the VPC CIDR if using NLB).
Exam Trap — Don't Get Fooled
{"trap":"You are asked to choose a load balancer for an application that requires the client's real IP address for logging. The options include ALB and NLB without any additional detail. Learners often pick ALB because it is more common, but NLB preserves the client IP by default."
,"why_learners_choose_it":"They associate ALB with web applications and assume it always has more features. They forget that ALB replaces the client IP with its own private IP unless you enable proxy protocol or use X-Forwarded-For headers.","how_to_avoid_it":"Remember that NLB preserves the source IP by default because it operates at Layer 4 and does not terminate the connection.
ALB terminates the client connection, so it loses the original IP unless you use X-Forwarded-For or proxy protocol. For strict IP-based logging or whitelisting, use NLB."
Step-by-Step Breakdown
Define listeners
A listener is a process that checks for connection requests. You configure it with a protocol and port, such as HTTPS on port 443. The listener defines how the load balancer routes traffic from clients to targets.
Create a target group
A target group groups the resources that will receive traffic, like EC2 instances, Lambda functions, or IP addresses. You register these resources as targets within the group.
Configure health checks
You set a health check path, interval, and thresholds. The load balancer sends requests to each target periodically. If a target fails the health check, it is marked unhealthy and removed from receiving traffic until it recovers.
Set up routing rules
You define rules that tell the listener how to forward traffic to target groups. For example, a rule can state that requests for /api go to one target group and requests for /images go to another. This enables content-based routing.
Attach the load balancer to subnets
You select the subnets in which the load balancer will run. For high availability, you must select at least two subnets in different Availability Zones. The load balancer creates a network interface in each chosen subnet.
Configure security groups
A security group acts as a virtual firewall for the load balancer. You must allow inbound traffic from clients on the listener ports. For the backend instances, you create another security group that allows traffic only from the load balancer's security group.
Integrate with Auto Scaling
Attach the target group to an Auto Scaling group. When traffic increases, Auto Scaling launches new instances, which automatically register with the target group. The load balancer then starts distributing traffic to the new instances seamlessly.
Practical Mini-Lesson
To configure an Application Load Balancer in practice, you start by designing the architecture. First, determine the protocol and port your application uses. Most web applications use HTTPS on port 443.
You will need an SSL/TLS certificate, which can be obtained from AWS Certificate Manager (ACM) for free. When creating the ALB in the AWS Management Console, choose internet-facing if the application is accessible from the internet, or internal if it is only for internal traffic. You must select at least two subnets in different Availability Zones to ensure high availability.
This is a critical point: if you only select one subnet, the load balancer becomes a single point of failure if that Availability Zone goes down. Next, configure the listener. For an HTTPS listener, you select the protocol HTTPS, port 443, and then choose the ACM certificate.
The listener will terminate the SSL connection, meaning the traffic between the client and the ALB is encrypted, but the traffic between the ALB and the backend instances can be in plain HTTP, which reduces the CPU load on your instances. However, in a secure environment, you might want to also encrypt the traffic between the ALB and instances using HTTPS. That would require installing certificates on each instance.
After the listener, you create the target group. You specify the protocol and port on which the instances listen, typically HTTP on port 80. You also configure the health check path.
A common mistake is using the root path /, but a better practice is to create a lightweight health check endpoint, such as /health, that returns a 200 OK if the application is truly healthy, including database connectivity. The health check interval should be set to about 30 seconds, with a healthy threshold of 2 and an unhealthy threshold of 2. This balances quick detection of failures with avoiding false positives.
Once the target group is ready, you register your EC2 instances. You can do this manually or automatically through an Auto Scaling group. If you use Auto Scaling, the instances are automatically registered when they launch and deregistered when they terminate.
This is the recommended approach for production. After registration, the load balancer begins sending traffic. You can test by accessing the ALB's DNS name, not an IP address. Remember, using the DNS name is essential because the IP address of the ALB can change.
Finally, monitor the load balancer using CloudWatch metrics. Key metrics include RequestCount, HealthyHostCount, UnhealthyHostCount, TargetResponseTime, and HTTP 5xx errors. If you see a spike in 5xx errors, check if the health check path is correct or if the backend instances are overloaded.
Also enable access logs to an S3 bucket for detailed request analysis. This helps with security audits and troubleshooting slow requests. In terms of cost, you pay per hour for each ALB or NLB, plus per GB of data processed.
Use cost explorer to monitor these costs, as leaving idle load balancers running can accumulate charges.
Memory Tip
Remember ELB stands for 'Even Load Balancing' and always think 'ALB for Apps, NLB for Networks, GWLB for Gateways.' For exams, the ALB is your go-to for HTTP/HTTPS, and NLB is for TCP/UDP with static IPs.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
Related Glossary Terms
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
5G is the fifth generation of cellular network technology, designed to deliver faster speeds, lower latency, and support for many more connected devices than previous generations.
An A record is a type of DNS resource record that maps a domain name to an IPv4 address.
An AAAA record is a DNS record that maps a domain name to an IPv6 address, allowing devices to find each other over the internet using the newer IP addressing system.
A/B testing is a controlled experiment that compares two versions of a single variable to determine which one performs better against a predefined metric.
Frequently Asked Questions
Can an Elastic Load Balancer be used to balance traffic across different AWS regions?
No, a single ELB operates within a single region. To balance traffic across regions, you combine ELB with Amazon Route 53 using latency-based routing or geolocation routing.
What is the difference between an Application Load Balancer and a Network Load Balancer?
An ALB works at Layer 7 and supports advanced routing features like path and host-based routing. An NLB works at Layer 4, handles millions of requests per second with extremely low latency, and preserves the client source IP address.
How do I make the load balancer's IP address static?
For an NLB, you can assign an Elastic IP address to each subnet. For an ALB, you cannot assign a static IP directly. Instead, use AWS Global Accelerator, which provides static IP addresses and sits in front of the ALB.
Why is my website returning a 503 Service Unavailable error?
This usually means the target group has no healthy instances. Check that your EC2 instances are running, the health check path is correct, and the security group of the instances allows traffic from the ALB.
Can I use the same load balancer for multiple applications?
Yes, with an ALB you can use multiple listeners and target groups, and use path-based or host-based routing to direct traffic to different applications. For example, app1.example.com can go to one target group and app2.example.com to another.
Does an Elastic Load Balancer support WebSocket?
Yes, the Application Load Balancer supports WebSocket and HTTP/2 protocols natively. You do not need any special configuration beyond using an HTTP or HTTPS listener.
Summary
The Elastic Load Balancer is a foundational AWS service that ensures your applications remain available, scalable, and performant by distributing incoming traffic across multiple resources. It is not a single product but a family of services: the Application Load Balancer for web traffic, the Network Load Balancer for high-performance TCP/UDP traffic, and the Gateway Load Balancer for virtual appliances. Understanding how to configure listeners, target groups, health checks, and security groups is essential for any cloud architect.
The ELB integrates with Auto Scaling, Route 53, and AWS WAF, enabling robust architectures that can handle failures and traffic spikes automatically. For exam takers, especially for the AWS SAA, DVA, and SOA certifications, the ELB is a heavily tested topic. You must know the differences between load balancer types, how to troubleshoot common issues like health check failures and 503 errors, and how to secure traffic end-to-end.
A common mistake is to treat all load balancers as identical, but each type serves a specific purpose. The key takeaway is to always match the load balancer type to the requirements of the application protocol, latency needs, and routing features. By mastering this term, you gain the ability to design resilient, cost-effective systems that meet both performance and availability goals.