3. [SAA/DVA] Classic Load Balancer (CLB)
First, start with our classic load balancer. And these may not be as prominent in the exam, but they may still be mentioned, and they’re still very valid load balancers. So they support TCPor traffic as well as HTTP and HTTPS. TCP is referred to as layer four, HTTP as layer five, and GCP as layer seven. I’m not going to get too deep into what these layers mean, but just know that TCP is layer four and the other two are layer seven. So the health checks are either TCP-based or HTTP-based. And what you will get out of a load balancer is a classic load balancer with a fixed host name, and we’ll see this in the hands-on as well. So what we’ll set up in this lecture is a client talking to our classic load balancer on an HTTP listener. And internally, that CLB will be redirecting traffic into our easy-to-use instances. So let’s take a look at how we can do this in the console.
4. [SAA/DVA] Classic Load Balancer (CLB) – Hands On
Okay, so in this lecture, we’re going to create a classic load balancer. But to do so, let’s first launch an instance very quickly, just the way we’ve done it before. We’ll go with Amazon Annex T and Micro, and we’ll set it up with the same web server as before. So if we go in here, copy the entire script and paste it entirely, then add storage, everything looks good at tags. Security Group, we’ll use the previous security group for Launch Wizard One, and then click Review and Launch and Launch. We’re going to create our EC2 instance, and this EC2 instance right here is going to have a web server. So I’ll keep this in here while it starts, and then I’ll go into load balancer on the left side. So I am in the load balancer console, and I will create my first load balancer.
So I have four options available to me. There is an application load balancer, a network load balancer, a gateway load balancer, and a classic load balancer. So as you can see, the Classic is sort of deprecated compared to its previous generation, so we can still create it, but it’s discouraged by alias to use it. We’ll see ALB and NLB in the next lectures, and Gateway Load Balancer is out of scope for now. So let’s click and create a classic load balancer. So I call it my demo CLB. We’ll create it inside of my default VPC, and we can make this an internal load balancer if we wanted to keep it private, but we want to access it from our computer.
So we will leave this unticked, and we will also leave the advanced VPC configuration unticked. In terms of listener configuration, we want our ClassicLoad Balancer to accept HTTP traffic. So that means that Http on port 80 is what we want to allow, and then it’s going to go to the EC2 instances on port 80 for the protocol Http as well. So this is great. Next, for Security Groups, we’re going to create a new Security Group for our Classic Load Balancer, and I will call it my first Load Balancer SG, and then we can just leave the description as is, so we’re going to have to allow HTTP traffic from anywhere. So HTTP on port 80 from anywhere as long as IPV4 is used. And we can do anywhere to have IPV 4 and IPV 6 as well, which are not supported by the classical balancer.
Therefore, you don’t see IPV6 in here. Okay, so we’re good to go. So now we can configure the security settings, and we get a warning because we’re not using HTTPS or SSL, but this is fine because we don’t want to encrypt traffic in flights right now in this sector. Next, for health checks, we must consider what will be checked on our instance. As you can see, the health check will communicate with our two EC instances via the http protocol, and the path will be an HTML index. So let’s ensure that it works. So, let’s look at the public IPV 4. I’ll copy the IP address and open it; as you can see, we get the hello world, but what if we add the path so slash index of HTML onto here? If you press Enter, we get the same URL. So this ping path would work. The slash-ping path would work as well. So I like to just have a slash. But if we do something like slash foobar, for example, for something that doesn’t exist, we do something like slash foobar and press Enter. We’re going to get an error, and this error would make our instance unhealthy if we kept the health check as FUBAR. So we want to stick to a path that we know works, like a slash. And if we have just a slash, then we get just the URL, and we get HelloWorld back from our EC2 instance.
So this is perfect. In terms of the health check, we need to configure a timeout, so five seconds is great. how often we want to do the health check. So let’s keep it at 3 seconds. how many times the instance needs to be unhealthy. So let’s do five, then, for it to be happy. how many times the unhealthy count should be before the instance should be unhealthy. So two is great. And how many times should the health check be correct? Let’s keep it to a low number, like three, until the instance is deemed healthy. So, if three health checks pass, the instance is considered healthy. And if two health checks in a row don’t pass, then it’s unhealthy. Okay, now we’ll add two simple instances. So I’m going to add this EC-2 instance, and then I will add tags create and create. As a result, our first classic load balancer is born. And actually, the health check timeout must be less than the interval. So let’s review and resolve. So the response timeout must be less than the interval. So let’s keep the response time to 5 seconds, 4 seconds, and then create it again, and we’re good to go.
So my classic load balancer was successfully created. So here it is, our classic load balancer, and we need to wait for it to come up. So let me pause and get back to you when it is up and running. So if we check the video right now, as you can see, the instance is out of service, and if you go over the info, it says instance registration is still in progress. So if you see “out of service” for your instance, please wait a little bit before asking in the Q and A. Then it gets to the service. So that means that our classical balancer is working. Now, if it doesn’t, if you don’t get inducted in, say, a minute or two, then I will show you what may be going wrong. So right now, let’s assume that everything is working. Please don’t ask a question in the Q and A just yet. So we’re going to open the URL DNS, name our classical balancer, and as you can see, we get hello,weld from the EC2 instance, the same as if we had used the public facing IP. So that means that the classic load balancer is working. But what if it didn’t work? What if we had an instance that was unhealthy? So maybe your instance is unhealthy because of security groups.
So if we go into the security groups right now and go to Launch Wizard One, let’s say we want to remove these HTTP rules right here, so I’m going to delete these HTTP rules and save the rule. This will make it so that, well, this instance right here is not accessible from the public Internet, of course, but also from the private ALS Internet because, well, there’s no port 80 available on the security group. So that means that, for example, in this example, my instance should be marked out of service very quickly. As you can see, it is currently unavailable. So this could be one reason why the instance is out of service. Another reason it could be down is that the hello world script does not work and the bootstrap script did not run properly. So these are the two reasons why this would not work. Okay, so let’s go back into our instance. So we saved the rule when we had the inbound rule set to be http onport ad from anywhere on IPV 4. So when we had this, we could access our instance both from the public IP and from the classical load balancer, which is not working right now because I need to wait for my instance to go back into service, which should take about 15 seconds. So now it’s back in service. This works after I refresh it. Okay, so the problem is that we can access our two instances directly and also through the load balancer, but we would like to tighten the security.
So this is where we can show something really cool with security groups. We can change the inbound rule to only allow HTTP on port 80, but not from anywhere; instead, we want to allow it from a security group of the load balancer. So this is my first load balancer, so we are allowing any traffic from the security group of the load balancer into the security group of the EC two instances. So allow only traffic from the ELB. And the reason we do so is that we want the ELB to access our instance. Okay? But we don’t want our users to directly access our instances. As you can see, Now if I refresh this page, I get an endless running cycle. And in here, if I refresh while it’s still working, we can only now access our ECTwo instances via the load balancer. So we have enhanced the security, and that is a very, very common pattern in AWS. So finally, let’s show the whole power of load balancing by having more instances. So I can right-click and say “Launch an instance from this template.” For example, oops, right-click and say “Launch instances,” and then use the one that appears. So we’ll use TWO micro and example details, and we’re good to go. We can also provide the user data, just like we did before. So let’s provide it and add storage. security tags group review and launch. So we will pass on the launch. Wizard one security group. Launch. And yes, we have the keypad, so that’s one of them. And we can do another one like this. So we’ll start an instance again, this time selecting T two micro. I’m trying to go a little bit faster. Pasting the user data into storage is good. Security group. We’re going to do the launch. Wizard One review. And launch. And launch. Okay, so the effect of this is that now we have three easy-to-launch instances that are launched, and they will all have their own Leo Hello World message. So what I want to do is add these instances to my Secret Balancer class. So I go to my classical balancer, I edit my instances, and now I add these two new instances. So now we have three instances registered on my classical balancer. And as you can see, two are out of service because they’re still booting up. So what’s going to happen is that we need the user data script on the easy two instances to complete successfully. And then, once the EC2 instances are up, they should be put into service by our load balancer.
And again, if you see out of service, this is maybe because you don’t have the user data script running properly or some security group issues, but if you see some in service and some out of service and they have the same security groups, then it’s not a security group issue. Okay? So let’s just wait a little longer for this to finish. Okay, so my three instances are in service, and they’re spread across two availability zones. As a result, US East 2A and US East 2C And so now if I go back to my load balancer and refresh the page, every time I refresh, I’m going to get a new instance replying to me, and therefore we get a new Hello World message from a different private IP. So this shows that every time I refresh the browser, my request goes to a different EC2 instance. And that means that my load balancer is indeed load balancing. My request. So this is pretty cool. And that concludes the demo for the load balancers. So that’s it for this demo. Please delete the classic load balancer. We will not be using it, but keep the EC2 instances running during this section, as we’ll be creating new load balancers and using them as well. So that’s it.
5. [SAA/DVA] Application Load Balancer (ALB)
Let’s move on to the second type of load balancer we’ll look at: the application load balancer. So it’s a layer 7 load balancer. So that means HTTP, and it allows you to route multiple HTTP applications across machines. And these machines are going to be grouped into something called a target group, and it will make a lot of sense once we get our hands on them. It enables you, for example, to load balance multiple applications on the same ECU. So, as we’ll see, using containers and ECS has support for HTTP/2 and Web Sockets, as well as redirection. So if you wanted to redirect traffic from HTTP to HTTPS automatically, it could be done at the load balancer level. It also supports route routing. So there is routing based on different target groups. For example, you can route based on the target path of your URL. For example, example users, example posts, and slash posts are different routes in your URL, different paths. And so you can redirect these two things to different target groups. We’ll see what that means in a second. You can also do routing based on the host name in the URL.
So if your load balancer is accessed using one example or another, it could be routed to different target groups. And you could also be routing based on the query strings and headers. So for example, if Commuters and ID equal one, two, and three, and order equals False could be routed to a different target group. So ALB, which is short for application load balancers, They’re great when you have micro services and container-based applications. So, once we’ve learned what Docker is, Amazon ECS ALB will be the go-to load balancers because they have port mapping features that allow you to redirect to a dynamic port on the ECS instance, and more on that in the ECS section. And in comparison, if we wanted to have multiple applications behind a load balancer, we would have to have multiple classic load balancers. We need to actually have one per application, whereas with load balancers, we’re able to have one application load balancer in front of many applications.
So maybe a graph will help. So we have our public-facing external application load balancer, and behind it we have our first target group made of EC, two instances, and this one will be routing for the route slash user. And we have a second target group made up of two instances of EC again, and this one is going to be our search application, and this is going to be a health check as well, and it’s going to be routed through the rules for the search route. So, as you can see here, we have two independent microservices that do different things. The first one is the user application, and the second one is a search application. But they’re behind the same application of the answer, which knows how to intelligently route to these target groups based on the route that is being used in the URL. So the target groups, what are they?
The first is that they are simple to create and can be managed by an auto-scaling group, as we will see shortly. It could be ECS tasks, and we’ll see this in the ECS section; it could be lambda functions, and this is something that’s not very known. So application load balancers can be in front of lambda functions, and we’ll see what lambda functions are in the future section, but they’re the base of everything called serverless and AWS. Finally, they can have public IP addresses but must have private IP addresses. So ALB can route to multiple target groups, and the health checks are going to be done at the target group level. So let’s take another example where we have an ALB and we have two target groups. The first one is based on AWS with two easy instances, and the second one is going to have private servers on premises. So in our own data center So, in order for the target group to exist, we must include our servers’ private IP addresses in the target group in order for them to be registered. And now say we have an application that is serving its request through the ALB, and what we want is to send to the first target group all the mobile-based traffic and to the second target group all the desktop-based traffic. For this, we can use an example query string or parameters for routing.
So if in the URL that the clients are trying to use there is a question mark, “platform equals mobile,” we can write a rule in the ALB redirection rules, the routing rules, to redirect to the first target group. And if you have a question mark next to platform equals desktop, so this is a query string or a parameter, then we can say to redirect to the target group number two. I don’t know why you would do this, but this is just an example I’m providing you. Okay, so something good to know before we get into the weeds on the first one is that you also get a fixed host name with your application and balancers. Just like the classic one, the application servers don’t see the IP of the client directly. The true IP of the client is going to be inserted instead in a header called “X forwarded 4.” As a result, you can also obtain the port by using a forwarded port and the protocol by using a forwarded protocol.
And so what that means is that our client’s IP, which is 1234-5678, is directly talking to our load balancer, which performs something called connection termination. And when your load balancer talks to your EC2 instance, it’s going to use the load balancer’s private IP, which is a public IP. And so for the EC2 instance to know the client IP, it will have to look at these extra headers in your HTTP request, which are called X-44, Port, and Proto. All right, that’s it. Now let’s go hands-on and create our first application load balancer.
6. [SAA/DVA] Application Load Balancer (ALB) – Hands On
Okay, so now let’s practise using application balancers. For this, I will create a new type of application balancer that is for HTTP and HTTPS traffic. So in terms of name, I’ll call it Demo ALB. It’s going to be internet-facing on IPV four. The listener is for the HTTP protocol, so this is perfect. And for the AZ, I’m going to want to go into all three AZs in my VPC. Okay, we’re good to go. We were not going to use a global accelerator for this. We’ll click on Configure Security Settings, configure Security Groups, and we’ll use the default My First Lob Balancer SG Security group we have already created from before. Then it will configure the routing. We’re going to create a new target group, and I’ll call it my First Target Group. It’s going to be instance-based to redirect the traffic on port 80 of whatever instances are in the target group. The protocol version is HTTP 1.
Okay, and the protocol is for the health check to be HTTP as well on the path slash, just like the one we had for the classic club balancer in terms of a healthy threshold, which we can set to three and healthy to two, the timeout to four, and the interval to five to match the same settings as before. and the success code is 200. Okay, next, we will register targets. And I will register two targets in this example, not three. I will show you why in a second. So I registered two targets for my first target group. Click on Next, review everything that looks good, and create our ALB. So now let’s go into the console and wait for the ALB to be provisioned. Okay, so my ALB is now provisioned, and I can go to my DNS name, open it, and then I get Hello World from the IP. And if I refresh again, I get a different Hello World from different ECU instances. So my ALB is working as expected, just like the CLB did. But because this is an application balancer, we get some added benefits. And so to prove this to you, I’m going to go into target groups and create a second target group. So we have my first target group.
I’m going to create a target group based on instances, and I’ll call it my second target group. And then we have this VPC, which is perfect, where you have HTTP 1. Scrolling down, the health check looks the same as before. As a result, LP threshold three, onLt timeout four, and interval five. Here we go. And click on “next.” And then I can register; I can’t remember which one it is, but there is one missing instance, the one that is not. It doesn’t really matter which one you choose, but anyway, I will just add one instance for the sake of this exercise. And I’ll include a spending budget below that is a target for my target group. Create the target group, and now we have a second target group. So the cool thing is that if we go back into our ALB now, we can have multiple listeners redirect to multiple target groups. So right now we have one listener report that 80 is forwarding to my first target group. But we can view and edit the rules of this listener to start leveraging other target groups. So I can add a rule in here and say, “Okay, if the path is, for example, tests, then you should forward your response to my second target group.”
And the idea behind this is that, okay, now if we save this, well, we have two rules, and the first one that’s going to be evaluated is the path, and it goes to my second target group. If it matches F by default, you should route to my first target group, and we can insert manuals. For example, we can say if the path is slash constant, then return a fixed response, which is maybe 404, a constant error response, or whatever you want to think of, and again save this. And now we have different rules for our load balancer. So you can create it, but you can see how we are way more powerful than the classic load balancer. And we can do routing based on path, host header, HTTP header, query strings, source IP, and so on. So you can get very creative with these load balancers. So let’s give it a shot; let’s see how it goes. So we go to the demo ALB, and we take the DNS, which is right here and is already open here. So this works right now, and we’re going to get two instances. If I do slash constant, I’m going to get the constant-hair response directly sent by my load balancer, and if I go to slash test, well, it’s not going to work. I’m going to get a not found because my EC2 instance is not configured to respond to the slash test type of query.
But this query is actually being redirected to my second target group, which sort of proves the point I was trying to make. So to finish this, let’s go and clean it up. So for the listeners, I can just remove some rules that I’ve created. So these two will be removed; I will delete them; then, back into my target groups, I will delete my second target group, and in my first target group, I’m going to just register one more target. So I’ll register targets and try not to remember which one it is. So I’ll add those three, and then okay, this one is being added. So that’s perfect. Click on “register pending targets” and here we go. As you can see, this is the target group now, which will perform the health checks and make sure that all the instances are healthy. So now three instances are healthy out of three. So this is perfect. So, if we go back to the root of the URL, we get hello, weld from one, two, and three different types of instances. So that’s perfect. Our target group is working properly, as is our ALB, and that’s it. So I hope you like this lecture, and I will see you in the next lecture.
7. [SAA/DVA] Network Load Balancer (NLB)
Let’s move on to the final load balancer, network load balancers, which are layer load balancers that allow you to transform and forward TCP or UDP-based traffic to your instances. At its lower level, it allows you to handle millions of requests per second. So they’re extremely high-performance, and the latency is a lot less than for the ALB. So here are some numbers to get you started. An average time would be 400 milliseconds. Latency for an application load balancer is around 100 milliseconds, while latency for a network load balancer is around 200 milliseconds.
The MLBs are also very different because they expose one static IP per availability zone on the outside, which is very helpful when you want to whitelist specific IPs. And they also support assigning elastic IPS instead of the ones given by the NLB itself. So that means that you can use NLB when you want to have two entries. points, for example, that are dedicated, specific IPs for your application. And then the NLB will forward the traffic into your EC. Two instances that are different from the ALB or CLB, which did not have a static IP but had a static host name Now the NLB’s use case is usually around when you want extreme performance or you want TCP or UDP level traffic, and for the hands-on that we’re going to do very, very soon, The NLBS are not included in the AWS free tier.
So if you do the work hands-on with me, then you will pay some money. So if you don’t want to pay any money, then don’t do the hands-on with me. Very simple. Now, the network load balancer is at layer 4, and what that means is that your target groups will now receive TCP-based traffic will reach your target groups.So it could be from the outside. And we can also have some rules around how to redirect to your target groups. Okay. So let’s go hands-on to see how network load balancers are being created.
