An autoscaling policy changes the desired capacity of an EC2 Auto Scaling group so instances are added or removed as demand changes. Capacity can follow a recurring schedule or respond to a CloudWatch alarm. For a blogging platform, a schedule could add instances around lunchtime; an alarm can react when an unexpectedly popular article raises CPU usage or load-balancer requests. section 17.2 section 17.0
Choose a trigger that matches the workload:
- Schedule capacity changes for predictable peaks and quiet periods. This is simpler to set up, but unexpected spikes may require spare capacity. section 17.2
- Use CloudWatch metrics and alarms for changing load. Step scaling can make different adjustments according to how far a threshold is exceeded; target tracking adjusts capacity toward a target such as 70% CPU utilization. Predictive scaling is intended for recurring patterns, while simple scaling is a legacy option. section 17.2.2
Scale queue workers
For workers processing jobs from an SQS queue, monitor the number of visible messages with a CloudWatch alarm. When queue length exceeds five, a step-scaling policy adds one instance to the Auto Scaling group. Define an opposite alarm and policy to remove capacity when the queue is empty. This example uses step scaling rather than target tracking because queue length does not correlate with the number of workers. section 17.3.2
Listing 17.8 A step-scaling policy adding one more instance to an Auto Scaling group
# [...]
ScalingUpPolicy:
Type: 'AWS::AutoScaling::ScalingPolicy' #1
Properties:
AdjustmentType: 'ChangeInCapacity' #2
AutoScalingGroupName: !Ref AutoScalingGroup #3
PolicyType: 'StepScaling' #4
MetricAggregationType: 'Average' #5
EstimatedInstanceWarmup: 60 #6
StepAdjustments: #7
- MetricIntervalLowerBound: 0 #8
ScalingAdjustment: 1 #9
# [...]
The CloudFormation listing shows the policy resource, its Auto Scaling group, a 60-second estimated instance warmup, and the step that adds one instance. section 17.3.2
Check the CloudWatch alarm state and EC2 instance list after applying a policy. In the queue-worker example, a load test produces 250 messages: an additional worker launches, then disappears after the work finishes. Scaling down avoids keeping that extra capacity when it is no longer needed. section 17.3.2
