The shop is quiet at night and packed on Monster Mondays. A scaling policy changes the desired capacity for you.

Target tracking

Target tracking keeps one number near a target, here the group's average CPU at 50%:

{ "PredefinedMetricSpecification": { "PredefinedMetricType": "ASGAverageCPUUtilization" }, "TargetValue": 50 }

aws autoscaling put-scaling-policy --auto-scaling-group-name web-asg --policy-name cpu50 --policy-type TargetTrackingScaling --target-tracking-configuration file://cpu50.json

aws autoscaling describe-policies --auto-scaling-group-name web-asg --query "ScalingPolicies[].[PolicyName,TargetTrackingConfiguration.TargetValue]" --output text lists it.

• Out, fast: three minutes above the target, and it asks for ceil(instances × CPU / target), up to the maximum.
• In, slowly: fifteen minutes below 90% of the target, and it removes one. A group that stays big for a while after the load ends is working as designed.
• Warmup: a new instance is left out of the average while it starts. Target tracking has no cooldown; the group's default instance warmup is the damper:

aws autoscaling update-auto-scaling-group --auto-scaling-group-name web-asg --default-instance-warmup 60

Making load

Load should arrive the way customers do: through the load balancer, spread over every instance. One busy instance among idle ones barely moves the average. hey sends requests for a while: here 10 workers, 10 a second each, for five minutes:

hey -z 5m -c 10 -q 10 http://$DNS/

aws autoscaling describe-scaling-activities --auto-scaling-group-name web-asg --max-items 2 --query "Activities[].Cause" --output text

The cause names the alarm and the change: ...triggered policy cpu50 changing the desired capacity from 2 to 4.

Step scaling adds fixed amounts at alarm thresholds you set, and scheduled actions change the capacity at set times (every Monday at 8). Target tracking is the one to start with.