CRUCIBLE
Log in
← Back to Services

Elastic Load Balancing (ELB)

LOW

Elastic Load Balancing (ELB) is an AWS service that distributes incoming application traffic across multiple targets, such as Amazon EC2 instances, to ensure high availability, fault tolerance, and scalability. It monitors target health, automatically scales capacity based on traffic changes, and supports various load balancer types for different application needs. (Source Page 2, 5)

Learning Objectives

  • Understand the core function and benefits of Elastic Load Balancing (ELB) in AWS.
  • Differentiate between Application Load Balancer (ALB), Network Load Balancer (NLB), Gateway Load Balancer (GWLB), and Classic Load Balancer (CLB), and their appropriate use cases.
  • Explain the components of ELB, including listeners, target groups, and health checks, and how they contribute to traffic routing and application reliability.
  • Describe advanced ELB features like TLS termination, cross-zone load balancing, connection draining, and sticky sessions.
  • Be able to outline the process of creating and configuring load balancers and their associated components using the AWS CLI and console.
  • Recognize how ELB integrates with other AWS services like EC2 Auto Scaling and Route 53 to build scalable and highly available architectures.

Introduction to Elastic Load Balancing (ELB)

Elastic Load Balancing (ELB) is a fundamental AWS service for creating highly available and scalable applications by distributing incoming traffic across multiple resources.

ELB is an AWS service that distributes incoming traffic across multiple targets, such as Amazon EC2 instances, containers, or IP addresses, in one or more Availability Zones. It acts as a traffic director, optimizing speed and utilization, ensuring no single server is overloaded, and redirecting traffic if a server fails. New servers are automatically incorporated into the load balancing process.
ELB is essential for high-traffic websites and applications needing cost-effective scalability. It provides high availability by distributing traffic across multiple targets and Availability Zones (AZs). It enhances security by allowing security groups and internal load balancers. ELB improves performance by offloading CPU-intensive tasks like TLS termination from application servers and monitors target health, routing traffic only to healthy targets. It enables zero-downtime deployments and maintains consistent performance.
ELB works in conjunction with Amazon EC2 Auto Scaling groups to manage capacity dynamically, ensuring sufficient capacity to meet demand and replacing unhealthy instances. It can be associated with Amazon Route 53 for custom domain names and advanced routing. ELB also integrates with Amazon CloudWatch for real-time performance monitoring, providing metrics on HTTP responses and host health.
Load balancers are used for secure access, providing a single point of entry to web servers. They enable decoupling by separating application environments using public and internal load balancers. They provide fault tolerance by distributing traffic across multiple Availability Zones for high availability and increase elasticity and scalability with minimal overhead. ALBs are ideal for microservices and containers, as shown in the migration of monolithic applications.

ELB Architecture and Core Components

To function effectively, an Elastic Load Balancer relies on listeners to receive traffic and target groups to manage the backend resources.

A listener defines the port and protocol the load balancer listens on for incoming connections. Each load balancer requires at least one listener, and a maximum of 50 listeners can be created per load balancer. Routing rules are defined on listeners, specifying a target group, a condition, and a priority. Traffic is forwarded to the specified target group when the condition is met. Content-based routing is possible by defining multiple rules based on request content, and each listener requires at least one default rule.
Technical Specs: Maximum 50 listeners per load balancer
A target group contains registered targets such as Amazon EC2 instances or Amazon Elastic Container Service (Amazon ECS) container instances. A single target can belong to multiple target groups. Health checks are configured for each target group to monitor the health of registered targets, ensuring traffic is only routed to healthy instances.
Health checks monitor the health of registered targets. If a target fails a health check, the ELB removes it from the load balancing pool and stops sending new requests to it. Once the target becomes healthy again, it is automatically added back to the pool. This mechanism contributes significantly to high availability by ensuring traffic is always directed to functional instances. Health checks can be configured with specific protocols (TCP, HTTP, HTTPS), path, healthy/unhealthy thresholds, timeout, interval, and success codes.
Technical Specs: Default Healthy Threshold: 5, Unhealthy Threshold: 2, Timeout: 5 seconds, Interval: 30 seconds, Success Codes: HTTP 200 (configurable)

Types of ELB Load Balancers

ELB offers four types of load balancers, each optimized for different application architectures and traffic patterns.

The four main types of Elastic Load Balancers are Application Load Balancer (ALB), Network Load Balancer (NLB), Gateway Load Balancer (GWLB), and Classic Load Balancer (CLB).

Application Load Balancer (ALB)

Operates at Layer 7 (application layer) of the OSI model. It provides advanced routing for modern applications such as microservices and containers.
operating_layer Layer 7 (Application Layer)
supported_protocols HTTP/1.1, HTTP/2, WebSocket, gRPC
routing_features Path-based routing, Host-based routing, native IPv6 support, dynamic ports, deletion protection, request tracking, enhanced metrics, access logs
scheme Internet-facing or Internal
ip_address_type IPv4
Use Cases:
  • Microservices architectures
  • Container-based applications
  • HTTP/HTTPS traffic distribution based on content

Network Load Balancer (NLB)

Operates at Layer 4 (transport layer) and is designed for extreme high performance and low latency, handling millions of requests per second. It's optimized for volatile traffic patterns and uses a single static IP address per Availability Zone.
operating_layer Layer 4 (Transport Layer)
supported_protocols TCP, UDP, TLS (for TLS listeners)
performance High-throughput, low-latency, millions of requests per second
ip_addressing Can assign Elastic IP addresses, supports AWS-provided static IP per Availability Zone
supported_target_types EC2 instances, IP addresses (inside or outside VPC), Application Load Balancers (as backend targets)
listeners TCP, UDP, TLS
health_checks TCP or HTTP/HTTPS based health checks
port_mapping Allows specifying port for each target
tls_offloading Supports TLS termination at Layer 4 (decrypts, re-encrypts to backend)
tls_pass_through NLB does no decryption/encryption; backend handles it
cross_zone_load_balancing_default Each NLB node distributes traffic only to registered targets in its own AZ
cross_zone_load_balancing_enabled Distributes traffic across all registered targets in all enabled AZs (incurs data transfer fees)
preserve_source_ip_address Enabled by default; backend sees client’s original IP
Use Cases:
  • Applications requiring ultra-low latency
  • Applications with volatile traffic patterns
  • When a static IP address per Availability Zone is needed (e.g., for IP whitelisting)
  • Gaming, IoT, high-volume data streaming

Gateway Load Balancer (GWLB)

Operates at Layer 3 (network layer) and Layer 4 (transport layer). It is a transparent gateway specifically designed for deploying, scanning, and managing third-party virtual appliances such as firewalls, intrusion detection systems (IDS), and deep packet inspection (DPI) systems.
operating_layer Layer 3 (Network Layer)
protocol GENEVE protocol on port 6081
placement Sits between VPC and the internet, or between VPCs
functionality Routes traffic to virtual appliances without altering packet headers, performs autoscaling for appliances, provides GENEVE encapsulation (passing metadata like source/destination IP, original headers)
supported_target_types EC2 instances running security appliances, private IP addresses
Use Cases:
  • Centralized inspection of all traffic for security (firewalls, IDS)
  • Network analysis and traffic monitoring with virtual appliances

Classic Load Balancer (CLB)

An older generation load balancer that operates at Layer 4 (TCP) and Layer 7 (HTTP/HTTPS). AWS does not recommend it for new applications.
operating_layer Layer 4 (TCP) and Layer 7 (HTTP/HTTPS)
features Distributes traffic across multiple EC2 instances, supports basic health checks, supports SSL termination, supports sticky sessions using cookies
Use Cases:
  • Migration scenarios for older, unmodernized applications
  • Applications built on the deprecated EC2-Classic platform

Advanced ELB Features

Elastic Load Balancers offer several advanced features to enhance security, performance, and application reliability.

TLS termination involves the load balancer handling SSL/TLS decryption and certificate management, offloading this CPU-intensive task from the backend application servers. For Network Load Balancers, TLS termination happens at Layer 4, where the NLB decrypts incoming client traffic and then establishes a new TLS session (re-encrypts) to the backend target. This requires a TLS listener on port 443 and a TLS target group also on port 443.
In TLS Pass-Through mode, the Network Load Balancer does not decrypt or re-encrypt the traffic. Instead, it passes the encrypted client traffic directly to the backend target, which then handles the decryption. This configuration requires a TCP target group, typically on port 443.
By default, each NLB node distributes traffic only to registered targets in its own Availability Zone, which can lead to imbalance. When cross-zone load balancing is enabled, each NLB node distributes traffic across all registered targets in all enabled Availability Zones. Enabling cross-zone load balancing for NLB and GWLB incurs data transfer fees between AZs.
This feature ensures that in-flight requests complete before an instance is deregistered from the load balancer or marked unhealthy. It prevents data loss or errors for ongoing user requests when instances are terminated (e.g., by Auto Scaling), fail health checks, or are updated. The load balancer stops sending new requests to the instance but allows existing connections to finish within a configurable timeout period. This timeout duration can be configured from 0 to 3,600 seconds (default is 300 seconds). This feature is called 'Connection Draining' for CLB and 'Deregistration Delay' for ALB and NLB.
Technical Specs: Configurable timeout duration: 0 to 3,600 seconds (default 300 seconds)
Sticky sessions ensure that requests from a specific client are consistently routed to the same target instance for a defined duration. This is crucial for stateful applications where maintaining session information on a particular backend server is necessary. This feature can be configured within the target group attributes, with a stickiness duration ranging from 1 second to 7 days.
Technical Specs: Stickiness duration: 1 second to 7 days (demonstrated with 30 seconds)

Creating an ELB using AWS CLI

procedure

Load balancers can be created and configured using either the AWS Management Console or the AWS Command Line Interface (AWS CLI). This section outlines the general steps for creating a load balancer using the AWS CLI.

The process involves creating the load balancer itself, defining target groups for backend resources, registering instances with those groups, and configuring listeners to direct incoming traffic.

Prerequisites

  • AWS CLI installed and configured
  • At least two subnets from different Availability Zones
  • Security groups for the load balancer and instances
  • EC2 instances to register as targets
1

Create a load balancer

Establishes the entry point for distributing traffic.

aws elbv2 create-load-balancer --name my-load-balancer --subnets subnet-01a subnet-02b --security-groups sg-xxxxxxxx --scheme internet-facing
2

Create a target group

Organizes backend instances and defines health check settings for them.

aws elbv2 create-target-group --name my-target-group --protocol HTTP --port 80 --vpc-id vpc-xxxxxxxx
3

Register EC2 instances with the target group

Adds instances to the pool of resources that the load balancer can send traffic to.

aws elbv2 register-targets --target-group-arn arn:aws:elasticloadbalancing:... --targets Id=i-xxxxxxxx,Port=80
4

Create a listener with a default rule

Configures the load balancer to listen on specific ports/protocols and forward requests to the target group.

aws elbv2 create-listener --load-balancer-arn arn:aws:elasticloadbalancing:... --protocol HTTP --port 80 --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:...
5

Verify target health (optional)

Confirms that registered instances are healthy and ready to receive traffic.

aws elbv2 describe-target-health --target-group-arn arn:aws:elasticloadbalancing:...

Application Load Balancer Demonstration Insights

A practical demonstration of ALB configuration highlights key aspects of target setup, traffic distribution, and security group interactions.

Two Amazon Linux 2023 T3 micro EC2 instances were configured as simple web applications. User data scripts were used to automate the installation and starting of the Apache HTTP Server (httpd), and to create an `index.html` file displaying 'Hello world' and the instance's private IP address. Instances were renamed for clarity (e.g., 'CS load balancer target group 01').
Technical Specs: OS Image: Amazon Linux 2023 (kernel 6.1 AMI), Instance Type: T3 micro, VPC: Default VPC
An Application Load Balancer was created with an 'Internet-facing' scheme and IPv4 address type, spanning all Availability Zones in `us-east-1`. A new security group ('CSLB demo sg') was created for the ALB, allowing HTTP on port 80 from anywhere. A target group ('CS demo TGT') was created first, specifying instances as target type, HTTP protocol on port 80, and registering both EC2 instances. The ALB's listener was configured to forward HTTP:80 traffic to this target group. After the ALB became 'Active', accessing its DNS name showed traffic alternating between the two target instances, confirming round-robin distribution.
Technical Specs: ALB Scheme: Internet-facing, IP Address Type: IPv4, Target Type: Instances, Listener: HTTP:80
Removing the HTTP:80 inbound rule from the EC2 instances' security group caused direct access to the instances via public IP to time out. However, access via the ALB's DNS name continued to work, demonstrating that the ALB could still reach its targets. Re-enabling access required adding an inbound rule to the EC2 instance security groups allowing HTTP:80 specifically from the ALB's security group, highlighting that EC2 instances need to allow traffic from the ALB's security group for proper routing.
ALBs support multiple listeners, each configured with different protocols, ports, and forwarding rules. Besides forwarding to a target group, listeners can be configured with rules to redirect client requests to a different URL or return a fixed HTTP response (e.g., HTTP 500 with custom JSON content). This allows for diverse traffic management strategies based on the request.

Network Load Balancer Configuration Review

A review of NLB configuration options reveals its flexibility for high-performance, low-latency applications, particularly in setting up listeners and target groups.

When configuring an NLB, key settings include the load balancer name, scheme (Internet-facing or internal), IP Address Type (IPv4 or Dual-stack for IPv4/IPv6), and network mapping (VPC and subnets across Availability Zones). IP assignment can be AWS-assigned or use Elastic IPs. Security groups can be created and attached to the NLB.
Technical Specs: IP Address Type: IPv4 or Dual-stack
NLB listeners define the protocol and port for incoming traffic. Supported protocols are TCP, TLS, UDP, and TCP/UDP. Common ports include 80, 443, or custom ports.
Technical Specs: Protocols: TCP, TLS, UDP, TCP/UDP. Ports: 80, 443, custom.
Target group settings for NLB are largely similar to other load balancers. Target type options include instances, IP addresses, Lambda functions, or Application Load Balancers. For NLB, supported protocols for target groups are TCP, TLS, UDP, and TCP/UDP. Health checks support TCP, HTTP, and HTTPS protocols, with configurable advanced settings such as healthy/unhealthy thresholds, timeout, interval, and success codes. The 'Target Deregistration Delay' (connection draining) can be configured from 0 to 3,600 seconds (default 300 seconds).
Technical Specs: Target Deregistration Delay: Default 300 seconds, Range 0 to 3,600 seconds
Specific traffic configuration attributes for NLB include 'Preserve Client IP Address', which is enabled by default, allowing backend targets to see the client’s original IP. This can be toggled on or off. 'Session Stickiness' can also be enabled, but it is not compatible with TLS protocol target groups on NLB, as stickiness is a Layer 7 concept.

ELB in High Availability and Scalability Architectures

Elastic Load Balancing plays a central role in designing robust, highly available, and scalable cloud architectures by working seamlessly with other AWS services.

ELB achieves high availability by distributing traffic across multiple EC2 instances deployed across at least two Availability Zones (AZs) within a region. If an EC2 instance or an entire AZ becomes unhealthy or fails, the load balancer automatically reroutes traffic to healthy instances in other AZs, preventing user downtime. This multi-AZ distribution is a key component for meeting Service Level Agreements (SLAs) and minimizing single points of failure.
ELB works with Auto Scaling Groups to dynamically adjust the number of EC2 instances based on demand. The ASG ensures sufficient capacity, scales out (adds instances) during high demand, scales in (removes instances) during low traffic, and automatically replaces unhealthy instances. The ELB monitors instance health, and CloudWatch metrics trigger the ASG's scaling actions, creating a dynamic and cost-effective capacity management system.
ALBs are ideal for microservices architectures, allowing for content-based routing (e.g., path-based) to direct different microservices or container instances. For stateless web applications, ELB + Auto Scaling is a cost-effective solution, especially when combined with Reserved Instances for baseline usage and Spot Instances for additional capacity, as the application can tolerate interruptions and distribute load across many identical instances.

Exam Focus

  • AWS often tests CLB concepts, especially backend compatibility, despite it being a legacy service. (Source Page 6)
  • For Gateway Load Balancer (GWLB), GENEVE protocol and port 6081 are key terms to remember. (Source Page 6)
  • Understand the differences between Application Load Balancers, Gateway Load Balancers, and Network Load Balancers, and when to choose one over the others. (Source Page 2)
  • Be aware that stickiness (session affinity) is an HTTP/HTTPS concept (Layer 7) and is not compatible with TLS listeners on a Network Load Balancer (Layer 4). (Source Page 6)
  • Remember that EC2 instances behind an ALB need to allow traffic specifically from the ALB's security group. (Source Page 7)
  • High availability within a region is achieved by distributing resources across multiple availability zones. (Source Page 10)

Glossary

Elastic Load Balancing (ELB)
An AWS service that automatically distributes incoming application traffic across multiple targets, such as Amazon EC2 instances, containers, IP addresses, in one or more Availability Zones.
Application Load Balancer (ALB)
An ELB type operating at Layer 7 (application layer) that provides advanced routing for modern applications like microservices and containers, supporting HTTP/1.1, HTTP/2, WebSocket, and gRPC.
Network Load Balancer (NLB)
An ELB type operating at Layer 4 (transport layer) designed for high-throughput, low-latency applications handling millions of requests per second, optimized for volatile traffic patterns.
Gateway Load Balancer (GWLB)
An ELB type operating at Layer 3 (network layer) and Layer 4 (transport layer) that acts as a transparent gateway for third-party virtual appliances (e.g., firewalls, IDS) using the GENEVE protocol.
Classic Load Balancer (CLB)
An older generation ELB type operating at Layer 4 (TCP) and Layer 7 (HTTP/HTTPS), not recommended by AWS for new applications.
Listener
A component of a load balancer that defines the port and protocol the load balancer listens on for incoming connections and includes routing rules to direct traffic to target groups.
Target Group
A logical grouping of registered targets (e.g., EC2 instances, container instances) where a load balancer routes traffic, and for which health checks are configured.
Health Check
A mechanism used by ELB to monitor the health of registered targets within target groups, removing unhealthy targets from the load balancing pool and re-adding them when they become healthy.
TLS Termination
The process where the load balancer handles SSL/TLS decryption and certificate management, offloading this CPU-intensive task from backend application servers.
TLS Pass-Through
An NLB configuration where the load balancer does not decrypt or re-encrypt TLS traffic, but passes the encrypted client traffic directly to the backend target for decryption.
Connection Draining (Deregistration Delay)
An ELB feature that ensures in-flight requests complete before an instance is deregistered or marked unhealthy, preventing data loss during scaling events or instance failures.
Sticky Sessions (Session Affinity)
An ALB feature that ensures requests from a specific client are consistently routed to the same target instance for a defined duration, important for stateful applications.
GENEVE Protocol
A network virtualization encapsulation protocol used by the Gateway Load Balancer (GWLB) on port 6081 to route traffic to virtual appliances without altering packet headers, while also passing metadata.

Key Takeaways

  • Elastic Load Balancing (ELB) is crucial for building scalable and highly available applications on AWS. (Source Page 2)
  • Four main types of ELB load balancers (ALB, NLB, GWLB, CLB) cater to different application needs and architectures. (Source Page 2)
  • Auto Scaling complements ELB for dynamic capacity management. (Source Page 2)
  • Understanding the features and use cases of each load balancer type is key to optimal application deployment. (Source Page 2)
  • Amazon CloudWatch provides comprehensive monitoring capabilities for ELB. (Source Page 2)
  • Elastic Load Balancing is a core component for improving availability and fault tolerance of EC2 instances. (Source Page 9)

Content Sources

07_AWS_Solutions_Architect_Associate_... Scaling and Name Resolution Introduction to Amazon ElastiCache Introduction to Amazon ElastiCache Cloud Architecture Fundamentals: High... Extracted: 2026-01-24 12:46:38.435469 Model: gemini-2.5-flash