The Elastic Load Balancer or ELB is a web service that allows you to automatically distribute incoming traffic across a fleet of EC2 instances. In simpler terms, an ELB acts as a single point of contact between your clients and the EC2 instances that are servicing them. The clients query your application via the ELB; thus, you can easily add and remove the underlying EC2 instances without having to worry about any of the traffic routing or load distributions. It is all taken care of by the ELB itself!
Coupled with Auto Scaling, ELB provides you with a highly resilient and fault tolerant environment to host your applications. While the Auto Scaling service automatically removes any unhealthy EC2 instances from its group, the ELB automatically reroutes the traffic to some other healthy instance. Once a new healthy instance is launched by the Auto Scaling service, ELB will once again re-route the traffic through it and balance out the application load as well. But the work of the ELB doesn't stop there! An ELB can also be used to safeguard and secure your instances by enforcing encryption and by utilizing only HTTPS and SSL connections. Keeping these points in mind, let us look at how an ELB actually works.
Well to begin with, when you create an ELB in a particular AZ, you are actually spinning up one or more ELB nodes. Don't worry, you cannot physically see these nodes nor perform any actions on them. They are completely managed and looked after by AWS itself. This node is responsible for forwarding the incoming traffic to the healthy instances present in that particular AZ. Now here's the fun part! If you configure the ELB to work across multiple AZs and assume that one entire AZ goes down or the instances in that particular AZ become unhealthy for some reason, then the ELB will automatically route traffic to the healthy instances present in the second AZ:
How does it do the routing? The ELB, by default, is provided with a public DNS name, something similar to MyELB-123456789.region.elb.amazonaws.com. The clients send all their requests to this particular Public DNS name. The AWS DNS servers then resolve this public DNS name to the public IP addresses of the ELB nodes. Each of the nodes has one or more listeners configured on them which constantly check for any incoming connections. Listeners are nothing but processes that are configured with a combination of protocols; for example, HTTP and a port, for example, 80. The ELB node that receives the particular request from the client then routes the traffic to a healthy instance using a particular routing algorithm. If the listener was configured with an HTTP or HTTPS protocol, then the preferred choice of routing algorithm is the least outstanding requests routing algorithm.
Confused? Well don't be, as most of these things are handled internally by the ELB itself. You don't have to configure the ELB nodes nor the routing tables. All you need to do is set up the listeners in your ELB and point all client requests to the ELB's Public DNS name, and that's it! Keeping these basics in mind, let us go ahead and create our very first ELB!
Creating and setting up an ELB is a fairly easy and straightforward process provided you have planned and defined your Elastic Load Balancer's role from the start. The current version of ELB supports HTTP, HTTPS, and TCP, as well as SSL connection protocols; however, for the sake of simplicity, we will be creating a simple ELB for balancing HTTP traffic only. I'll be using the same VPC environment that we have been developing since Chapter 5 , Building Your Own Private Clouds Using Amazon VPC; however, you can easily substitute your own infrastructure in this place as well.
To access the ELB Dashboard, you will have to first access the EC2ManagementConsole. Next, from the navigation pane, select the LoadBalancers option, as shown in the following screenshot. This will bring up the ELB Dashboard as well, using which you can create and associate your ELBs. An important point to note here is that although ELBs are created using this particular portal, you can, however, use them for both your EC2 and VPC environments. There is no separate portal for creating ELBs in a VPC environment:
Since this is our first ELB, let us go ahead and select the Create Load Balancer option. This will bring up a seven-step wizard using which you can create and customize your ELBs.
To begin with, provide a suitable name for your ELB in the Load Balancer name field. In this case, I have opted to stick to my naming convention and name the ELB US-WEST-PROD-LB-01. Next up, select the VPC option in which you wish to deploy your ELB. Again, I have gone ahead and selected the US-WEST-PROD-1 (192.168.0.0/16) VPC that we created in Chapter 5, Building Your Own Private Clouds Using Amazon VPC. You can alternatively select your own VPC environment or even select a standalone EC2 environment if it is available. Do not check the Create an internal load balancer option as in this scenario, we are creating an Internet-facing ELB for our Web Server instances.
There are two types of ELB that you can create and use based on your requirements. The first is an Internet-facing Load Balancer, which is used to balance out client requests that are inbound from the Internet. Ideally, such Internet-facing load balancers connect to the public subnets of a VPC. Similarly, you also have something called as Internal Load Balancers that connect and route traffic to your private subnets. You can use a combination of these depending on your application's requirements and architecture; for example, you can have one Internet-facing ELB as your application's main entry point and an internal ELB to route traffic between your public and private subnets; however, for simplicity, let us create an Internet-facing ELB for now.
With these basic settings done, we now provide our ELB's Listeners. A Listener is made up of two parts: a protocol and port number for your frontend connection (between your client and the ELB), and a protocol and a port number for a backend connection (between the ELB and the EC2 instances).
In the Listener Configuration section, select HTTP from the Load Balancer Protocol drop-down list and provide the port number 80 in the Load Balancer Port field, as shown in the following screenshot. Provide the same protocol and port number for the Instance Protocol and Instance Port fields as well:
What does this mean? Well, this listener is now configured to listen on the ELB's external port (Load Balancer Port) 80 for any client's requests. Once it receives the requests, it will then forward it out to the underlying EC2 instances using the Instance Port, which in this case is port 80 as well. There is no rule of thumb as such that both the port values must match; in fact, it is actually good practice to keep them different. Although your ELB can listen on port 80 for any client's requests, it can use any ports within the range of 1-65,535 for forwarding the request to the instances. You can optionally add additional listeners to your ELB such as a listener for the HTTPS protocol running on port 443 as well; however, that is something that I will leave you do to later.
The final configuration item left in step 1 is where you get to select the Subnets option to be associated with your new Load Balancer. In my case, I have gone ahead and created a set of subnets each in two different AZs so as to mimic a high-availability scenario:
Select any particular subnets and add them to your ELB by selecting the adjoining + sign. In my case, I have selected two subnets, both belonging to the web server instances; however, both present in two different AZs.
Once your subnets are added, click on Next: Assign Security Groups to continue over to step 2.
Step 2 is where we get to assign our ELB with a security group. Now, here's the catch: You will not be prompted for a Security Group if you are using an EC2-Classic environment for your ELB. This Security Group is only necessary for VPC environments and will basically allow the port you designated for inbound traffic to pass through:
In this case, I have created a new dedicated Security Group for the ELB. Provide a suitable
Security group name as well as a Description, as shown in the preceding screenshot. The new security group already contains a rule that allows traffic to the port that you configured your Load Balancer to use; in my case it's port 80. Leave the rule at its default value and click on Next: Configure Security Settings to continue.
This is an optional page that basically allows you to secure your ELB by using either the HTTPS or the SSL protocol for your frontend connection. But since we have opted for a simple HTTP-based ELB, we can ignore this page for now. Click on Next: Configure Health Check to proceed to the next step.
Health checks are a very important part of an ELB's configuration and hence you have to be extra cautious when setting them up. What are health checks? To put it in simple terms, these are basic tests that the ELB conducts to ensure that your underlying EC2 instances are healthy and running optimally. These tests include simple pings, attempted connections, or even some send requests. If the ELB senses either of the EC2 instances in an unhealthy state, it immediately changes its Health Check Status to OutOfService. Once the instance is marked as OutOfService, the ELB no longer routes any traffic to it. The ELB will only start sending traffic back to the instance only if its Health Check State changes to InService again.
To configure the health checks for your ELB, fill in the following information as described here:
- Ping protocol: This field indicates which protocol the ELB should use to connect to your EC2 instances. You can use the TCP, HTTP, HTTPS, or the SSL options; however, for simplicity, I have selected the HTTP protocol here.
- Ping port: This field is used to indicate the port which the ELB should use to connect to the instance. You can supply any port value from the range 1 to 65,535; however, since we are using the HTTP protocol, I have opted to stick with the default value of port
80. This port value is really essential as the ELB will periodically ping the EC2 instances on this port number. If any instance does not reply in a timely fashion, then that instance will be deemed unhealthy by the ELB. - Ping path: This value is usually used for the HTTP and HTTPS protocols. The ELB sends a simple
GETrequest to the EC2 instances based on the Ping Port and Ping Path. If the ELB receives a response other than an OK, then that particular instance is deemed to be unhealthy by the ELB and it will no longer route any traffic to it. Ping paths generally are set with a forward slash, /, which indicates the default home page of a web server. However, you can also use a/index.htmlor a/default.htmlvalue as you see fit. In my case, I have provided the/index.phpvalue as my dummy web application is actually a PHP app.
Besides the ping checks, there are also a few advanced configuration details that you can configure based on your application's health check needs:
- Response time: The Response Time is the time the ELB has to wait in order to receive a response. The default value is 5 seconds with a maximum value up to 60 seconds. Let's take a look at the following screenshot:
- Health Check Interval: This field indicates the amount of time (in seconds) the ELB waits between health checks of an individual EC2 instance. The default value is 30 seconds; however, you can specify a maximum value of 300 seconds as well.
- Unhealthy Threshold: This field indicates the number of consecutive failed health checks an ELB must wait before declaring an instance unhealthy. The default value is 2 with a maximum threshold value of 10.
- Healthy Threshold: This field indicates the number of consecutive successful health checks an ELB must wait before declaring an instance healthy. The default value is 2 with a maximum threshold value of 10.
Once you have provided your values, go ahead and select the Next: Add EC2 Instances option.
In this section of the wizard, you can select any running instance from your Subnets to be added and registered with the ELB. But since we are setting this particular ELB for use with Auto Scaling, we will leave this section for now. Click on Next: Add Tags to proceed with the wizard.
We already know the importance of tagging our AWS resources, so go ahead and provide a suitable tag for categorizing and identifying your ELB. Note that you can always add/edit and remove tags at a later time as well using the ELB Dashboard. With the tags all set up, click on Review and Create.
The final step of our ELB creation wizard is where we simply review our ELB's settings, including the Health Checks, EC2 instances, tags, and so on. Once reviewed, click on Create to begin your ELB's creation and configuration.
The ELB takes a few seconds to get created, but once it's ready, you can view and manage it just like any other AWS resource using the ELB dashboard, as shown in the following screenshot:
Select the newly created ELB and view its details in the Description tab. Make a note of the ELB's public DNS Name as well. You can optionally even view the Status as well as the ELBScheme (whether Internet-facing or internal) using the Description tab. You can also view the ELB's Health Checks as well as the Listeners configured with your ELB.
Before we proceed with the next section of this chapter, here are a few important pointers to keep in mind when working with ELB. Firstly, the configurations that we performed on our ELB are all very basic and will help you to get through the basics; however, ELB also provides us with additional advanced configuration options such as Cross-Zone Load Balancing, Proxy Protocols, Sticky Sessions, and so on, which can all be configured using the ELB dashboard. To know more about these advanced settings, refer to http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-configure-load-balancer.html. Second important thing worth mentioning is the ELB's costs. Although it is free (Terms and Conditions apply) to use under the Free Tier eligibility, ELBs are charged approximately $0.025 per hour used. There is a nominal charge on the data transferring as well, which is approximately $0.008 per GB of data processed.
With these points in mind and our ELB all prepped, let us go ahead and get started with the fun part of Auto Scaling!