Configuring Auto Scaling

All instances start in the healthy state. Instances are assumed to be healthy unless Auto Scaling receives notification that they are unhealthy. This notification can come from three sources: Amazon EC2, Elastic Load Balancing, and the SetHealthStatus action in the Auto Scaling API.

All Auto Scaling groups get Amazon EC2 health checks by default. If you choose to use the Elastic Load Balancing health check, Auto Scaling still bases health decisions on the Amazon EC2 health information in addition to the Elastic Load Balancing information. This means that an Amazon EC2 instance can still be marked unhealthy and replaced even if the Elastic Load Balancing considers it healthy. This could happen if Amazon EC2 determines that the hardware for the instance has become degraded, but the application is still passing Elastic Load Balancing health checks.

Once an instance has been marked unhealthy, it is almost immediately scheduled for replacement. It will never automatically recover its health. You can intervene manually by calling the SetInstanceHealth action to set the instance's health status back to healthy, but you will get an error if the instance is already terminating. Because the interval between marking an instance unhealthy and its actual termination is so small, attempting to set an instance's health status back to healthy with SetInstanceHealth is probably useful only for a suspended group. For more information about suspending and resuming processes, see Suspendable Processes.

Auto Scaling creates a new TerminateInstance scaling activity for an unhealthy instance and terminates it. Subsequently, a new LaunchInstance scaling activity brings a replacement instance into service.

Use UpdateAutoScalingGroup to create a health check on an existing Auto Scaling group. By default, Auto Scaling uses the Amazon EC2 health status for all Auto-Scaling-managed instances. To also use the Elastic Load Balancer's health check, set the HealthCheckType property of the group to ELB. Frequently, new instances need to warm up, briefly, before they can pass a health check. To provide ample warm-up time, set the HealthCheckGracePeriod property (--grace-period in the Auto Scaling CLI tool) of the group to match the expected startup period of your application:

% as-update-auto-scaling-group myGroup –-health-check-type ELB  –-grace-period 300 

When Auto Scaling checks health status, it ignores instances that have been in the InService state for less than the number of seconds specified by the HealthCheckGracePeriod.

Use DescribeAutoScalingGroups to return information about the instances in your Auto Scaling group. Instances have a HealthStatus field that is either Healthy or Unhealthy. Unhealthy instances are short-lived and won’t remain in your Auto Scaling group very long.

If you have your own health check system, you can integrate it with Auto Scaling. Use SetInstanceHealth to send the instance's health information directly from your system to Auto Scaling. Auto Scaling enforces the health check grace period by rejecting changes in health status for new instances that are still within the grace period.

% as-set-instance-health i-a1b2c3 –-status Unhealthy

Use PutScalingPolicy to specify a scaling adjustment and type for your group. The type specifies whether the adjustment is an absolute value, a constant increment, or a percentage of the current capacity. A positive value adds to the current capacity and a negative value removes from the current capacity. For example, if you want to scale up your group by 100 percent, set the increment to 100 and the type to PercentChangeInCapacity:

	Note
	When you are using Windows tools, you must use quotation marks.

# When scaling up, double my group's current capacity 
%as-put-scaling-policy my-group --name "double-group-size" 
--adjustment 100 --type PercentChangeInCapacity

And then use the corresponding policy to scale back down:

# When scaling down, decrease the capacity by 1 
%as-put-scaling-policy my-group --name "scale-down" 
"--adjustment=-1" --type Absolute

A successful PutScalingPolicy action returns an Amazon Resource Name (ARN), which serves as a unique name for the new policy. Subsequently, you can use either the ARN or a combination of the policy name and group name to specify the policy.

	Note
	All Auto Scaling names, including policy names, cannot contain the colon (:) character because colons serve as delimiters in ARNs.

Scaling policies also enable you to specify a custom cooldown period. Cooldown periods help to prevent Auto Scaling from initiating additional scaling activities before the effects of previous activities are visible. Because scaling activities are suspended when an Auto Scaling group is in cooldown, an adequate cooldown period helps to prevent a trigger from firing based on stale metrics. To use a different cooldown period than the default specified in the Auto Scaling group, use PutScalingPolicy, specifying your custom cooldown period. If the policy does not specify a cooldown, the group's default cooldown is used.

# Use a cooldown of 10 minutes when executing policy 'double-group-size' 
%as-put-scaling-policy my-group --name double-group-size 
--adjustment 100 --type PercentOfCapacity --cooldown 600    

Use ExecutePolicy to specify a policy you want to run. Auto Scaling scales your Auto Scaling group according to the specified policy. You can use ExecutePolicy to test a policy that you will later use with a CloudWatch alarm.

# Scale my-group as specified by scale-up-exponential policy 
      %as-execute-policy my-group --name "double-group-size" 

To force Auto Scaling to ignore a policy execution command while your Auto Scaling group is in cooldown, specify the HonorCooldown parameter when you make the ExecutePolicy call. Auto Scaling will reject your call with an appropriate error message if your group is in cooldown. The HonorCooldown flag is probably most useful for automated processes. You can use it to make sure that your custom scaling scripts respect cooldown periods.

Use DescribePolicies to list the policies attached to your Auto Scaling group.

# List all the policies attached to group my-group
% as-describe-policies my-group
POLICY  GROUP-NAME  POLICY-NAME         ADJUSTMENT    TYPE                  COOLDOWN
POLICY  my-group    double-group-size   100          PercentChangeInCapacity
POLICY  my-group    scale-down           -1          ExactCapacity
POLICY  my-group    scale-up-fast        10          ExactCapacity
POLICY  my-group    scale-up              1          ExactCapacity      

To determine not only which policies were executed, but also when they were executed, use DescribeScalingActivities. The cause parameter lists both the specific policy executed as well as the resulting activity.

Description => Launching a new EC2 instance: i-abcdefg
Cause => At  2010-07-06T18:32:02Z, user executed policy 'scale-up' changed desired capacity from 1 to 2. At  2010-07-06T18:32:13Z, an instance was started in response to a difference between desired and actual capacity.
         
Description => Terminating EC2 instance i-abcdefg
Cause => At  2010-07-06T19:44:10Z, user executed policy 'scale-down' changed desired capacity from 2 to 1. At  2010-07-06T19:44:35Z, an instance was terminated in response to a difference between desired and actual capacity.      

Use PutScalingPolicy with the name of the existing policy to update the scaling increment value and type. Note, however, that this action effectively deletes the previously existing policy and creates an entirely new policy with the settings you specify in the more recent call.

Use DeletePolicy with the name of the existing policy to delete the policy.

Use SuspendProcesses to suspend any policy executions on the specified Auto Scaling group.

# Suspend execution of policies
%as-suspend-processes my-group  

To resume policy executions, use ResumeProcesses.

# Suspend execution of policies
      %as-suspend-processes my-group    

	Note
	You can't suspend executions of individual policies.

Use Auto Scaling's PutScheduledUpdateGroupAction to configure scheduled actions. This call enables you to specify the date and time for each action, along with the minimum, maximum, and desired size of the group you want to take effect at that point in time. For example, if you knew you were having a book sale on April 5th, you would scale up in time for the sale:

# Make sure we scale up in time for the book sale on the 5th
% as-put-scheduled-update-group-action my-group –-name “book-scale-up”
-- time “2010-04-05T02:00:00Z” –-min 500 –-max 500

Then you would release excess capacity after the sale:

# The sale is over by the 6th, so shut down excess capacity
% as-put-scheduled-update-group-action my-group –-name “book-sale-over”
-- time “2010-04-06T00:00:00Z” –-min 100 –-max 100

Use DescribeScheduledActions to list all the activity plans attached to your Auto Scaling group. The listing displays activities that are still waiting to be executed. Once a scheduled action is completed, it is automatically deleted and, thus, no longer visible in the list of planned actions. Instead, an activity record for the running activity will be displayed with DescribeScalingActivities.

% as-describe-scheduled-actions my-group
NAME               TIME                   MIN   MAX    DESIRED 
wii-scale-up       2010-04-05T02:00:00Z   200   200
wii-sale-over      2010-04-06T00:00:00Z   100   100

Use PutScheduledUpdateGroupAction to update an Auto Scaling group's scheduled action. Make a request with this Auto Scaling API action with a preexisting scheduled action plan name to overwrite the existing plan with any new values you specify for minimum, maximum, and desired group size.

Use the SuspendProcesses action to suspend an Auto Scaling group's scheduled action. This action doesn't delete your scheduled actions. Make a request with this Auto Scaling API action with the name of the scheduled action plan you want deleted.

% as-suspend-processes my-group  
        

Use the DeleteScheduledAction action to delete an Auto Scaling group's scheduled action. Make a request with this Auto Scaling API action with the name of the scheduled action you want to delete.

	Note
	Scheduled actions are automatically deleted when they are executed.

You can determine whether instances were launched due to a scheduled action by examining the Cause field returned by DescribeAutoScalingActivities. Activities launched as a direct result of a scheduled action will have a reference to the specific action name in the cause field of the corresponding scaling activity. An example cause would be:

Cause => “At 2010-03-24T01:23:17Z scheduled action scale-up-come-morning set group desired capacity changing the minimum capacity from 100 to 200.  At 2010-03-24T01:24:12Z an instance was started in response to a difference between desired and actual capacity, increasing the capacity from 100 to 200.”