Hi, everyone. Welcome back. Morgan here. Let's recap what we've built out so far. Previously, we built our application and launched it on two separate EC2 instances. Those EC2 instances lived in two separate Availability Zones and two public subnets. We then had our private subnets with our database instances in them. We also created an elastic load balancer. Our elastic load balancer distributed traffic across our EC2 instances. Let's imagine a scenario where our corporate directory application starts to get really popular. As more people visit our application, the demand on our two web servers is going to go up. At some point, our two instances aren't going to be able to handle that demand, and we're going to need more EC2 instances. Instead of launching these instances manually, we want to do it automatically. So, we're going to use what's called Auto Scaling. Auto Scaling is what allows us to provision more capacity on demand, depending on different thresholds that we set, and we can set those in CloudWatch. You know what? To get a better idea of this-- Hey, Blaine, can you draw this out for us? You bet, Morgan. Let me go ahead and explain a little bit about, wait a minute. We're doing a super lab again, aren't we? Yeah. We need our jackets. Hold on. You know, if you insist on super lab, that's fine. Super lab time, here we come. Wait. This isn't just super lab. It's time for super duper lab, here we go. Ready? Let's do this. We are looking at an EC2 distributed system, where you've got multiple subnets across multiple Availability Zones, EC2 instances that are created inside an Auto Scaling group, meaning, they're identical, they can launch as needed by the Auto Scaling engine, all connected through the elastic load balancer. So, traffic coming in from the outside can easily come down to either EC2 instance, but there's going to be more, because we're going to take those EC2 instances and we are going to stress them out. We're going to run an application that's going to make these think they're overloaded. When they do, they're going to be sending metrics over to CloudWatch. CloudWatch is watching for whenever the CPU crosses a certain line, and when it does, it's going to tell the Auto Scaling engine that we need more EC2 instances launched in each Availability Zone. It's going to happen automatically, without any humans doing the work. All right. Morgan, show them how it's done. Okay. So, to get this built out, we have to create an Auto Scaling group and a launch configuration. This is going to define where we're launching our new instances and what to launch. So, let's look at the console and see how to really build this out. First, what we're going to do is, from the EC2 Dashboard, we can scroll down, and we can select Auto Scaling Groups. I'm already on that page. So, we're just going to go ahead and create Auto Scaling group. From here, I'm going to select Launch Configuration, and I'm going to create a new launch configuration, and click Next Step. The first thing to do is to define what AMI we are going to use. So, again, our launch configuration is what are we going to launch. So, we have web servers out there that are already receiving traffic. We want to create mirror images of those web servers. So, that way, whenever we scale out, we just have more instances with the exact same configuration. So, that's our launch configuration. Let's go back to the console. So, as we did when we launched our EC2, we're going to select the Amazon Linux AMI, and we're going to keep our t2.micro. From here, we will configure details. We'll give our launch configuration a name. We'll call this Web Server and we will give it the role, instance-role. This is the same role that we gave to our EC2 instance when we launched that previously. So, now we have to expand the Advanced Details. We paste our user data. Our user data, again, is what goes out and grabs the source code and unzips it so that our application is running on the EC2 instance. We'll click Next for add storage. We'll just hop through this, we don't have to worry about that. We'll configure our security group by selecting an existing security group. We will select the web security group which enables HTTP traffic. Next, we will review. We'll go ahead and get past this warning by just clicking Continue. Here, we can see our launch configuration. We have our AMI, our instance type, and we have our security group for our web traffic. Again, this is all the same settings for our existing EC2 instances. Here, I'll create the launch configuration, I will acknowledge the key pair and click Create launch configuration. Now that we've configured our launch configuration, which again, is going to define what we're launching and the configurations for those instances, we now have to define an Auto Scaling group or where we're going to launch those instances, and when to launch them as well. So, we can see on the screen here, our launch configuration is already populated to Web Server. So, we're going to go ahead and give this Auto Scaling group a name. We're going to call it webservers. Our group size is going to start with two instances. This is so that we can have instances across Availability Zones, one in each to start at a minimum. Next, I'll change the VPC to be our directory VPC. Then for the subnets, I'm going to select both of our public subnets that we created. If we scroll down to the Advanced Details section, we also have to select for the load balancing to receive traffic from one or more load balancers. This is because we've created an ELB in our VPC. We're going to call this target group webservers. Next, we can configure the scaling policies. So, for scaling policies, what we're talking about here, is you can set up a scaling policy with CloudWatch that whenever your instance capacity reaches a certain limit or any other metric that you would like, you can add more instances to the pool, which would deploy more EC2 instances into your Auto Scaling group. So, we can do that right here. So, what we want to do is use scaling policies to adjust the capacity of this group. We want to scale between two and four instances. Two is the min and four is the max. We'll name this Scale Up. Our metric type is going to be the Average CPU Utilization. Our target value is going to be 60 percent. Instances are going to need 300 seconds to warm up before scaling. We can go ahead and click Next now to configure notifications. You can configure notifications when scaling events happen. This is optional. So, for now, we're just going to skip past it. We can configure tags as well, but we're going to skip past that for now too. Next, we will review. Here, we can see we have our Auto Scaling group defined. You'll notice that we skip through some of the configurations. That's because these are optional. By default, we can keep it simple, and go ahead and just create our Auto Scaling group. So, I'll click Create Auto Scaling group. All right. Our Auto Scaling group has been successfully created. So, now all that's left to test is we need to stress our application and make sure that our application does scale. So, to do that, I'm going to open up a new tab. I'm going to paste the endpoint for our elastic load balancer. Here's our application. I'm going to go back to that info page. You'll notice down here that we built in a stress CPU feature. This is going to mimic the load coming onto our servers. Then we can watch our servers scale with that Auto Scaling policy. So, as the CPU utilization goes up, our Auto Scaling policy will be triggered, and our server groups will grow in size. So, I'm going to go ahead and select 10 minutes for our stress CPU. All right. Some time has passed, we've stressed our application, and if we take a look at CloudWatch, we can see what happened. So, let's click on CloudWatch. If you look here, we can see our Alarm Summary. So, we stressed our system and I'm going to click on this graph to show you guys what happened. So, we stressed our system. You can see here the spike in CPU. So, we went over 60 percent CPU utilization across instances. That was our threshold to launch new instances into the pool. So, we launched two new instances into our Auto Scaling group. Then you can see the load started to come down. Because we've launched more instances into our Auto Scaling group, there were more hosts to accept traffic from our elastic load balancer, and the average CPU utilization then went down across our servers. All right. So, let's exit this and go look at the EC2 instances that were launched into the Auto Scaling group. So, I'm going to close this. I am going to go to the EC2 Dashboard. From here, I'm going to scroll down to Target Groups and select webservers, which was our Auto Scaling group. I'm going to select targets, and we can now see that we have four healthy targets in our Auto Scaling group. All right. So, now we have an environment with an Auto Scaling policy and our launch configuration. We've set up an alarm in CloudWatch, that whenever our CPU utilization goes over 60 percent, we're going to launch more instances into that group. Okay, Blaine. Can you draw some things out for us to help us visualize this? Great. So, let me just recap exactly what you just saw. You had your EC2 instances. Again, they're part of the Auto Scaling group. They're identical, they're launched as part of the launch configuration. As they were put under stress, they all reported down to the CloudWatch engine, saying their CPUs are overloaded. CloudWatch went into an alarm state and told the Auto Scaling engine, "Give me more EC2 instances." As they each came online, they all reported back to the elastic load balancer, they got traffic, ending up giving us all the scalability we need. Now, if we wait around long enough, what we would see is, as the CPU load dropped off, then one by one, they would each get terminated, because we no longer need them, bringing our state all the way back down to the basic two we need, the minimum number for this particular group. All of that done without any human intervention. I love the automation. Back to you, Morgan. Thanks, Blaine. All right. So, we've use CloudWatch to monitor our EC2 instances. When our instances went over that threshold, we had an alarm in CloudWatch that triggered our Auto Scaling policy. For more information on CloudWatch, visit aws.amazon.com.
