In my last column I discussed how to create an auto-scaling group that can automatically scale workloads in response to spikes in demand.
Although automatic scaling is relatively simple to set up, the entire process relies on alerts. Amazon Web Services (AWS), uses alerts to notify it when a workload must be scaled. I didn’t have the chance to talk about alerts in the previous column so I wanted to share how to create an alert to be used with an auto-scaling team.
You can use an existing alarm in the AWS console, but you can also create an alarm as part of the auto-scaling group generation process. Figure 1 shows that there are several alarms already in place, but you also have the option to add a new alarm.
[Click on the image to see a larger version.] Figure 1: You have two options. You can either use existing alarms or click Add New Alarm. This will create a new alarm. You will be taken to Figure 2’s dialog box if you choose to add a new alert. This dialog box allows you to send a notification when a predefined threshold is reached.
[Click on the image to see a larger view.] Figure 2: These options are available to create a new alarm. As you see the figure above, remember that auto-scaling groups can only be created for an instance. The Elastic Compute cloud (EC2) console can be used to create alarms specific for an instance. You could create an instance, set up one or more alarms, then create an auto-scaling group. You could either use the existing alarms from the instance to increase or decrease the group size or create new alarms for the sole purpose of changing the group’s size.
Any of these methods will work, but I recommend the Create Alarm dialog box shown in Figure 2. If you plan to use an alarm for group-scaling, however, it is best to use the dialog box shown in Figure 2. Take a look at Figure 3, below, to see why I recommend this. This is the interface that was used to create an instance-specific alert.
[Click on the image to see a larger version.] Figure 3: This is how it looks when you create an instance alarm. Comparing Figures 2 and 3, it is clear that you have the option to take action when you create an alarm for an incident. There are four options available: Recover This Instance; Stop This Instance; Terminate This Instance; and Reboot This Instance. These actions are not appropriate if you want to scale the instance. These actions are not shown in the dialog box when you create an alarm using the auto scaler. The auto scaler is performing an act, but that action is the scaling a workload.
If they were used, the actions in Figure 3 could cause problems with the scaling process. You should not include any actions in an alarm that will be used for auto-scaling purposes. The exception is sending a notification. Although you won’t need to send notifications every time, it is an option.
As explained above, it is up to the auto-scaling alarm to decide if the workload should be scaled. Administrators can decide what criteria warrant scaling the workload. As shown in Figure 4, the Create Alarm dialog box lets you create alarms based on CPU utilization as well as storage I/O or network traffic. After you have determined the metric you want to monitor, you can set a threshold for the alarm. You might create an alarm that triggers an increased group size when the average CPU is utiliz.

Oswald