With your ELB all set up, you are now ready to go ahead and start configuring the Auto Scaling service. As discussed earlier, there are basically three parts to Auto Scaling: The Launch Configurations, the Auto Scaling Group, and, finally, the Scaling Triggers. In this section, we are going to check out some simple steps using which you will be able to create and configure your own auto scaled environment; but before that, here are a few tips and tricks worth mentioning!
First up, prepare your Machine Image or AMI. By prepare I mean make sure you have already installed and configured your web server (in my case, I'm using a simple Apache HTTP web server) to start on instance boot up as well as place your application's code or website files in the correct directories. Additionally, you can even install and configure the CloudWatch Log agent in your AMI such that it captures the essential web server logs and sends them to CloudWatch for further processing.
The second most important part of any Auto Scaling activity is planning and understanding instance quantity, that is, what is the desired capacity of your Auto Scaling Group and what are the minimum and maximum number of instances you want your application to scale to. Since we are just starting off, I would really recommend doing the basics. Have a desired capacity set to 1 instance, which means that there will be a single instance hosting your web server at all times. Next, set up a minimum instance value of 1 and a maximum instance value of, say, 5. Remember that you can always change the Auto Scaling Group values but not the Launch Configuration details.
The third and final thing that I would like to mention is the famous moto: Plan for failure, and nothing will fail. Although you can set up Auto Scaling using a single AZ, it is highly recommended that you distribute your workloads across AZs as much as possible. The following is a look at my simple Auto Scaling example:
In this case, we have already deployed and configured our ELB, and the only thing remains is the Auto Scaling configuration. So without further ado, let's get started!
The first step to setting up an Auto Scaling activity is to create and configure a Launch Configuration. To do so, from the EC2 Management Dashboard option, select the AutoScaling Groups option from the navigation pane as shown in the following screenshot. This will bring up the Auto Scaling Groups dashboard. Next, select the Create Auto Scaling group option to bring up the Auto Scaling setup wizard.
The wizard is a simple six-step process that will first enable you to create and configure a Launch Configuration, followed by a five-step process to associate an Auto Scaling Group with it. Let us go through each of the steps in detail.
From the Choose AMI page, select your choice of AMI for your Launch Configuration. You can either select the Amazon Linux AMI to get started with or even select the custom AMI that we created back in Chapter 4, Security, Storage, Networking, and Lots More!, by selecting the My AMIs option and then selecting your particular custom AMI.
Select the appropriate instance type required for your Launch Configuration. In my case, I have selected the General purpose t2.micro instance type for my demo purposes; however, feel free to select an appropriate instance type as per your requirements. Click on Next: Configure details to continue with the process.
Provide a suitable Name for your Launch Configuration. In my case, I have named it using the same naming convention that I'm following throughout this book, that is, US-WEST-PROD-WEB-LC-1. You can Request Spot Instances instead of the default On-Demand Instances as well. Spot instances are a great way to save costs compared to your on-demand instances; however, use them with caution. Spot instances are spun up the moment your bid price rises above the instance's market value and are terminated when the market value exceeds your spot price.
You can optionally even assign a particular IAM Role for your Auto Scaled instances by selecting an appropriate Role name from the IAM role drop-down list. In this case, I have not provided any roles to my Launch Configuration. Select the Enable CloudWatch detailed monitoring checkbox if you wish to have your instances monitored for a duration of 60 seconds. By default your instances will be monitored by CloudWatch for a minimum period of 300 seconds (five minutes) for no charge at all. Selecting detailed monitoring will incur additional charges, so use it with caution.
Once your basic details are filled out, you can even set the instance's IP addressing scheme by selecting the Assign a public IP address to every instance option from the Advanced Details section. This option comes in handy when you wish to connect and log into to your VPC instances from your home network.
With your Launch Configuration created, you can now continue to adding and configuring the remaining elements of your instances, which includes the Storage and Security Groups. You can add an optional Volume to your instances by selecting the Add NewVolume button on the Add Storage page. The rest of the fields are pretty self-explanatory, so I'm really not going to talk about them here. In my case, I have not provided any additional volumes to my instances and opted for only a single EBS root volume (/dev/xvda). Click on Next: Configure Security Group to either create or select an existing security group for your auto scaled instances.
From the Configure Security Group page, select an appropriate Security Group for your Auto Scaled instances. Since we are working with web server instances, I have selected my US-WEST-PROD-WEB-SG (Web Server Security Group). The group has the following set of inbound rules:
|
Web Server Inbound Security Rules | |||
|---|---|---|---|
|
Source |
Protocol |
Port Range |
Remarks |
|
0.0.0.0/0 |
TCP |
22 |
Permit inbound SSH access to web server instance |
|
0.0.0.0/0 |
TCP |
80 |
Permit inbound HTTP access to web server instance |
|
0.0.0.0/0 |
TCP |
443 |
Permit inbound HTTPS access to web server instance |
You can optionally even create a new Security Group as per your requirements; however, make sure to have the SSH as well as the HTTP ports opened up before you proceed with the next steps.
Phew! After all those intense configurations, we are now officially ready to review and create our Launch Configuration. Make sure the AMI details, Instance Type, and your Launch Configuration settings are correct. Once verified, click on Create Launch Configuration to complete the process.
The wizard will now automatically set and create a new Launch Configuration based on your specifications. You can create as many Launch Configurations as you need; however, you will be able to specify only a single LC for an Auto Scaling Group at a time. Also, once a LC is created, there is no way you can edit its configurations. The only way to do so is by creating a new LC and associating that with your Auto Scaling Group. Instances that were launched as a part of the old LC remain unaffected by this change; however, any new instances that are created will use the new LC as their blueprint for the Auto Scaling activity.
With your Launch Configuration ready, the next and final stage of creating your first Auto Scaling task involves the setting up of an Auto Scaling Group. We have already talked about Auto Scaling Groups in the beginning of this chapter, so let's have a quick recap of the same.
As discussed previously, an Auto Scaling Group is nothing more than a logical grouping of instances that share some common scaling characteristics between them. Each group has its own set of criteria specified which includes the minimum and maximum number of instances that the group should have along with the desired number of instances which the group must have at all times. Besides these, an Auto Scaling group also helps us to create and define scaling triggers which, when triggered, result in either instances getting added or removed from the group. These scaling triggers rely on CloudWatch Metrics and periodic health checks to determine whether a particular instance is unhealthy or unresponsive. If such an instance is found, then the Auto Scaling service will automatically terminate the unhealthy instance and replace it with a brand new one! Awesome, isn't it!
With these basics in mind, let us go ahead and continue where we left off from the Launch Configurations stage. Log in to your AWS account using your IAM credentials and select the EC2 option from the AWS Management Console. Next, from the navigation pane provided, select the Auto Scaling Groups option. This will bring up the Auto Scaling Group dashboard, as shown in the following screenshot. Select the Create Auto Scaling Group option to get started:
Here, you will be provided with two options: either create a new launch configuration or create an Auto Scaling Group out of an existing one. Since we have already created our LC, select the Create an Auto Scaling group from an existing launch configuration option. Select the newly created LC and click on Next Step to proceed. Now comes the fun part where we actually get to configure the Auto Scaling Groups. Follow the next steps carefully and fill out the required fields as per your requirements:
The first step in creating your Auto Scaling Group requires you to provide a suitable name for your Auto Scaling Group as well as its Network and Load Balancing details.
Fill in the required fields as per your requirements:
- Group name: Provide a suitable name for your Auto Scaling Group. In this case, I have used the name
US-WEST-PROD-WEB-ASG-1. - Group size: Here, enter the desired capacity for your Auto Scaling Group. Remember that the value entered here represents the number of instances Auto Scaling must have at all times, so choose a smaller number to start with. In my case, I have chosen 1 as this is just a demo:
- Network: From the Network drop-down list, select your appropriate VPC in which you wish to enable Auto Scaling.
- Subnet: Once your Network is selected, you can now select your corresponding subnets. Auto Scaling will then launch the instances based on the subnet that you select here. In my case, I have selected two subnets, each created in a different AZ. This setup maximizes the availability of your application while minimizing any unwanted downtime.
With these basic settings filled out, we now move on to the Advanced Details section of our Auto Scaling Group:
- Load Balancing: These are optional settings that you can configure to work with your Auto Scaling Group. Since we have already created and configured our ELB, we will be using that itself to balance out incoming traffic for our instances. Select the Receive traffic from Elastic Load Balancer(s) option, as shown in the following screenshot. Next, type in the name of your ELB (
US-WEST-PROD-LB-01) in the Load Balancing text field:
- Health Check Type: You can use either your EC2 instances or even your ELB as a health check mechanism to make sure that your instances are in a healthy state and performing optimally. By default, Auto Scaling will check your EC2 instances periodically for their health status. If an unhealthy instance is found, Auto Scaling will immediately replace that with a healthy one. Here, I have selected ELB as my health check type, so all the instance health checks are now going to be performed by the ELB itself.
- Health Check Grace Period: Enter the health check's grace period in seconds. By default, this value is set to 300 seconds.
Once your Auto Scaling Group's basic configuration is complete, the next step is where you actually get to create and define the scaling policies. Click on Next: Configure scaling policies to continue with the process.
The second most important part of creating any Auto Scaling Group is defining its scaling policies. A scaling policy is a set of instructions used by the Auto Scaling service to make adjustments in your Auto Scaling group's size (number of instances). Each Scaling Policy is attached with a CloudWatch alarm and a notification action. When the alarm is breached, the appropriate scaling policy is triggered, which will either add or remove instances from your Auto Scaling Group depending on its definition. Let us go ahead and create a few such scaling policies for our own use.
First up, we need to define whether this particular scaling policy will be used to maintain the Auto Scaling Group's initial size (desired capacity) only or whether you wish to adjust the Group's size by adding or removing instances. In this case, I have selected the Use scaling policies to adjust the capacity of this group option, as shown in the following screenshot. I have also provided the minimum (1 instance) and maximum number (5 instances) of instances I want to the group to scale between. You can provide your own set of values here as per your needs; however, stick to the basics if this is your first time:
Next, we define and create our scaling policies. There are two policies that are used by an Auto Scaling Group: one to increase the instance count based on certain alarms and the other to decrease the instance count. To begin with, let us first go ahead and populate the Increase Group Size policy, as shown in the following screenshot:
- Name: Provide a suitable name for your scale-out policy.
- Execute policy when: In this field, you have to select a pre-configured alarm using which the policy will get triggered. Since this is our first time configuring, select the Add new alarm option. This will pop up the Create Alarm dialog, as shown in the following screenshot:
Filling out and creating the alarm is a very simple process; for example, we want our Auto Scaling Group to be monitored based on the CPU Utilization metric for an interval of 5 minutes. If the average CPU Utilization is greater than or equal to 50 percent for at least one consecutive period, then send a notification mail to the specified SNS Topic (in this case, All-About-Dogs-Admins). You can verify your alarm's configuration by comparing it to the Alarm Graph as well. Once you are satisfied with your settings, click on Create Alarm.
- Take the action: With your basic alarm now set, you can further tell your policy what action it has to take if the particular threshold is breached. Select Add from the dropdown list and provide a suitable number of instances that you wish to add when a certain condition matches. For example, I have created a four-step scaling policy that first adds one instance to the group when the average CPU utilization is within a particular threshold range, such as 50-55 percent. Next, another instance is added when the CPU utilization increases even further to 55-65 percent, and so on so forth. You can add multiple such steps by selecting the Add step option, as shown in the following screenshot. Once the steps are added, your Increase Group Size policy should look something like the following:
- Instances need: With the steps added, the final field left is the Cooldown period. By default, this value is set to 300 seconds and can be changed as per your requirements. What is this cooldown period and why is it important? Well, a Cooldown period is kind of like a grace period that we assign to the Auto Scaling Group to ensure that we don't launch or terminate any more resources before the effects of previous scaling activities are completed. It is just a way of telling the Auto Scaling Group to wait for a short period of time before initiating another scaling event. Ideally, this field is very important and should not be taken for granted. There have been cases where the Auto Scaling activity goes into a loop-like condition where an instance is launched and terminated repeatedly, only because the cooling period and the ELB health check timeout did not match, so use this value with utmost care!
Once the Increase Group Size policy is created, you can conversely create and configure the Decrease Group Size policy as well. Follow the same steps by first creating and assigning an alarm that now triggers when the average CPU Utilization is less than or equal to 75 percent. Next, add the scaling steps that will remove one instance from the Auto Scaling Group at a time depending on the alarm's threshold ranges, such as removing one instance from the group when the average CPU utilization is between 65 percent and 75 percent and so on so forth. Once configured, click on Next: Configure Notifications to proceed with the next steps.
Notifications play a very important role in an Auto Scaling activity. You can basically configure your Auto Scaling Group to send notifications out to any particular endpoint, such as an e-mail address, whenever a specified event gets triggered, such as the successful launch of an instance, or a failure to launch an instance, and so on.
To configure notifications, all you need to do is create an SNS Topic and subscribe when it has to notify you in case a particular event is triggered. To create a new SNS Topic, simply click on the create topic option, as shown in the following screenshot. Fill in the SNS Topic Name as well as the required Email Addresses that you wish to subscribe to. In this case, I have already created an SNS Topic that will send notifications to the administrators whenever the instances successfully launch and terminate as well as when they fail to launch or terminate correctly:
You can optionally add more notifications to your Auto Scaling Group by selecting the Add notification option as well. Once done, click on Next: Configure Tags to proceed.
We do know the importance of tags and tagging from our previous chapters. Tagging helps us organize, manage, and identify our resources more effectively and efficiently by specifying one or more metadata in the form of a key and a value pair. Auto Scaling Groups too can be assigned tags using the Configure Tags page. Provide a suitable Key and Value for your new Auto Scaling Group. You can optionally even tag your instances that will be launched by your Auto scaling Group by selecting the Tag New Instances checkbox, as shown in the following screenshot:
Remember, you can add up to 10 tags for each Auto Scaling Group that you create as well as remove them at any time. Once you have tagged your Auto Scaling Group, move on to the final step of the process by clicking on the Review option.
Congratulations if you made it this far! You are almost done with your first fully functional Auto Scaling Group, but before you finish, review the settings once more and make sure that all the configuration settings and auto scaling values are correct. Once satisfied with the checks, click on Create Auto Scaling Group. The group will first check the number of desired instances that you have specified. In our scenario, we specified one as the desired value, so Auto Scaling will automatically launch one instance in either of the subnets that we specified during the group's configuration stage. You can view and verify the instance launch from the EC2 Management Dashboard as well. With the instance successfully launched, we now move on to an important part of verifying and actually testing the Auto Scaling configurations.
Once your Auto Scaling configuration and deployment is completed, you are now ready to go ahead and verify its validity. The first step to do so is by checking the instance deployment itself using the ELB dashboard. Select the Elastic Load Balancer option from the EC2 dashboard and select your ELB, as shown in the following screenshot. Next, select the Instances tab and make a note of the instance's Status column. It should display the status as InService as shown in the following screenshot. This basically means that the instance is associated with the ELB and that its health status is being continuously monitored by the ELB as well. In some cases, your Status column may show the status as Pending, so don't worry, give it a bit more time and the status should change back to InService again. You can optionally even view the number of instances launched as well as the overall health of your AZ by viewing the Instance Count as well as the Health columns highlighted in the following:
The next way to verify the Auto Scaling configuration as well as the ELB is by actually viewing the ELB's DNS name in a local web browser. If all goes well, you should see your application's landing page, or in this case the index.php page. Make a note of the ELB's public DNS name and copy it over to any web browser of your choice. Don't forget to append the /index.php landing path to the public DNS as well, as shown in the following screenshot:
Now in my case, the index.php file is nothing more than a simple PHP page that displays the IP address of the running underlying instance along with a simple welcome message.
The code for the index.php file is as follows:
<?php echo "Hello! I am a Web Server instance and my IP address is: ".$_SERVER['SERVER_ADDR']; ?>
This IP address is actually a part of the Web Server Subnet (us-west-2a) that we created back in Chapter 5, Building Your Own Private Clouds Using Amazon VPC. If you got it till this far, then you are on the right track! However, in case you don't see your application's landing page here, then I might suggest changing your instance's cooldown period as well as the ELB's Health Check period to suit your needs.
Once the verification is completed, you can go ahead and test your Auto Scaling configuration. To do so, simply SSH into your launched instance and increase its load using any load synthesizer tool you can find. I personally like Stress as well as Lookbusy as they are really simple and easy to use. For this scenario, I used Lookbusy to increase the instance's CPU Utilization to 60 percent. After a good 5 minutes of continuously loading the instance, the Increase Capacity scaling policy was triggered and a new instance was automatically created to balance out the application's load. You can verify this newly added instance by once again checking your Instances tab from the ELB dashboard. You should see two instances now, as shown in the following screenshot:
Similarly, gradually increase the CPU utilization of your instances from 60 percent to 70 percent and, finally, to 85 percent. If all goes well, you should see instances launch up as per your increase scaling policy. Once the instances are all added, gradually reduce the CPU utilization and watch the instances terminate automatically as well. This is one of the real reasons why I love AWS so much! It's simple and so easy to use! Once configured properly, your Auto Scaling service as well as ELB can run completely independently from all manual interventions, so you can concentrate on your business while the heavy lifting is taken care of by AWS itself!
Yup! You heard it right! You can additionally even suspend and resume an Auto Scaling activity in your Auto Scaling Group. Why would someone want to do that? Well, at times, you may want to run some minor configuration changes in your instances but don't want that to trigger an auto scaling event; or there may be a configuration issue in your Auto Scaling Group, or some problem with your application and you want to investigate it but without starting up the Auto Scaling process, and so on. In such cases, suspending an Auto Scaling process comes in really handy!
There is a small catch though! You cannot suspend or resume an Auto Scaling activity using the EC2 Management Console; you have to use the AWS CLI to get this done. Let us go through few commands and see how easy it is to put an Auto Scaling Group in a suspended state.
First up, let us describe our Auto Scaling Group using the AWS CLI. Type in the command as shown in the following and substitute the Auto Scaling Group's name with your own:
# aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names US-WEST-PROD-WEB-ASG-1
Now go ahead and suspend the Auto Scaling Group using the following command:
# aws autoscaling suspend-processes --auto-scaling-group-name US-WEST-PROD-WEB-ASG-1
Verify the status of your Auto Scaling Group by running the describe-auto-scaling-groups command once again. You should see its status shown as SUSPENDEDPROCESSES:
To resume an Auto Scaling Group, type in the following command as shown in the following:
# awsautoscaling resume-processes --auto-scaling-group-name US-WEST-PROD-WEB-ASG-1
Once again, check the status of your Auto Scaling Group to make sure that the process has indeed been initiated. Both the suspend-processes and resume-processes commands can be used to suspend and resume, respectively, the entire scaling activity in one go; however, if you wish to suspend or resume only a particular process from the entire Auto Scaling activity, then you will have to use the --scaling-processes attribute along with your suspend-processes and resume-processes commands.
For example, consider the following example that suspends an Auto Scaling's Health Check process:
# awsautoscaling suspend-processes --auto-scaling-group-name US-WEST-PROD-WEB-ASG-1 --scaling-processes HealthCheck
You can use the following set of processes with the suspend/resume commands: Launch, Terminate, HealthCheck, ReplaceUnhealthy, AZRebalance, AlarmNotification, ScheduledActions, and AddToLoadBalancer.
Note
Tip: To know more about each of these individual processes, refer to http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/US_SuspendResume.html.
With your process suspend and resume operations done, the final thing left to do is clean up your Auto Scaling Group. To delete your Auto Scaling Group, you first need to make sure that it has no running instances in it. To do so, simply set the minimum and maximum number of instances to zero! You can edit the group's size by using either the Auto Scaling Group Dashboard or the AWS CLI using the following set of commands:
First, set the minimum and maximum size to zero using the following command:
# awsautoscaling update-auto-scaling-group --auto-scaling-group-name US-WEST-PROD-WEB-ASG-1 --max-size 0 --min-size 0
Before you proceed with the deletion of the group, check the status of the group using the describe-auto-scaling-groups command. Make sure there are no instances running at all. Next, type in the following command to delete your Auto Scaling Group:
# awsautoscaling delete-auto-scaling-group --auto-scaling-group-name US-WEST-PROD-WEB-ASG-1
Once the Auto scaling Group is deleted, you can optionally go ahead and delete the Launch Configuration as well as the ELB using the following set of commands:
# awsautoscaling delete-launch-configuration --launch-configuration-name US-WEST-PROD-WEB-LC-1
Similarly, delete the ELB as well using the following command:
# awselb delete-load-balancer US-WEST-PROD-LB-01
To know more about the various additional Auto Scaling CLI commands and their usage, refer to http://docs.aws.amazon.com/cli/latest/reference/autoscaling/index.html.