Before we can talk about Elastic Load Balancing, we need to understand the basic problem it exists to solve: what happens when one server isn’t enough.

What Is Load Balancing?

Load balancing is the practice of distributing incoming network traffic across multiple servers so that no single server has to handle all the work alone. Without it, a popular application would either need one impossibly powerful server, or it would simply slow to a crawl — or crash — under heavy demand. Load balancing also provides a second, equally important benefit: if one server fails, traffic can be automatically redirected to the servers that are still healthy, so users never even notice.

What Is Amazon Elastic Load Balancing (ELB)?

Amazon Elastic Load Balancing is a fully managed AWS service that automatically distributes incoming application traffic across multiple targets, such as EC2 instances, containers, or IP addresses, in one or more Availability Zones. “Fully managed” means AWS operates, scales, and patches the load balancer itself, so your team never has to install load-balancing software or worry about the load balancer becoming a bottleneck on its own. Companies like Airbnb and Netflix rely on this kind of automatic traffic distribution to keep their websites responsive even during massive spikes, such as a flash sale or a new show release, without any engineer manually redirecting traffic in the moment.

The Four Types of AWS Load Balancers

AWS offers four distinct load balancer types, each tuned for a different layer of network traffic and a different kind of application:

An Elastic Load Balancer is built from a small number of clearly defined pieces working together, regardless of which type you choose.

The Building Blocks

• Load Balancer — the front door that receives all incoming traffic before it reaches any application server.
• Listener — a configuration that checks for connection requests on a specific protocol and port, such as HTTPS on port 443.
• Target Group — a logical collection of servers (targets) that the load balancer routes requests to.
• Health Checks — periodic pings the load balancer sends to each target to confirm it’s still capable of handling traffic.
• Rules — conditions attached to a listener that decide which target group a given request should go to, based on things like the URL path.

flowchart TB
    USER["Users on the Internet"] --> ELB["Elastic Load Balancer
(Listener on port 443)"]
    ELB -->|"Rule: /api/*"| TG1["Target Group A
(API Servers)"]
    ELB -->|"Rule: /images/*"| TG2["Target Group B
(Image Servers)"]
    subgraph AZ1["Availability Zone A"]
        TG1
        S1["EC2 Instance 1"]
        S2["EC2 Instance 2"]
    end
    subgraph AZ2["Availability Zone B"]
        TG2
        S3["EC2 Instance 3"]
        S4["EC2 Instance 4"]
    end
    TG1 --> S1
    TG1 --> S2
    TG2 --> S3
    TG2 --> S4
    ELB -.->|"Health checks"| S1
    ELB -.->|"Health checks"| S2
    ELB -.->|"Health checks"| S3
    ELB -.->|"Health checks"| S4
        

Where ELB Fits Inside AWS

Elastic Load Balancing typically sits at the very front of an application’s architecture, directly behind Amazon Route 53 (DNS) and in front of Amazon EC2 instances, containers running on Amazon ECS or EKS, or AWS Lambda functions. A common pattern pairs an Application Load Balancer with an Auto Scaling group, so that as the load balancer detects rising traffic, new EC2 instances are automatically launched and registered as new targets, and the load balancer immediately begins sending them traffic.

What actually happens between the moment a user’s browser sends a request and the moment a specific server responds?

Step by Step: Handling a Request

How Health Checks Actually Work

A health check is a small, repeated request the load balancer sends to each registered target — often a simple HTTP request to a designated path like “/health.” If a target responds successfully a configured number of times in a row, it’s marked healthy and receives traffic. If it fails a configured number of times in a row, it’s marked unhealthy and is automatically removed from rotation until it starts passing again, all without any human intervention.

Traffic flowing through a load balancer follows a predictable lifecycle from request to response, and targets themselves have their own lifecycle of joining and leaving rotation.

The Lifecycle of a Target

A server doesn’t simply appear in front of user traffic the instant it launches. It’s first registered with a target group, then it enters an “initial” state while health checks run, then it becomes “healthy” and starts receiving traffic, and eventually it may be deregistered — for example, when an Auto Scaling group decides to remove it during a scale-in event. AWS supports “connection draining” (also called deregistration delay), which gives in-flight requests time to finish before a target is fully removed, so a user’s checkout doesn’t get abruptly cut off mid-transaction.

sequenceDiagram
    participant AutoScaling as Auto Scaling Group
    participant ELB as Elastic Load Balancer
    participant Target as New EC2 Instance
    participant User as End User

    AutoScaling->>Target: Launch new instance
    AutoScaling->>ELB: Register instance with target group
    ELB->>Target: Send health checks
    Target-->>ELB: Healthy response
    ELB->>Target: Begin routing live traffic
    User->>ELB: Send request
    ELB->>Target: Forward request
    Target-->>User: Return response
        

Sticky Sessions

Some applications need a returning user to keep hitting the same server, for example, when session data is stored only in that one server’s memory. ELB supports “sticky sessions,” using a cookie to remember which target a specific user was last sent to, and routing their future requests back to that same target whenever possible.

Load balancing solves real problems, but it isn’t free of trade-offs — understanding both sides is exactly what interviewers look for.

The Core Trade-off: Simplicity vs. Control

Running your own reverse proxy or load-balancing software gives you complete control over every routing decision, but it also means you own patching that software, scaling it during traffic spikes, and keeping it highly available itself. Amazon ELB trades a small amount of low-level control for AWS guaranteeing that the load balancer itself never becomes the single point of failure it’s meant to protect against.

A load balancer that can’t scale itself would defeat its entire purpose — so ELB is built to grow automatically alongside demand.

Automatic Scaling of the Load Balancer Itself

Unlike a single server with a fixed capacity ceiling, Elastic Load Balancing automatically provisions additional capacity behind the scenes as traffic grows, adding more load balancer nodes across Availability Zones without any action from you. This is similar to a stadium that can magically add more ticket-checking gates the moment a line starts forming, rather than making everyone squeeze through the same fixed number of doors no matter how big the crowd gets.

Scaling in Practice

A ticket-sales company expecting a massive spike the moment a popular concert goes on sale might pair an Application Load Balancer with an Auto Scaling group configured to react quickly to rising request counts — as the load balancer’s metrics show increasing traffic, new EC2 instances launch and register within minutes, all coordinated automatically without an engineer manually adding capacity in the middle of the rush.

A load balancer’s entire job is to protect an application from a single point of failure — so it needs to avoid becoming one itself.

Spreading Across Availability Zones

Elastic Load Balancing is designed to operate across multiple Availability Zones simultaneously. You register targets from more than one Availability Zone, and the load balancer distributes traffic across all of them, so if an entire data center location experiences an outage, traffic simply continues flowing to the healthy targets in the remaining zones.

Durability vs. Availability

In the context of load balancing, availability is really the central concern — the load balancer holds no persistent data of its own to keep durable, but it must remain reachable and correctly routing traffic at all times. Amazon achieves this through redundant load balancer nodes, health checks, and cross-zone traffic distribution, so the loss of any single component doesn’t take down the front door to your entire application.

Because a load balancer sits at the very front of your application, it’s also naturally your first line of defense.

• Security groups — control exactly which sources are permitted to send traffic to the load balancer in the first place.
• SSL/TLS termination — the load balancer can handle encryption and decryption of HTTPS traffic, offloading that work from your application servers.
• Integration with AWS WAF — the AWS Web Application Firewall can be attached to an Application Load Balancer to block common web attacks before they ever reach your servers.
• Private, internal load balancers — an ELB can be configured to only accept traffic from within your VPC, keeping internal services hidden from the public internet entirely.
• Access logs — detailed logs of every request can be stored in Amazon S3 for later security analysis or auditing.

Since every single request to your application passes through it, a load balancer is one of the richest sources of operational insight you have.

Amazon ELB integrates with Amazon CloudWatch, continuously reporting metrics like request count, target response time, and the number of healthy versus unhealthy targets. Think of these metrics like the vital signs a doctor checks during a routine exam — individually simple numbers, but together they tell a clear story about overall health. Teams commonly set an alarm on the “unhealthy host count” metric so that if targets start failing health checks, someone is alerted before the remaining healthy servers become overwhelmed by the extra load.

Elastic Load Balancing rarely operates alone — its real power shows up in how it connects the rest of an application’s architecture together.

A common deployment pattern places an Application Load Balancer in front of an Auto Scaling group of EC2 instances, so the two services work as a coordinated pair: the load balancer distributes traffic and reports health, while Auto Scaling reacts to that traffic by adding or removing capacity. Teams running containerized applications on Amazon ECS or Amazon EKS similarly register containers as ELB targets, letting the load balancer route traffic to whichever containers are currently running, even as those containers are replaced during routine deployments.

Cost Considerations During Deployment

Amazon ELB bills based on the hours the load balancer runs plus a measure of the traffic it processes, similar to how a toll road charges a base fee plus a per-vehicle charge. A common beginner mistake is provisioning many small, separate load balancers for different services when a single Application Load Balancer using path-based routing rules could serve all of them at a lower combined cost.

Integration with Serverless Architectures

Elastic Load Balancing isn’t limited to traditional servers. An Application Load Balancer can route traffic directly to AWS Lambda functions as targets, letting a team expose a serverless backend through the same familiar load balancing layer used for EC2-based applications. This is particularly useful when migrating an application gradually from servers to serverless — the load balancer can send some paths to Lambda functions and others to EC2 targets during the transition, so users never notice which underlying technology is answering their request.

Choosing the right load balancer type and configuration is itself a design decision, and getting it wrong is a surprisingly common mistake.

Good Patterns to Follow

• Use path-based or host-based routing to consolidate load balancers instead of creating a new one per microservice.
• Enable deregistration delay (connection draining) so in-flight requests finish cleanly during scale-in or deployments.
• Spread targets evenly across at least two Availability Zones so the load balancer can actually route around a zone failure.

Most ELB problems in the real world trace back to a handful of avoidable configuration mistakes.

Seeing how real organizations actually use ELB makes the abstract concepts click into place.

Across every one of these industries, the common thread is the same: the load balancer is invisible when everything works, and indispensable the moment something doesn’t — a single server crashing, a data center losing power, or traffic spiking tenfold overnight all become non-events instead of outages.

An Application Load Balancer works at the HTTP/HTTPS layer and can route based on URL paths or hostnames, making it ideal for web applications. A Network Load Balancer works at the TCP/UDP layer, prioritizing extreme performance and preserving the client’s original IP address, making it ideal for latency-sensitive or high-throughput workloads.

Amazon designs Elastic Load Balancing to be highly available by running redundant nodes across multiple Availability Zones and automatically scaling its own capacity, so it’s built specifically to avoid becoming a single point of failure for your application.

The load balancer stops sending new traffic to that target after it fails a configured number of consecutive health checks, and automatically resumes sending traffic once the target starts passing health checks again, all without manual intervention.

Yes, particularly with an Application Load Balancer, which supports path-based and host-based routing rules, letting one load balancer serve many different backend applications or microservices based on the incoming request’s URL or hostname.

No. Amazon Route 53 is a DNS service that translates domain names into IP addresses and can route traffic across regions, while Elastic Load Balancing distributes traffic across servers within one or more Availability Zones once that traffic has already arrived — the two are often used together, with Route 53 pointing to a load balancer.