EC2 High Availability and Scalability

9. Auto Scaling Groups Hands On (with ELB Health Checks!)

Okay, so in this lecture we're going to create an auto scaling group. And so before that, I'm just going to terminate all of the 82 instances that we've created before. Don't worry; they'll be recreated soon enough. Next, I want to go all the way down to the bottom and create an autoscaling group. Now this auto scaling group is going to be something special. So the first thing we have to do is create a launch configuration. So for this, we'll select Amazon Linux 2 AMI, click on Select T 2 Micro, and click on Configure Details. Here is the launch configuration; I'll call it my Launch Config, and I am rolling. I'll select Amazon EC2 for SSM. Excellent. Then, for advanced details in the user data, I'm going to install Apache as a boot. And so here is my user data SH file. And so what this script does is very simple. We update the packages, then we install HTTPD. So Apache is on our machine, and we start Apache. We enable Apache reboot, and then we just echo this hello world from hostname into our index HTML file into VAR wwhat. And so this will just start a smallweb server just like we've done before. So what I'm going to do is just copy this and then go to my user data and paste it here. When you're ready, you click on "Add storage," "Configure security group," and we'll select an existing security group.

For this, I'll just use the My Web app, which right now allows HTTP traffic on port 80 from my load balancer. Click on "review" and then "okay," then "continue." Next, we're ready to go. Click on Create Launch Configuration, and we'll assign an AWS course keypad to this. OK, now we go to creating the autofill group. We'll just call it my Sigma ASG, and we'll start with three instances in the subnet. I'm going to choose three subnets, and basically, this says that I should launch two instances in EUC: one in subnet A and one in subnet B. That's because we want to be highly available. So remember, this is all about high availability. In the advanced details, we can set load balancing, and so here we can say to receive traffic from one or more load balancers. We don't have a classical load balancer; we have an application bouncer. And so for this, we use target groups. So in target groups, I'm going to select my Apache web. For now, the health care type is going to be ECQ, not ELB. We'll change this in a second. But I want to start by showing you something.

For the grace period, I'm going to select 60 seconds, and the rest is good. Next, we click on "Configure scaling policies." And this is where we could configure the scaling policies for ASG. We could use scaling policies to target, for example, average CPU utilization. But we could also set step or simple scaling policies if you wanted to have alarms and add or decrease instances based on cloud watch alarms. For now, we will keep things very, very simple. We will not have any scaling policies because I expect you to know them, and we'll keep this group at its initial size. Click on "Configure Notification" and we are fine. We're not going to have any notification tags as well, so click on Review. Let's go ahead and create our auto-scaling group now. So our auto scaling group has been created. Click on Close, and now it is starting. So as you can see now, the number of desired instances is three, the minimum is three, and the maximum is three. What I'm going to do right now is just edit the minimum and the Max.

So I'll click on Edit, and I will just set the Min to zero so we can lose instances if we need to press Save. And so let's see what happens if you look at instances. The really cool thing is that because we have set up the three instances we wanted and we have selected three subnets to launch our instances in, we can see that the three instances being launched right now are in EU-1, EU-2, and EU-3, respectively. So by default, by selecting the fact that we have ASG in three AZ, we get high availability, and that's pretty cool. So now I'm just going to wait for my instances to be ready, and I'll just pause the video. Okay, so my instances are not healthy and so if we go to my target group itself, we should see in Targets the fact that yes, my three instances are healthy and they're registered and they're in three AZ. So we have full availability.

Okay? So what that means is that if I go to my load balancer, I should be able to access my application. So let's go to the DNS name; I'll copy it and then open a new tab and paste it. Here we go. We get the Hello World message, and if I refresh, we get sent to three different applications, three different instances. So this is working really well. As you can see, my instances work just fine. But now I want to show you what happens with all these health checks and this advanced stuff, because you already know this. Okay? So let's go back to our auto-scaling group. And so one thing I want to show you is the health check. So let's say that right now our three instances are healthy, but we have an EC-2 health check. So that means that even though my ELB would mark an instance as unhealthy, my ASG will not see it. So let's just demo this right now. I'm going to go to System Manager. So I'll open a new tab in Systems Manager, and I'm going to just go and do SessionManager, and I will take one of my instances. So I'll start a new session, and I'll take any of these instances and start a session on them. Here we go.

I'm on a session, and so I'm going to do pseudosu to be root, and I'm going to do systemctl stophttpd, so this is going to stop Apache on the server. Now another thing I may want to do very quickly is create an entirely new group. I'm going to disable scrolling down and set the deregulation delay to 10 seconds because it would not wait that long. Okay? Click on "Save." This is when the instances will be terminated. Okay? So what happens is that now, through what I've done in Systems Manager, I've basically rendered that instance unhealthy. So if we go to our target group yesand we go to health check targets now we can see that two instances are healthy. These two first are healthy, but this one in EU West One A is unhealthy. That's because the health check fails. But if we go to our auto scaling group and we look at the health checks of our instances, all three of them are healthy. And so that's a very popular exam question.

It says well that the ASG is healthy but the ELB is not healthy, and it's unmatching. So what we have to do is indeed, instead of having an EC-2 health check type, enable an ELB health check type, and so the ELB health checks will propagate to the ASG. Click on "Save." So now the health check type is ELB, and what we should be seeing now is that very soon one instance will be marked as unhealthy. So here we go. My instance is now marked as unhealthy because the ELB checked it because it got propagated, so EU West one A is unhealthy. So what should happen very soon? This instance, here we go, should be terminated because it was unhealthy. and you can see the cause. It says an instance was taken out of service in response to an ELB system health check failure. And so if we go to this instance in the EC2 console, we should be seeing it being terminated very soon, as soon as all the checks are in place. So I'll just wait a few seconds, and now we can see that my instance is shutting down. So it was marked as unhealthy. So it's being terminated obviously, and if I go back to my ASG very soon, it should launch a new Etiquette instance in response to the fact that because it was terminated, my actual capacity was two and I wanted three.

So it's going to start a new instance for me. I saved. And so, as you can see, this new instance being in service is an EU West one again, so it tries to balance the AZ. So this is what I want to show you. This is all about health, all about OKA again, using SSM just for using secure shells on our machines, and making sure everything is well configured. So I hope that was helpful in the next lecture. We're also going to see some more advanced stuff, so see you in the next lecture.

10. ASG Scaling Processes Hands On

So in this lecture, I want to show you the inner workings of an autoscaling group. And so, behind the scenes, in the autoscaling group, they have scaling processes. The first one is obvious. The first scaling process is called "launch." And what launching does is that it helps to bring new EC-2 members into the group, increasing the capacity. We also have terminations. So when the scaling process terminates in the ASG, it will remove two instances from the group, decreasing its capacity. The health check in the ASG is what performs the health check on the instances. Replace Unhealthy is a scaling process that will terminate unhealthful instances, and then we can recreate them. Then there is an AZ rebalance to balance the number of AC 2 instances across all the AZ we have alarm notification to accept notification from CloudWatch scheduled action basically to perform scheduled action on our behalf and add to the load balancer to register new instances into our load balancer.

So why am I talking to you about all these things? Well, because we can suspend these processes. So we can just say that you cannot terminate instances anymore. And so we're going to play with those, and I want to show you how important they are. What you need to remember is definitely the first five. So launch "Terminate Health Checkreplace," "unhealthy," and "age rebalance." These are five very common scaling processes. So in this lecture I'm going to play with them, and at the end I'm going to give you more information about AZ rebalancing. So you may be wondering how we set these suspend actions. So in my AST, I'm going to click on edit, and then all the way to the bottom, there is a suspend process. And so this checks a box we've never seen before, but we're seeing it now. So in there, we're able to suspend some processes, so we can suspend whatever we want. All these things I told you about before So let's, for fun, suspend and terminate. So here, by suspending the process, we're telling our ASG that it cannot terminate any easy instance. Click on Save, and we'll see here that nothing has changed. But now what I'm going to do is set the desired capacity to two. So let's go and set the desired capacity to 2 and the minimum capacity to 0. I don't know why it didn't stick.

And so here is the desired capacity: two minutes, zero hours, and three hours. And so usually, when we do this, it should terminate an instance for me. But because we have suspended the process, nothing should happen. So let's have a look. Now, as you can see in my spreadsheet, there are three instances and two desired. But if we go to the instance, they are healthy and nothing is happening. If we go to the activity history, there's nothing happening. I'll just wait five minutes to prove it to you. Okay, so it's been five minutes and nothing happened; there is no activity history, and three items of maintenance are still there. The reason is that because we suspend the process, our ASG will not terminate our instances in any way. And so this could be really helpful in troubleshooting. Now, to prove that things should be working when you don't suspend the processes, I'm going to remove the terminator and suspend the processes. Click on "Save." And now my instance should be terminated automatically because I'm allowing my ASD to terminate my instances. So let's go to Activity History and wait just a little bit.

And now here we go. As you can see, the activity history says that they are starting to terminate an EC2 instance because the capacity has changed by one and so we need to terminate one. So this is really cool to see how these suspend processes work because it really shows you how you can modularize your ASG and really control how it works. Let's do another fun one. Let's play with "replace." Unhealthy. So now I'm going to go ahead and mysuspend processes and I'm going to suspend replace unhealthy. So this process, as remembered, basically replaces unhealthy instances. So if I suspend it, then unhealthy instances will not be replaced, and we can troubleshoot what's going on in them.

So click on "Save. And now replace. Unhealthy is chosen. So let's go back to our instances. We have two healthy instances, and one is being terminated. And so what I want to do is make one of these unhealthy. So for this, there's a really cool way of doing it. There's a CLI called set instance health for ASG. If you look at this CLI command, basically, we can set the instant half of any of our instances. So let's play with it. For it, we have to use the instance ID and the health status. So let's have a look. My instance ID is right here. So let's do it. AWS Autoscaling Set the instant health instance ID. And then we have to paste in this instance ID. For example, if that's the one we want to basically make unhealthy, Here we go. And then I will say, "Let's remember what the flag is: health status." And then the value of health status can be either healthy or unhealthy. So let's set the instance status to unhealthy. Here we go.

Press Enter, and no output occurs. But if we go back to our little instances and refresh them now, the health status of this one has become unhealthy. How cool is that? So using the new CLI thing you just learned, you can set instances as healthy or unhealthy. But because my suspend process is replacing healthy, nothing will happen. This instance just remains unhealthy, but it will not be terminated. And so again, when you suspend a process, something happens. Again, if I go to the details instead, And now don't suspend that process anymore; it should start replacing my unhealthy instances. So let's just wait a little bit, go to Activity History, and know that in a few seconds it should start being terminated. And so, as you can see now in the activity history, it's saying it's terminating this instance and waiting for the ELD Connection training, and it says it was taken out of service because of a user health check.

So because we manually set the health status to unhealthy," that's really cool. Now the instance will get terminated eventually, and a new instance will get launched right away. So really, really nice. So remember these suspend processes; you should know them, especially the Launch Terminate Health Check we place on "healthy" and AZ rebalancing, which I just want to talk to you about right now. So the AZ rebalance is when there is an imbalance in our AZ spread. For example, one availability zone has five instances, another has one, and another has zero. This is an imbalance. And so it's going to rebalance to put two instances everywhere. And so this AZ Rebalance ASG Scaling Policy or Action is basically going to launch new instances and then terminate the old ones. So it's going to rebalance stuff by launching new instances at first. And so if we suspend that launch process, it's basically going to impact how AC rebalancing works. So if we suspend the launch process, that means that our ASG cannot launch any new instances, so the AZ rebalance won't launch new instances, and because it's not able to launch instances, it won't terminate instances either. So we basically render AC rebalancing useless if we suspend the termination process. That means if we forbid AZ rebalance from doing this rebalance, then it's still going to launch instances.

Actually, the ASG can grow up to 10% of its size. Okay? It's allowed during rebalancing. So even if you have a desired capacity of ten, it's allowed to go to eleven because it's allowed to grow by 10% during AC rebalancing, but then it will remain at this increased capacity because it can't terminate instances. And that's quite a popular exam question as well. So it's something you have to remember that, basically, if you can't terminate instances and the AZrebalances happen, it's going to run at overcapacity, at 10% over capacity. Just remember that number. This is something quite important, and so what's important for you to understand is that all these scaling policies can impact each other, and the AZ rebalance is impacted by the launch process and the termination process. So just as a summary, again, remember all these scaling processes and that you can suspend them. Launch Terminate Health Check Replacement health and azure balance are by far the most important for you to remember. I hope that was helpful, and I will see you in the next lecture.

11. ASG for SysOps

Okay, so just a few tips going into the exam—especially for SysUps, where it's just shots and things you already know but it's good to reiterate them once. So if you want to have high availability, that means you need to have at least an ASG that is configured to work across two AZs and therefore two subnets. And so even though it's configured to be across two AZs, you will not get high availability until you launch at least two instances. and I think that makes sense.

Remember my first lecture? Another thing you should know is about the health checks. We've seen this in depth, but I want to reiterate it. We have EC2 status help checks, and these are about knowing if the VM is okay or if the underlying hardware is okay, but they won't tell us information about our application. If our application is exposed to a load balancer and the load balancer is approved to do health checks on it, then we can use ELB health checks. And we did this during the hands on session.

By switching from EC-2 health checks to ELB health checks, our ASG was able to see what was unhealthy and therefore terminated. Also, ASG will launch a new instance after terminating an unhealthy one. So if one instance is marked unhealthy, it gets terminated, and a new instance is created. There is no such thing as an ASG rebooting an unhealthy host for you if that's something you wanted to do. You would need to basically remove suspended processes and manually reboot the unhealthy host yourself. Two CLI's are good to know. Number one is setting instance health, and we've been able to play with it. It's a way to basically say that an instance is unhealthy or healthy, but manually. And another one called "Terminate instance in Autoscaling Group," which I think is quite explicit about what it does; it basically allows you to terminate a specific instance in an autoscaling group.

Now you may have issues, which you need to know about and know how to react to them. So number one is when you get a number of instances that are already running and the launch of an instance fails. So this is basically when you're trying to launch an instance but your ASD has already reached the limit set by your desired capacity parameter. And so, in order to add instances to your ASG, you need to update your scaling group and provide the new desired capacity. Just something you should know. Sometimes launching EC2 instances will fail, and there may be a couple of reasons for it. Number one is, for example, that the security group does not exist.

So, for example, someone deleted the underlying security group, and your ASD cannot create your EC-2 instance. Otherwise, maybe someone deleted a key pair, and so, basically, because the key pair does not exist anymore, ASG cannot launch Easy Two instances. And so these are things to know and look for in case of launch issues. And if your ASG fails to launch instances for over 24 hours, if the issues persist for over 24 hours, then automatically it is going to suspend the processes. And this is called administrative suspension. So all the processes we've seen before are suspended because we can't launch easy two instances. So remember this going into the exam. These are common issues to deal with in ASG, and you should know about them. I hope that was helpful, and I will see you in the next lecture.

12. CloudWatch for ASG

Okay, so now just talk about Cloud Watch metrics for ASG. Remember, "Cloud Watch" is a very important exempt topic. So there are eight metrics that are available for SG, and it's opt in group instance groupmax The size of the group is our capacity. So these are just some parameters we can track in our ASG in service instances. So that means how many instances are running (pending instances), how many are being launched (on standby), how many are ready terminating instances are being terminated), and how many total instances we have in our ASG. So we can enable the metrics collection to see these metrics, and we'll see this in a second.

And something you should know: these metrics for the ASG are collected every 1 minute. Now, we can also monitor the underlying EC2 instances. And for this, there's nothing special. The basic monitoring is at 5-minute granularity, and that's enabled by default. And we also get detailed monitoring with 1 minute granularity. and that's something we have to pay for. So let's have a look. This is our ASG, and I'm going to go to monitoring. And as you can see, I can display either auto scaling or EC 2. It turns out that I need to enable group metrics collection before things happen. So here we go. Now it says metrics can take some time to appear after enablement, so we won't see much. Right now, you can see all the metrics that are discussed right here. And so as soon as you enable the auto-scaling metrics, this will get populated. And then you can display EC Two instances as well. And here you get EC-2 monitoring. And so what we can see here is the CPU utilisation average. The Discrete Bytes Networking network out all these cool pieces of information we get, as well as status checks.

So it's a nice way to view all these metrics. So lastly, if you wanted to go see The Min Cloud Watch directly, you go to Cloud Watch. Oops, Cloud Watch. Here we go. And in Cloud Watch, you will go to Metrics. And here there will be anodized scaling and group metrics. And here we are able to see from myASG all this information, such as the desired capacity. For example, it's two. We can do the max size, which is three, and the min size, which is zero. So we can have a nice graph right here showing our desired capacity, minimum size, and maximum size for ASG if we want to. But all these metrics, something to remember, are available under the Autoscaling namespace for us automatically. So that's it for this lecture. Just remember this: you need to enable these metrics, which have 1 minute granularity. And then we can see in this dashboard either auto-scaling or EC 2. Okay, that's it for this section. I hope you liked it, and I will see you in the next lecture.

13. Section Cleanup

So in this section, I just want to clean everything up. So for the ASG, we just right-click and delete, and this will delete the ASG-terminated instances from me, and so on. So this might take a while. Then in launch configuration, I can right-click and delete this launch configuration, and this will make sure that it is gone. But this is not something you wanted, so you could have kept that launch configuration if you wanted to. Now for load balancers, there's this load balancer right here. Again, it's another free tier, but we're going to delete it nonetheless. And here it's gone. And then finally, the target groups are something you definitely want to deal with as well. We're going to delete the target group. They don't cost any money, but it's good to clean up after ourselves.

So in the instances, what we should be seeing is that all our instances are shutting down. So yes, as you can see, lots of instances are being terminated and shutting down right now. And so that's it for the cleanup. We've basically deleted everything we've created in that section. I hope you like that section, and I will see you in the next lecture.

Prepared by Top Experts, the top IT Trainers ensure that when it comes to your IT exam prep and you can count on ExamSnap AWS Certified SysOps Administrator (SOA-C01) certification video training course that goes in line with the corresponding Amazon AWS-SysOps exam dumps, study guide, and practice test questions & answers.