Must-know Facts About AWS Elastic Load Balancing

AWS Elastic Load Balancing automatically distributes incoming application traffic across multiple Amazon EC2 instances. It helps to achieve better fault tolerance in applications by seamlessly providing the amount of load balancing capacity needed in response to incoming application traffic.


The following are important facts to consider before diving in to use AWS ELB:

1. AWS ELB is elastic. That means it can handle large requests and distribute them appropriately and efficiently to back-end EC2 instances. Since there is no upper limit to the number of instances used, any number of EC2 instances can be attached to leverage the incoming load.
   
   
2. By default, up to 10 ELBs can be created per region. If you need more than ten, you can submit a request to the AWS support team by submitting the following form:
   
   ELB Request Form
   
   
3. Supported protocols. The Amazon load balancer supports load balancing of applications using HTTP, HTTPS, TCP, and Secure Sockets Layer (SSL) protocols. You can specify protocols independently for the front-end connections (client-to-load balancer) and for the back-end connections (load balancer to back-end instance). The acceptable ports for both HTTPS/SSL and HTTP/TCP connections are 25, 80, 443, and 1024-65535.
   
   

4. Amazon Availability Zones. You can configure the load balancer to balance incoming application traffic in two ways:

   • Across multiple instances in a single Availability Zone, or
   • Across multiple instances in several same-region Availability Zones.

   When using multiple Amazon Availability Zones, be sure to maintain equal capacity distribution in each of the zones registered with the load balancer.

   For example, let’s assume there are two us-east-1a zone instances and one us-east-1b instance attached to the ELB. In this case, the ELB distributes the traffic equally between the availability zones, but not between the instances. This means that a single instance in the 1b zone gets the same number of requests that would be served by two instances in the 1a zone. That’s the behavior you want because Availability Zones are separate failure domains. Fault tolerance is assured only when the capacity is evenly spread across all zones.
   
   If you enable cross-zone load balancing, you no longer have to worry that clients caching DNS information will cause requests to be distributed unevenly. In a new development, AWS ELB now ensures that requests are distributed equally to your back-end instances, regardless of the Availability Zone in which they’re located. This advance makes it easier for you to deploy and manage your applications across multiple Availability Zones. You can enable this feature only through AWS Command Line Interface, not yet via GUI.
   
   You can find instructions on how to enable cross-zone load balancing here:
   
   Enable or Disable Cross-Zone Load Balancing for Your Load Balancer

    

5. Not designed for sudden spikes in traffic. Though the ELB is elastic, it can’t handle a sudden heavy surge in request count, nor can the ELB handle a large number of requests at the moment it’s created. It comes with a controller that monitors and manages the capacity that can be handled by load balancers. The controller gradually increases the ELB capacity based on the incoming request count.
   
   • In the case of an immediate demand, is it necessary to wait till the controller increases the ELB’s capacity? No. Simply subscribe to premium AWS technical support and submit a ticket to request pre-warming the ELB for the desired capacity. Upon request, the ELB can be configured to have a minimum scaling based on expected traffic.
     
     
   • If the ELB hasn’t been pre-warmed and the request rate increases from 500/minute to 20k/minute, the ELB will return HTTP response code 503 (Service Unavailable) to the incoming requests.

    

6. Monitoring. One interesting feature of AWS is Amazon CloudWatch, which is used for monitoring the ELB. CloudWatch graphs can be used to recognize request count patterns-per-minute at the ELB and the HTTP 5xx response count at the ELB level.
   
   • always a good idea to enable AWS CloudWatch alerts for ELB 5xx errors and request counts. You’ll then receive notifications if and when there are issues with the ELB capacity, or if there are sudden spikes in request count.
   • If the aws load balancer is created and not used for a period of time—generally for a few hours, but sometimes in as little as an hour)—the load balancer may scale down before traffic begins to reach it.

    

7. AWS ELB Timeout. The default session timeout is 60 seconds. AWS does not allow you to increase this limit, which may be a problem when needing to generate large files, such as PDFs or reports, on the EC2 back-end. That’s because the EC2 server will keep the connection idle during the generation process before it returns the response result. However, you can increase the AWS ELB timeout to meet your requirements by contacting the AWS support team.
   
   
8. Domain mapping. Each Elastic Load Balancing instance that you create will result in an automatically generated Domain Name System (DNS) name. The DNS name will typically include the name of the AWS region for which the load balancer is created. For example, if you create a load balancer named myLB in the US-East region, your load balancer may have a DNS name such as myLB-1234567890.us-east-1.elb.amazonaws.com. The ELB doesn’t have a static IP address. Instead, it has a pool of IPs that keep changing. You can’t attach a specific EIP, either, which may cause domain-mapping issues. However, you can use a CNAME record to route a subdomain to another DNS name. Most DNS providers don’t support mapping of CNAME records to the apex zone. A workaround is to migrate domains to AWS Route 53 /DnsMadeEasy, where you can map to a CNAME record. For example, you can map your domain www.example.com to an ELB end point.
   
   The following link will help you migrate DNS to Route53:
   Migrating DNS to Route53
   
   
9. SSL. You can deploy SSL certificates on ELB, which is easier than deploying on web servers such as Apache/Nginx/IIS. To deploy an SSL certificate, simply upload CRT, Bundle CRT and Private Key files and start using HTTPS. SSL encryption to the ELB provides the option to deploy the certificate on the web server level. Where higher levels of security are needed, web server deployment will encrypt the connection between the ELB and the web servers.
   
   It’s important to remember that only one SSL certificate can be supported at a time.
   
   For example, consider a name-based virtual hosting that needs ELBs to load balance requests. Each domain will have a different SSL certificate. In such cases, multiple ELBs are created and pointed to the same app servers. Certificates are uploaded to each ELB and corresponding mapping to the respective DNS is created. In the absence of an SSL connection, a single ELB can be mapped to all domains.
   
   
10. There is no stop/start option for ELB. Once created, charges apply until an ELB is deleted.
    
    Further Reading:
    
    http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/SvcIntro.html
    
    DNS Mapping:
    
    http://antti.blogging.fi/2011/07/23/root-domains-with-amazon-elastic-load-balancer/
    
    Get Started with AWS
    
    Receive AWS tips, DevOps best practices, news analysis, commentary and more. Sign up for our IT Modernization blog here and set your topic and frequency preferences. Or, download our guide on getting started with AWS, establishing a secure AWS enterprise architecture with Flux7 Landing Zones.