In this video, Jeff Winesett demonstrates how to configure the AWS auto scaling service. An Auto scaling configuration and group is used to help scale EC2 instances horizontally to help achieve a high availbaility architecture.
- [Instructor] The last thing to do is setup auto scaling. I introduced auto scaling previously in the course as part of our discussion, on how to implement elasticity in the cloud. Auto scaling has two primary components to it, a launch configuration, which defines what to scale, and auto scaling groups which define how to scale. So from the console, to setup auto scaling, I'll go back in to the EC2 service, and on the left-hand menu, there's an AUTO SCALING section.
I'll start with creating a new launch configuration. Since I don't have anything setup yet, I'm prompted to create an auto scaling group, which will include a launch configuration as part of the process. Click Create Auto Scaling Group. Doing so, provides me with a little landing page, telling me about launch configurations. So, I already know a little bit about these, we've introduced these, I'll move on to Create launch configuration. The next thing I have to do is choose an AMI to use to launch new servers.
This is part of what to launch. Since I want to auto scale the web servers, I want to use the AMI that I created previously at our web server tier. So under My AMIs, there's the AMI I created before, and this is the one I want to select. Next, I select the instance type, which is also part of what to launch, and I'm gonna stick with the micro instance here too. On to configure the details. The rest of this configuration is similar to what we've done before, when creating a new instance.
I can move through this pretty quickly as we've seen this before. Add Storage, I don't need any storage, Security group, I do want to launch it with a security group of web-tier, review the details, and just as when launching a new instance, I'm once again asked about the key pair, yes, I have access, and I'll launch the configuration. Then we move right into creating auto scaling group, so we'll start that process.
First, I'll name the group, web-scaling-group-1, name it whatever you like, whatever makes sense to you and your organization. Next, it asks about the Group Size. This is a number of instances the group should have at any time, it's also considered the desired capacity. I like to keep this at two. I want to have one in zone a and one in zone b always running, so I'll put my minimum at two. For the Network, we're gonna use our default VPC.
For the Subnet, I want to add in both of the availability zones that we're currently using to balance our traffic. Those have been zone a and zone b. Now if I toggle down here to Advanced Details, since I'm using a load balancer, I need to fill out a few things down here too. I want to indicate that this instance is launching to this auto scaling group are going to receive traffic from one or more load balancers. Since I'm using the application load balancer, I specify the Target Group, and we've already got this is as a choice, the Target Group that we've created.
The rest of these defaults are fine for now. I can move on to configuring the scaling policies. These policies help to further define how and when to scale. This is where CloudWatch alarms could be used. For example, I could create an alarm when the CPU of the instances, rises above a certain percentage and then have that alarm be the cause of adding more instances into the group, thereby scaling out. Similarly, I could add another alarm that if it falls below a certain percentage threshold, I could have it remove instances back down to that desired minimum number, which I set it to.
For the purpose of this demo, I'll just keep it always at two, but just know you, that could setup other policies to scale things in different ways. Next, Configure Notifications. This is where I could setup notifications based on any of the auto scaling events. For example, I could get an email when things scale out, when more servers are added to the scaling group, and similarly, I could receive an email, when things scale in, when servers are removed. For now, I'm just gonna keep moving on. I don't need any notifications at this time.
Can configure tags, maybe I'll still put in the environment, test environment, and add another tag, our good old friend the cost-center, and add marketing, click Review, it gives me a chance to review all the details that I've setup, everything looks good, I'll move forward with creating the auto scaling group. Great, it was successful.
And this takes me back to the auto scaling console homepage where I can see the information provided here. Similarly to the EC2 instances and RDS instances, I have a series of tabs down here that provide me even more information about the auto scaling group. The Details, the Activity History, Scaling Policies, Instances, so right now, because I specified I wanted two instances, one in zone a and one in zone b, they're actually being created and added to this auto scaling group.
They're being based on that AMI that I chose, which was created from the web server that we initially created, which means that these will be spinning up already as LAMP stack Apache web servers. These instances look to be created and in a healthy status. If I go back to Instances, I now see that I have four instances running. Two of them are actually still in Status Checks being Initializing, so I need to wait for those two to finalize. Now we have two more instances that have been automatically launched for us after creating the auto scaling group and launch configuration, so I can double check and make sure that they are actually been added to the Target Group, as specified, got Targets, we've got four instances now, behind the load balancer, all in a healthy state, they've all been launched with the same configuration since they've been created from the same AMI.
If I were to go back and in the browser, hit the load balancer, I would now expect this to rotate between four server ID's because I have four behind the load balancer. So i-013, i-013, i-0abdd, i-0f6bf, and i-0969a, great, and now we're back to 013ef, and so as I refresh, I'm just round robining between each of the servers behind the load balancer.
Now that I have my auto scaling launch configuration and group in place, I don't need the first two servers I created, I can just get rid of those. I've got my AMI from the first one, I can always create more, and the two initially are not part of the auto scaling group, so I can just get rid of those, let me show you how to do that. Go back into Instances, and I need to choose the two that were not created from the auto scaling group. Now one way to help me indicate that is to change what's being displayed here, so if I go up here to the little gear, I can go in to what is a configuration for the grid that's being displayed here for all these instances, and one thing that I can add is, add the auto scaling group name, and I can be able to see that when instances launch.
Once adding, I can now see the name of the auto scaling group that the instances were created from. This clearly tells me that this one and this one were not part of the auto scaling group. These are the two I can remove. Actions, Instance State, Terminate. It gives me a little warning, making sure that I have the right kind of storage in place, and just to be careful when terminating instances that you can lose some data if not stored correctly. In this case, we setup RDS, and we're persisting all our data to a separate data store, so this doesn't matter, I can proceed, Yes, Terminate, and we see it will proceed in shutting down the servers and terminating them, thereby removing them from our instance listing, and we won't have to pay for them anymore.
The two instances have completed termination, and now we just have the two instances that were created from the auto scaling configuration and auto scaling group. The last thing I want to do here is test that the auto scaling is working. If you recall, I setup auto scaling to ensure that we always had two instances available, one in zone a and one in zone b. So if anything were to happen to one of these two instances, auto scaling should kick in, and replace it, always keeping the available number at two.
So I'm gonna test this out by explicitly terminating the one in zone b. So, do that, Instance State, Terminate, again with the warning, Yes, Terminate, Yes, Terminate. Okay, shutting down is in progress, let's navigate around a little bit and see what's actually happening. So if I do go down to the Target Groups, and I look at the targets, I now see that another instance has been added.
It's currently waiting for it to be healthy, instance is still being registered, but as we can see, auto scaling did kick in, it realized that there was only one server in the instance count when it needed to be two, and if I look at my history, it shows me that it launched a new instance to replace the one that was terminated. So now I can go back in my instances, and now I'll need to wait for this initializing to happen, and while that happens, my traffic is still only being routed to the one single healthy server, and we'll wait here for this initialization to happen to show that it does end up getting added back behind the load balancer, and taken care of.
Okay, the Instance State's have completed, and the new instance that was created from the auto scaling is now up and running, as I can see here. So if I were to toggle back and hit the load balancer, I should once again see it balance between two different EC2 instances, which is exactly what it's doing. So auto scaling is indeed working, terminating one of the instances, caused auto scaling to kick off, create a new instance, replace it, put it behind the load balancer and we're back in business.
Okay, we set off to create a new auto scaling configuration and auto scaling group, and we've done that, mission accomplished. So in the next video, what I'm gonna do, is I'm gonna show you how all of these previous videos could have been condensed down to just a few steps by using Elastic Beanstalk to basically create the same application that we just created manually. Stay tuned, we'll do that next.
- Benefits of cloud services
- Making architectures scalable
- Examining cloud constraints
- Virtual servers, EC2, and Elastic IP
- Using the Amazon machine image
- Elastic load balancing
- Using CloudWatch for monitoring
- Security Models
- Elastic block storage
- S3, CloudFront, and Elastic Beanstalk
- Handling queues, workflows, and notifications
- Caching options and services
- Identity and access management
- Creating a custom server image
- Application deployment strategies
- Serverless architectures