- [Alana] Now that we have multiple EC2 instances hosting our application in public subnets, it's time to distribute our requests across our servers using the elastic load balancing or ELB service. Conceptually, how this works is, a typical request for the application would start from the browser of the client and is then sent to the load balancer. From there, the load balancer determines which EC2 instances to send the request to. After it sends the request, the return traffic would go back through the load balancer and back to the client browser, meaning your load balancer is directly in the path of traffic. Now, if we're looking at the architecture, the ELB looks like one thing. It looks like a single point of failure, but ELB is actually by design a highly available and automatically scalable service, much like S3 is. What that means is that (a) the ELB is a regional service, so you don't have to worry about maintaining nodes in each availability zone or having to configure high availability yourself. AWS maintains that for you. And (b), the ELB is designed to handle additional throughput and will automatically scale up to handle the traffic coming in without you having to configure that feature. Now, there are several types of load balancers that you can choose. There's the Application Load Balancer, that load balances HTTP and HTTPS traffic. There's the Network Load Balancer, that load balances TCP, UDP, and TLS traffic. And there's the Gateway Load Balancer, which is mostly for routing traffic to third-party applications. For our employee directory application, we'll be load balancing web traffic, so we'll be using the Application Load Balancer or the ALB. When you create an ALB, you'll need to configure three main components. The first component is a listener. The goal of the listener is to check for requests. To define a listener, a port must be provided as well as the protocol. For example, since we're routing web traffic and we set up our application to use port 80, we'd want our load balancer to listen to port 80 using the HTTP protocol. Additionally, we could set up a listener for port 443 using the HTTPS protocol. The second component is a target group. A target is the type of backend you want to direct traffic to, such as EC2 instances, AWS Lambda functions, or IP addresses. A target group is simply just a grouping of these backend resources. Each target group needs to have a health check, which is how the load balancer can check that the target is healthy so that it can start accepting traffic. The ALB operates on the application layer, which is Layer 7 of the OSI model. This gives the load balancer a lot of cool features, and one of those is the third component, which is a rule. A rule defines how your requests are routed to your targets. Each listener has a default rule and you can optionally define additional rules. So if we had two target groups, A and B, we can set up an additional rule that says if traffic is coming to our /info page, we can deliver that traffic to target group B. So because of the fact ALB operates on Layer 7, you can customize paths for your traffic. Okay, now it's time to put this into practice. Let's create an Application Lload Balancer in the console. If you wanna find the ELB service, you'll need to go to the EC2 console. So we'll type in EC2 in the service search. And then on the side panel, we'll go ahead and select Load balancers. Once we bring up our load balancers dashboard that shows all of the load balancers for this region, we'll then click Create load balancer. Here is where we choose which type of ELB we want, and you can see the three main types. We'll be using the ALB. From here, we'll choose a name and call it app-elb. The next setting asks if we want an internet-facing or an internal-facing load balancer. An internet-facing load balancer does what you might expect, which is route requests from clients over the internet to your backend servers or your targets. An internal load balancer, on the other hand, will route requests from clients with a private IP to targets with a private IP. For example, if you had a three-tier application with a web app and database tier, you could use an internal-facing load balancer to route traffic from your web tier to your app tier. For this app, we'll be routing internet traffic, so you can leave it as internet-facing. Then we select the listener. Currently, the default setting is to allow HTTP traffic on port 80. If we wanted to allow or limit to HTTPS traffic, we can click add listener, choose HTTPS and we'll be good to go. But for this demo, we'll stick with the defaults. After that, we choose which availability zones we want to route traffic to. First, we'll choose the VPC, then we'll select both availability zones, and then we'll choose the two public subnets. Then we'll go ahead and click next, and then next again. Now you choose your security group for your load balancer. This is where you decide which traffic you want to allow in. Here, we'll choose a security group that will allow traffic on port 80 from anywhere. Next, we'll go ahead and configure routing. Here is where we create a target group for our backend instances. We'll give it a name such as app-target-group-2 and then we'll go ahead and leave all the defaults and click next. This is where we'll be choosing which instances we want to live in the target group. So I'll go ahead and choose the two instances I have here, click add to registered and then click next, and then click create. After the load balancer has been created, we can then select it in the menu and then find the DNS name in the details page below. We can then pull that DNS name, copy it, and then paste it into a new tab. And from here, you can see our app. If I go to the /info page of our application, you can see which availability zone we're currently in. If I refresh the page a few times, you should see eventually that I'm being directed to both my EC2 instances in both AZs. And there you have it.
