Getting started with ELB
ELB: practical usage
Load Balancing refers to distributing workloads across multiple computing resources in order to avoid overloading some nodes while leaving others underused. When properly configured, load balancing can greatly increase an infrastructure's availability and performance, optimize throughput and response time, and generally improve the system effectiveness.
AWS has a purpose-build load balancing service called Elastic Load Balancing (ELB). Since the effective use of load balancers is so important even to many smaller deployments, instructor David Clinton crafted this introductory course, covering all the main concepts and practical application of ELB.
Who should take this course
As this is a beginner to intermediate course, you should be able to grasp all the core concepts with just about any background level. Nevertheless you may want to take our introductory EC2 and VPC courses first. Also, our Introduction to AWS might be another good, quick tutorial if you haven't yet seen that.
As a follow up to this course, check out our ELB questions set, and our advanced course How to Architect with a Design for Failure Approach, where you'll get the chance to see ELB in action providing high availability and fault tolerance in a cloud architecture.
If you have thoughts or suggestions for this course, please contact Cloud Academy at firstname.lastname@example.org.
In this video, we're going to configure and launch an ELB for the most common balancing task, balancing Internet-facing EC2 instances. You access the Elastic Load Balancing service through EC2. First though, for the purposes of this video, we've already created two instances called Instance 2A and Instance 2B on which we've installed an Apache web server, and Index.html files to distinguish one from the other. Now, let's click on Load Balancers, and let's create a new Load Balancer, we'll call it New Balancer.
We'll create it in the default VPC, it's very important that you specify the right VPC or classic EC2 environment, because it has to live in the same network as the instances you'd like it to balance. We will instruct this load balancer to handle any incoming traffic on HTTP port 80, and send it to the instance protocol HTTP on instance port 80. In other words, we'll take any incoming HTTP traffic from the internet using port 80, and redirect them between the instances using their HTTP protocols on port 80.
Let's continue. We have to configure a health check. As we've discussed in a previous video, the load balancer will not send traffic from the internet to an instance unless it's comfortable that the instance is really up and running. We'll leave the default values, though. It will expect a response within 5 seconds, and it will send a new health check every 30 seconds. An unhealthy threshold, meaning two pings with no healthy response we'll set at 2, and the healthy threshold that is we'll expect to get healthy responses 10 times.
These are the default values, they're good for us right now. Let's continue. Select subnets, now this is very important. You must create your Load Balancer in the same geographic region as your instances. But within that region, you also have to be able to direct traffic to the appropriate availability zone. Therefore, we'll select subnets in all three availability zones within this region. Therefore, even if we have instances in Zone 1A, Zone 1B, or Zone 1C, the traffic coming from the internet will be redirected to instances in each of those zones.
We'll assign a Security Group, let's create a new security group that will fit our needs. We'll take HTTP and allow it to come in through port 80 from anywhere. If we had a more complex web server which was serving other protocols, perhaps using other ports, we might have to add other rules. But this is good enough for the web server that we've got running. Click on continue.
Now, we have to add instances to the Load Balancer. There are only two instances currently in this region, we'll click here to select both of them. One, we've tagged as Instance 2A, and one we've tagged as Instance 2B. This will be important to remember a little later. We'll scroll down. We have, by the way, enabled Cross-Zone Load Balancing to allow load balancing between instances on multiple zones. And we've allowed also-, enabled also Connection Draining. Let's continue.
Let's give a key value or key and a value to this load balancer. Let's say it's name will be balancer2. Now, the name could be anything but this will help us identify this balancer from a list of balancers, or sometimes it'll help us identify output in logs. Because it's likely this tag will be included in any logged events in sometimes extremely long and difficult to read log files. Let's continue.
We can review our configuration, we're happy with it as it is. Let's create. We've successfully created a balancer. It may, of course, take a few minutes for the load balancing to actually begin to work.
But here back in the load balancer dashboard, we see that the DNS name for this balancer is newbalancer-1985140424 etc. This, we should copy. And once the balancer's properly up and running, we can simply paste it into the URL box of a browser, and we should be able to access the Index.html file on either of the two instances that we have running. So, let's copy that, and we'll get back to that later.
Meantime, however, let's take a little look at what the dashboard makes available to us. There's-, right now, tells us that the are-, the basic configuration. At this point, the status is zero of two Instances in Service because the balancer isn't up and running just yet. The port configuration is 80, that is, any traffic coming in from the internet on port 80 will be redirected to port 80 on the instances. Let's now click on instances, they are each listed right now as Out of Service. Again, it's still very early.
It's only been a minute or two since we created the load balancer. That will change eventually to In-service; well, at least we certainly hope. And we see that availability zones, there are three availability zones in which instances could be balanced.
Right now, there are only two instances in 1B-, Availability Zone 1B. Because that happens to be where we created our two instances. Let's check Health Check, and this displays for us our Health Check rules. We could Edit Health Check, to change those rules, but that's fine.
Let's, once again, check Instances, now they're In-service. Let's go back to description, and we see two of two instances In-service. So, is seems we should now be able to browse to the DNS name of our balancer, and access the Index.html files in our two instances.
Let's take a look. Let's paste the name of this balancer, and we see we have accessed Instance 2A. Let's click on reload, then we get 2A again, and this time we got 2B.
So randomly, the load balancer is sometimes sending incoming HTML traffic or HTTP traffic to Instance 2A, where we created the HTML file called "Welcome to-", or which contains the text "Welcome to Instance 2A." And sometimes, it sends us to Instance 2B, so the load balancer is obviously up and running, and working properly.
About the Author
David taught high school for twenty years, worked as a Linux system administrator for five years, and has been writing since he could hold a crayon between his fingers. His childhood bedroom wall has since been repainted.
Having worked directly with all kinds of technology, David derives great pleasure from completing projects that draw on as many tools from his toolkit as possible.
Besides being a Linux system administrator with a strong focus on virtualization and security tools, David writes technical documentation and user guides, and creates technology training videos.
His favorite technology tool is the one that should be just about ready for release tomorrow. Or Thursday.