Elastic Load Balancer distributes incoming application or network traffic across multiple targets, such as EC2 instances, containers (ECS), Lambda functions, and IP addresses, in multiple Availability Zones.
- Seamlessly handle failures of downstream instances
- Do regular health checks to your instances
- Provide SSL termination (HTTPS) for your websites
- Enforce stickiness with cookies
- High availability across zones
- Separate public traffic from private traffic
- Deleting ELB won’t delete the instances registered to it.
- Cross Zone Load Balancing – when enabled, each load balancer node distributes traffic across the registered targets in all enabled AZs.
- Supports SSL Offloading which is a feature that allows the ELB to bypass the SSL termination by removing the SSL-based encryption from the incoming traffic.
Why use an EC2 Load Balancer?
- An ELB (EC2 Load Balancer) is a managed load balancer
- AWS guarantees that it will be working
- AWS takes care of upgrades, maintenance, high availability
- AWS provides only a few configuration knobs
- It is integrated with many AWS offerings / services
Types of Elastic Load Balancer (ELB):
AWS has 3 kinds of managed Load Balancers
- Classic Load Balancer
- Application Load Balancer
- Network Load Balancer
Classic Load Balancer (v1 – old generation) – 2009:
It supports HTTP, HTTPS, TCP
Supports TCP (layer 4) and HTTP-HTTPS (layer 7)
AWS recommends using Application or Network load balancers instead.
Application Load Balancer (v2 – new generation) – 2016:
It Supports HTTP, HTTPS, WebSocket
ALB is layer 7 (HTTP). Supports redirects from HTTP to HTTPS.
ALB are a great fit for micro services & container-based application. For example: Docker & Amazon ECS.
Routing tables to different target groups:
- Routing based on path in URL (example.com/users & example.com/posts)
- Routing based on hostname in URL (one.example.com & other.example.com)
- Routing based on Query String, Headers
EC2 instances (can be managed by an Auto Scaling Group) – HTTP
ECS tasks (managed by ECS itself) – HTTP
Lambda functions – HTTP request is translated into a JSON event
IP Addresses – must be private IPs
ALB can route to multiple target groups
Health checks are at the target group level.
Cross-zone load balancing is always enabled in ALB.
ALB supports port mapping as well.
Application Load Balancers and Classic Load Balancers support X-Forwarded-For, X-Forwarded-Proto, and X-Forwarded-Port headers.
The application servers don’t see the IP of the client directly
The true IP of the client is inserted in the header X-Forwarded-For
We can also get Port (X-Forwarded-Port) and proto (X-Forwarded-Proto)
Network Load Balancer (v2 – new generation) – 2017:
It supports TCP, TLS (secure TCP) & UDP
Network load balancers (Layer 4) allow to:
- Forward TCP & UDP traffic to your instances
- Handle millions of request per seconds
- Less latency ~100 ms (vs 400 ms for ALB)
NLB has one static IP per AZ, and supports assigning Elastic IP (helpful for whitelisting specific IP)
NLB are used for extreme performance, TCP or UDP traffic
Not included in AWS free tier.
Support for static IP addresses for the load balancer, or assign one Elastic IP address per subnet enabled for the load balancer.
Cross-zone load balancing is disabled by default.
Network Load Balancers support connections from clients over inter-region VPC peering, AWS managed VPN, and third-party VPN solutions.
You CANNOT enable or disable Availability Zones for a Network Load Balancer after you create it.
Network Load Balancers use Proxy Protocol version 2 to send additional connection information such as the source and destination.
Load Balancer States:
Provisioning – The load balancer is being set up.
Active – The load balancer is fully set up and ready to route traffic.
Failed – The load balancer could not be set up.
Health Checks in Elastic Load Balancer:
Health Checks are crucial for Load Balancers. They enable the load balancer to know if instances it forwards traffic to are available to reply to
requests. The health check is done on a port and a route (/health is common). If the response is not 200 (OK), then the instance is unhealthy.
Health check by defaults happens every 5 seconds.
Load Balancer Stickiness:
- It is possible to implement stickiness so that the same client is always redirected to the same instance behind a load balancer
- Sticky sessions route requests to the same target in a target group. You enable sticky sessions at the target group level. You can also set the duration for the stickiness of the load balancer-generated cookie, in seconds. Useful if you have stateful applications.
- This works for Classic Load Balancers & Application Load Balancers
- The “cookie” used for stickiness has an expiration date you control
- Use case: make sure the user doesn’t lose his session data
- Enabling stickiness may bring imbalance to the load over the backend EC2 instances
Cross-Zone Load Balancing:
With Cross Zone Load Balancing: each load balancer instance distributes evenly across all registered instances in all AZ.
For Classic Load Balancer: Disabled by default & No charges for inter AZ data if enabled
For Application Load Balancer: Always on (can’t be disabled) & No charges for inter AZ data
For Network Load Balancer: Disabled by default & You pay charges ($) for inter AZ data if enabled
Elastic Load Balancer – SSL Certificates:
SNI(Server Name Indication) solves the problem of loading multiple SSL certificates onto one web server (to serve multiple websites).
It’s a “newer” protocol, and requires the client to indicate the hostname of the target server in the initial SSL handshake
The server will then find the correct certificate, or return the default one .
Note: Only works for ALB & NLB (newer generation), CloudFront & Does not work for CLB (older gen)
Classic Load Balancer (v1): Support only one SSL certificate. Must use multiple CLB for multiple hostname with multiple SSL certificates
Application Load Balancer (v2): Supports multiple listeners with multiple SSL certificates. Uses Server Name Indication (SNI) to make it work
Network Load Balancer (v2): Supports multiple listeners with multiple SSL certificates. Uses Server Name Indication (SNI) to make it work
Elastic Load Balancer – Connection Draining:
1)CLB: Connection Draining
2)Target Group: Deregistration Delay (for ALB & NLB)
Connection Draining: Time to complete “in-flight requests” while the instance is de-registering or unhealthy.
Stops sending new requests to the instance which is de-registering.
Between 1 to 3600 seconds, default is 300 seconds.
Can be disabled (set value to 0)
It is good to set to a low value if your requests are short.