4171. AWS-Elastic Load Balancer
AWS and Load Balancer

Build high availability applications with Elastic Load Balancer.

1. Elastic Load Balancer

1.1 Load Balancer Types

  • Application Load Balancer
  • Network Load Balancer
  • Classic Load Balancer

1.2 Application Load Balancer

Application Load Balancers are best suited for load balancing of HTTP and HTTPS traffic. They operate at Layer 7 and are application-aware. They are intelligent, and you can create advanced request routing, sending specified requests to specific web servers.

1.3 Network Load Balancer

Network Load Balancers are best suited for load balancing of TCP traffic where extreme performance is required. Operating at the connection level (Layer 4), Network Load Balancer are capable of handling millions of requests per second, while maintaining ultra-low latencies. Use for extreme performance!

1.4 Classic Load Balancer

Classic Load Balancers are the legacy Elastic Load Balancers. You can load balance HTTP/HTTPS applications and use Layer 7-specific features, such as X-Forwarded and sticky sessions. You can also use strict Layer 4 load balancing for applications that rely purely on the TCP protocol.

1.5 Errors in Load Balancing

Classic Load Balancers if your application stops responding, the ELB (Classic Load Balancer) responds with a 504 error. This means that the application is having issues. This could be either at the Web Server layer or at the Database Layer. Identify where the application is failing, and scale it up or out where possible.

1.6 X-Forwarded-For

If you need the IPv4 address of your end user, look for the X-Forwarded-For header.

1.7 Summary of ELB

  • Instances monitored by ELB are reported as InService or OutofService
  • Health Checks check the instance health by talking to it.
  • Load Balances have their own DNS name. You are never given an IP address.
  • Read the ELB FAQ for Classic Load Balancers.

2. Load Balancer and Health Check

The architecture of Load Balancer and Health Check. image The flow of the http request:
1) Client(Web browser) requests the IP address of the Load Balancer from DNS.
2) DNS returns the IP address of the Load Balancer.
3) Client uses the IP address to request the web page.
4) Internet Gateway checks and forwards the request to the Load Balancer.
5) The Load Balancer finds an active web server and forwards the request.
6) The selected web server returns the requested html file.
7) Client receives and processes the html file.

The Load Balancer checks the health of each web server via the health check service.

3. Lab - Classic Load Balancer

Create two instances with showing different web pages, then create a classic load balancer.

  • Reminder: Load Balancers are not free.

3.1 Create Two EC2 Instances

Create first instance with the following bootstrap script, make it showing “This is WebServer 01” in the web page.

#!/bin/bash
yum update -y
yum install httpd -y
service httpd start
chkconfig httpd on
cd /var/www/html
echo "<html><h1>This is WebServer 01</h1></html>" > index.html

Specify the subnet/AZ to ‘us-west-1a’. image Add tag, Name=Web01. image Create second instance with the same bootstrap script, make it showing “This is WebServer 02” in the web page. Specify the subnet/AZ to ‘us-west-1c’. Add tag, Name=Web02. Now, we have two instances running in different AZs. image If we access the public id address, we will see the “This is WebServer 01” or “This is WebServer 02” respectively. image

3.2 Create Classic Load Balancer

Go to Services->EC2->Load Balancers, Create Load Balancer, select “Classic Load Balancer”. image provider name for it. image Choose the same security group with EC2 instance, eg. WebSG. image Configure health check. image Add two EC2 instances. image Keep tag empty and create. The load balancer is created, wait until the status is changed from “OutService” to “InService”. image Copy the dns name and visit it in web browser. image We will see the content. Keep refreshing the page, sometimes we hit WebServer 1 and sometime we hit WebServer 2. image Stop the first instance which is Webserver 1. image The health check will notice this and the status of web server 1 instance is changed to “OutService”. image If we refresh the page, we will only see webserver 2, as load balancer detects webserver 1 is not available, it is sending all traffic to web server 2. image

4. Lab - Application Load Balancer

Create target group and application load balancer.

Launch the two web server instances.

4.1 Create Target Group

Go to Services->EC2->Target Groups, Create target group image Select “Instances” as target type, provide the group name. image Set path, threshold, timeout and interval for health checks, next. image Select the two web server instances, click “Include as pending below”, then “Create target group”. image The target group is created. image

4.2 Create Application Load Balancer

Go to Services->EC2->Load Balancers, Create Load Balancer, select “Application Load Balancer”, provider name and select all availability zones, next. image Skip the warning, next. image Select the WebSG security group, next. image Select the existing group created in previous lab, next. image Select the two instances and click ‘Add to registered’, next. image Review, create. image ELB is created. image Go to target group, wait for a while, until the status become ‘healthy’. image Go to the load balancer, copy the dns name, visit it in the web browser. image We will see the content. Keep refreshing the page, sometimes we hit WebServer 1 and sometime we hit WebServer 2. image Why application load balancer is more intelligent than classic load balancer? Check the listeners in the load balancer, click on the listener. image You can create rules with conditions and corresponding actions. image image

5. Advanced Load Balancer

5.1 Sticky Sessions

Classic Load Balancer routes each request independently to the registered EC2 instance with the smallest load. Sticky sessions allow you to bind a user’s session to a specific EC2 instance. This ensures that all requests from the user during the session are sent to the same instance. image You can enable Sticky Sessions for Application Load Balancers as well, but the traffic will be sent at the Target Group Level.

5.2 Cross Zone load Balancing

With cross-zone load balancing, each load balancer node for your Classic Load Balancer distributes requests evenly across the registered instances in all enabled Availability Zones. If cross-zone load balancing is disabled, each load balancer node distributes requests evenly across the registered instances in its Availability Zone only. image

5.3 Path Patterns

You can create a listener with rules to forward requests based on the URL path. This is known as path-based routing. If you are running microservices, you can route traffic to multiple back-end services using path-based routing. For example, you can route general requests to one target group and requests to render images to another target group. image

5.4 Summary

  • Sticky Sessions enable your users to stick to the same EC2 instance. Can be useful if you are storing information locally to that instance.
  • Cross Zone Load Balancing enables you to load balance across multiple availability zones.
  • Path patterns allow you to direct traffic to different EC2 instances based on the URL contained in the request.

6. References