An ELB distributes the incoming requests from the internet/intranet to the EC2 instances registered with it. The elastic load balancer can distribute the requests to the instances in a round-robin manner. If you need more complex routing algorithms then either use the Amazon Route53 DNS service, use Nginx as a reverse proxy, or use HAProxy. Amazon ELB is designed to handle an unlimited number of concurrent requests per second with increasing loads. However, it is not designed to handle sudden spikes in the number of requests that typically occur during special promotional sales, online exams, or online trading, when you might experience sudden surges. If your use case falls into this category then you can request that the Amazon Web Service support team pre-warm the ELBs to handle the sudden load increases.

The ELB consists of two parts :

• Load balancer: Monitors and handles the requests coming in through the internet/intranet, and distributes them across the EC2 instances registered with it.
• Control service: It automatically scales the handling capacity in response to incoming traffic by adding or removing load balancers, as needed, and it also performs the health checks.

Before creating an ELB, we modify the EC2 security group created in Chapter 3,  AWS Components, Cost Models, and Application Development Environments, to allow HTTP traffic on port 80 by adding an inbound rule, as shown in the following screenshot:

Follow the steps below to create the ELB:

1. From the EC2 navigation pane, click on Load Balancers listed under Network & Security, and then on the Create Load Balancer button:

2. The first step is to select the type of load balancer we want. At this stage, for simplicity, we will create a Classic load balancer. Click on the Create button:

We name the load balancer and configure the protocols it will service:

• Load Balancer name: A name which uniquely identifies the load balancer. This name will be a part of the public DNS name of your load balancer.
• Create LB Inside: Allows you to select the VPC where this load balancer will be deployed. Since we have only one VPC, select the My Default VPC (172.31.0.0/16).
• Create an internal load balancer: A load balancer can be created to serve the internet traffic in a public subnet or for intranet traffic, that is, between your internal servers, such as between the web servers and application servers. Check this only when you want to create an internal load balancer.
• Enable advanced VPC configuration: The advanced VPC configuration option allows you to specify your own subnets. Select this option if you have created your own subnets and want to use them instead of the default subnets. This allows your load balancer to route traffic to EC2 instances in other Availability Zones.
• Listener Configuration: A listener is a process which listens for incoming requests on a specific port from the client end and relays it to an EC2 instance configured for the protocol and the port. It supports protocols both at transport layer (TCP/SSL) and application layer (HTTP/HTTPS). Our Apache Tomcat server listens on port 8080; we enter port 80 for the Load Balancer Port and 8080 for the Instance Port. The acceptable ports for both HTTPS/SSL and HTTP/TCP connections are 25, 80, 443, 465, 587, and 1024-65535. Select HTTP as the protocol both on the Load Balancer Protocol and Instance Protocol.

The protocol for the load balancer and the instance should be at the same layer for a listener configuration. For example, if your load balancer protocol is using the TCP or SSL protocol then your instance protocol can either be TCP or SSL and not HTTP or HTTPS:

3. The next step is to configure the ELB to route the incoming traffic to the subnets in which the application is running. The VPC is configured so that each unique subnet is associated with an Availability Zone. The purpose of this is to make your application resistant to failure; if an Availability Zone goes down then all the application instances in that Availability Zone will not respond and will be detected via the ELB's health check. The ELB will start routing the data to your healthy application instances running in the other Availability Zones within the same region. Since our application is deployed in the us-west-2a Availability Zone, we add that to our Selected subnets by selecting it from the Available subnets list:

4. Now we assign a security group to our ELB. We have already created the sq-EC2WebSecurity Group security group in Chapter 3, AWS Components, Cost Models, and Application Development Environments (and updated it in this section). Next, click on the Configure Security Settings button:

5. You should see the following screen. Now, click on the Next: Configure Health Check button:

6. Next, we configure the health check. ELB periodically sends requests to test the availability of the EC2 instances. These tests are called health checks. EC2 instances that are healthy at the time of the health check are marked as InService and the instances that are unhealthy at the time of the health check are marked as OutOfService. The ELB performs health checks on all registered instances, regardless of whether the instance is in a healthy or unhealthy state. However, the ELB will route requests only to InService instances. In your web application, you define a URL which the ELB can call for a health check. To reduce network traffic we suggest you have a REST endpoint or a static HTML page which returns no data, only a 200 OK HTTP response code:
   • Ping Protocol: The protocol to connect to on the EC2 instance. It can be TCP, SSL or HTTP/HTTPS. Select HTTP from the dropdown.
   • Ping Port: The port to connect to with the instance. Enter 8080, which is the default port of our Apache Tomcat server.
   • Ping Path: The HTTP/HTTPS destination for the health request. A HTTP/HTTPS GET request is issued to the instance on the ping port and the ping path. If the ELB receives any response other than 200 OK within the response timeout period, the instance is considered unhealthy.
   • Response Timeout: Time to wait when receiving a response from the health check. If the instance does not respond within the set time period it is considered unhealthy. Use the default value of 5 seconds.
   • Health Check Interval: The amount of time in-between the health checks. If you have a low value, then you will increase the network traffic, but a healthy/unhealthy EC2 instance can be detected quickly and vice versa. Use the default value of 30 seconds.
   • Unhealthy Threshold: Number of consecutive health check failures before declaring an EC2 instance unhealthy or OutOfService. An OutOfService EC2 instance will only be detected after a time period (in seconds) of HealthCheck Interval*Unhealthy Threshold. Use the default value, 2.
   • Healthy Threshold: Number of consecutive health check successes before declaring an EC2 instance healthy or InService. An InService EC2 instance will only be detected after a time period of HealthCheck Interval*Healthy Threshold seconds. Use the default value, 10:

7. Next, we add the running instances to ELB. As we are creating this ELB for an Auto Scaling group we can skip this step. The Auto Scaling group when activated will add the defined EC2 instance to the ELB on the fly:
   • Enable Cross-Zone Load Balancing: This option allows the ELB route traffic across Availability Zones.
   • Enable Connection Draining: This feature only works when it used in conjunction with auto scaling. In auto scaling, the instances are dynamically added or removed based on the defined policies. Auto scaling should not de-register an instance from the ELB when it is in the middle of processing a request. Enabling the connection draining option performs two functions: one, it does not de-register the instance immediately (if it is processing a request), instead it delays the termination by a predefined time period, and two, it does not route any new traffic to the instance. After the elapsed time period the ELB will de-register the instance and hopefully by that time the instance would have processed all the pending requests. The default time period is 300 seconds; you can change it as per your application needs:

8. Next, we add a tag to the ELB; enter the Key field as Name and the Value field as A1ElectonicsEcommerce-ELB-us-west-2. Now, click on the Review and Create button:

9. The final step is to review all the configuration details and change, if required (by clicking on the Previous button). Now, click on the Create button:

10. You should see the following message. Click on the Close button:

After the ELB has been created it will be assigned a DNS name by which you can access it over the internet. This DNS name is assigned by AWS and cannot be changed, moreover it is not a user-friendly name. You would rather use www.a1eletronics.com than a1electronicsecommerce-elb-965226090.us-west-2.elb.amazonaws.com. In a production environment, you would need to associate your custom domain name with you ELB domain name by registering a CNAME with your DNS provider.

11. Click on the Description tab and check the Status row. Initially, you might see the status as 0 of 1 instances in service:

12. Click on the Instances tab. Initially, you might see the Status as OutOfService:

Shortly thereafter, the Status will change to InService as shown:

13. At this stage, you can key in the DNS name from the Description tab into a browser, and you should see the homepage of your site (add /a1ecommerce at the end of the DNS name):

In the next section, we will create a launch configuration.