Load Balancing on AWS : Part X: Configuring ELB using AWS Console

Step 1: Creating Load Balancer


Go to AWS Management Console ,> Select the AWS Region, > Select EC2 Tab and click on Load balancers to create a new load balancer . 
Notes : By Default if no AWS Region is selected it will create the Elastic Load Balancer in USA-East
Currently, the client's quota of LoadBalancers is limited to ten per Region. This can be increased by filling the following form:  http://aws.amazon.com/contact-us/elb-request/

Step 2: Defining the Load Balancer 

1. Assign a unique name to the new load balancer so that you can identify it from other load balancers you might create in future.
2. Create LB inside will list "EC2" and your "VPC Names" created in the region in this account. 
3. By selecting EC2 you are creating the Elastic Load Balancer in Public cloud of AWS inside the Region
4. By selecting any "VPC Name" you will creating the Load Balancer inside the Virtual Private Cloud of AWS inside the region
5. By default, AWS would have configured your load balancer with a standard web server on port 80 which shows on the Screen
6. Configure ports and protocols( HTTPS , TCP , SSL) for your Elastic load balancer. 

Note:Traffic from your clients can be routed from any Elastic load balancer port to any port on your EC2 instances.

Step 3: Configuring the Health Checks



Elastic load balancer will automatically perform health checks on the Amazon EC2 instances attached to it and only route traffic to EC2 instances that pass the health check. If an instance fails the health check, it is automatically removed from the load balancer. Customize the health check to meet your specific use cases .


Ping Protocol : The protocol is either TCP, HTTP, HTTPS, or SSL. The range of valid ports is one (1) through 65535. 


TCP is one of the Health Check mode, specified as a "TCP" in drop down: port pair, for example "TCP:6000". In this case a health check simply attempts to open a TCP connection to the EC2 instance on the specified port. Failure to connect within the configured timeout is considered unhealthy.


For HTTP or HTTPS protocol, the situation is different.You have to include a ping path. For example "HTTP:80/health/us/check". In this case, a HTTP GET request is issued to the instance on the given port and path. Any answer other than "200 OK" within the timeout period is considered unhealthy. 
The total length of the HTTP ping target needs to be 1024 16-bit Unicode characters or less.


Response timeout : Specifies the time in seconds, during which no response received means a failed health probe. The value that can be configured should be between 2 sec - 60 sec. Giving bigger values will result in error message. Also this value must be less than the Health Check Interval value. (if the Response timeout is greater than Health Check interval , then more health check requests will be sent to the EC2 instance and overall will cause instability in the infrastructure. Amazon ELB proactively restricts this configuration with an error message) 

Unhealthy Threshold : Specifies the number of consecutive health check failures before declaring an EC2 instance unhealthy.The value that can be configured should be between 2 -10. 


Healthy Threshold : Specifies the number of consecutive health check success before declaring an EC2 instance unhealthy.The value that can be configured should be between 2 -10. 

Why extra care should be taken while configuring health Checks in AWS infrastructure ?


Case 1: During heavy traffic in websites
Configuring a lesser unhealthy threshold value with aggressive response time out + Health Check interval , will mark EC2 instance unhealthy quickly and will stop sending requests. This will add burden on other EC2 instances under ELB quickly and there are chances they will also fail soon.



Case 2: During heavy traffic with Amazon Auto Scaling
Configuring a lesser unhealthy threshold value with aggressive response time out + Health Check interval , will mark EC2 instance unhealthy quickly and will stop sending requests. In addition , a signal will be sent to Amazon Auto Scaling to restart this EC2 instance since it is unhealthy. Even though you had requested Amazon Auto Scaling to maintain minimum of 4 instances at any time, you will find some EC2 instances getting frequently restarted within this minimum. This will add burden on other EC2 instances quickly and there are chances they will also fail soon during heavy traffic.



Case 3: During heavy traffic with Amazon Auto Scaling , EC2 with Cache
Configuring a  lesser unhealthy threshold value with aggressive response time out + Health Check interval , will mark EC2 instance unhealthy quickly and will stop sending requests. In addition , will send a signal to Amazon Auto Scaling to relaunch this EC2 instance. Even though you had requested Amazon Auto Scaling to maintain minimum of 4 instances , you will find some EC2 instances getting frequently restarted. If you maintain Cache in these EC2 instances (Web servers) like Memcached, W3TotalCache etc to offload the traffic from DB  servers and SOlr Servers , such frequent EC2 web server restarts will not give enough time for cache warming. This will add burden to the EC2 instances in web layer, DB servers etc and overall bring down the entire infrastructure.






Step 4: Add EC2 instance to the Load balancer

Attach EC2 instances to Elastic Load Balancer in this step. This screen will list 
all your running EC2 Instances that are not already behind another load balancer or part of an auto-scaling capacity group. Check the boxes in the Select column to add those instances to this load balancer. It is best practice to attach atleast 2 or more EC2 instances from 2 or more Availability Zones in the region. This provides High availability in the web/App layer. ELB seamlessly Load balances the EC2 instances deployed across Multiple AZ's.

Step 5: Review the ELB configuration

Please review your ELB configurations on this Screen. By Clicking "Create" you will launch your load balancer in the AWS

Step 6: Successful creation

On Successful creation, you can view load balancer and its parameters in management console

LoadBalancer DNS names vary depending on the Region they're created in. For LoadBalancers created in the United States, the DNS name ends with:
• us-east-1.elb.amazonaws.com (for the US Standard Region)
• us-west-1.elb.amazonaws.com (for the Northern California Region)




Other Load Balancing Articles :


Monitoring ELB with Amazon CloudWatch
Dissecting Amazon ELB: 18 things you should know
Configuring Amazon ELB using AWS Management Console
Amazon ELB Implementation Architectures
Amazon Elastic Load balancing benefits
Why do we need Elastic Load Balancing ?
Offloading SSL in Amazon ELB