Step Scaling: Tiered Adjustments for Bursty Load

Step scaling is an autoscaling policy that changes capacity by different amounts depending on how far a metric has breached an alarm threshold. Instead of one fixed response, you write a small table: a modest breach adds a little capacity, a large breach adds a lot. On Amazon EC2 Auto Scaling it sits alongside simple scaling (one adjustment, then a cooldown) and target tracking (the provider manages the alarms for you).

How a step policy is evaluated

You create a CloudWatch alarm yourself, with a metric, a threshold, and the number of evaluation periods that count as a breach. When the alarm fires, EC2 Auto Scaling applies whichever step matches the current metric value, and it keeps applying steps on further breaches until the alarm returns to OK.

AWS’s own example shows the shape: scale out by 10 instances at 60%, by 30 at 75%, and by 40 at 85%. Each step adjustment has a lower bound, an upper bound, and an adjustment, with the bounds expressed relative to the alarm threshold. The ranges cannot overlap or leave gaps, and only one step may have an open-ended lower bound (negative infinity) and only one an open-ended upper bound (positive infinity).

The three adjustment types

• ChangeInCapacity adds or removes a fixed number of units. With 3 instances and an adjustment of 5, the group goes to 8.
• ExactCapacity sets the group to a value. With 3 instances and an adjustment of 5, the group goes to 5.
• PercentChangeInCapacity scales by a percentage of current capacity. With 10 instances and 10%, the group goes to 11. Non-integer results are rounded: values above 1 round down (12.7 becomes 12), and values between 0 and 1 round up to 1, so a small percentage always moves at least one instance.

A capacity unit normally means one instance, unless you use instance weights.

Warmup, and why steps do not stack

Each new instance has a warmup period during which it is not counted in the group’s aggregated metrics. While instances are warming up, the policy only scales out further if the metric from the instances that are already warm exceeds the alarm threshold. Instances still warming up count toward desired capacity, so repeated breaches within the same step produce a single scaling activity rather than a pile of them.

AWS’s worked example: a group at 10 instances with steps of +10% at 60 and +30% at 70. At 60 it adds one instance. If the metric reaches 70 while that instance is still warming, the policy wants 3 more (30% of 10) but desired capacity is already 11, so it adds 2, for 13. While any scale-out is in progress, scale-in initiated by policies is blocked until warmup completes. AWS recommends using the group’s default instance warmup rather than a per-policy value, so one setting governs all policies.

When to choose step over target tracking

AWS’s guidance leans toward target tracking for proportional metrics such as average CPU or requests per target, and toward step scaling when you want greater control over scale-in, because target tracking deliberately scales in gradually. Step scaling also fits metrics that do not move in proportion to capacity, where you want to encode the response explicitly.

The cost is ownership. You maintain the alarms, the thresholds, and a separate scale-in policy, and a badly shaped table can oscillate. Keep scale-out and scale-in on the same metric where you can, and leave a gap between their thresholds.

Adopting existing step policies

If you already run step policies and later bring the group under management, the configuration has to survive the transition. ZopNight’s adopt-or-replace flow can adopt an existing policy without changing anything in AWS, and it refuses to replace step scaling policies with more than two step adjustments, because it cannot reconstruct them exactly on removal; those stay adoptable as-is. ZopNight writes both target tracking and step policies to Auto Scaling groups through PutScalingPolicy. For how the policy types fit together, see autoscaling fundamentals, or the Auto Scaling group integration page.