Scaling Policies: Target Tracking and Step Scaling

Static desired capacity works when load is constant, but real-world traffic fluctuates. Scaling policies let an Auto Scaling Group adjust the desired capacity automatically in response to metrics. AWS offers three main dynamic policy types: Target Tracking, Step Scaling, and Simple Scaling. For the SAA-C03 exam, target tracking and step scaling are the most important to understand.

Target Tracking Scaling works like a thermostat: you specify a metric and a target value, and AWS automatically calculates how many instances to add or remove to keep the metric at that target. For example, if you target 50% average CPU utilisation and utilisation climbs to 80%, ASG will add enough instances to bring CPU back to 50%. AWS manages both scale-out and scale-in actions for you.

Target Tracking supports several predefined metrics out of the box: ASGAverageCPUUtilization, ASGAverageNetworkIn, ASGAverageNetworkOut, and the ALB-specific ALBRequestCountPerTarget. For application-specific KPIs (queue depth, active connections, custom business metrics) you can supply a custom CloudWatch metric. Custom metrics give you much finer control over what drives your scaling decisions.

After a scale-out event, the ASG waits for a cooldown period (default 300 seconds) before evaluating another scale-out. This gives newly launched instances time to start handling traffic so the metric can stabilise. Similarly, a scale-in cooldown prevents premature termination immediately after adding capacity. For target tracking, AWS also recommends using a warm-up period so new instances don't skew the metric before they are fully initialised.

Step Scaling responds to CloudWatch alarms by adding or removing a specific number of instances based on how far the metric exceeds a threshold. You define multiple step adjustments—each step covers a metric range and specifies a capacity change. For example: if CPU is 60-70% add 1 instance; if CPU is 70-90% add 3 instances; if CPU exceeds 90% add 5 instances. This gives you graduated, proportional responses to varying load levels.

Step scaling requires a pre-existing CloudWatch alarm. The alarm monitors a metric and transitions to ALARM state when a threshold is crossed. The scaling policy then uses step adjustments referenced by the metric value relative to the alarm threshold. You can configure whether the adjustment type is ChangeInCapacity (add N), ExactCapacity (set to N), or PercentChangeInCapacity (scale by N%).

Each step adjustment has a MetricIntervalLowerBound and optionally an MetricIntervalUpperBound. The bounds are relative to the alarm threshold. If the alarm threshold is 60% CPU: LowerBound=0, UpperBound=10 fires when CPU is 60-70%; LowerBound=10, UpperBound=null fires when CPU exceeds 70%. This layered approach ensures large traffic spikes get an immediate, large capacity addition rather than waiting for multiple alarm cycles.

Simple Scaling is the predecessor to step scaling. Like step scaling it requires a CloudWatch alarm, but when triggered it adds or removes a fixed number of instances and then waits for the entire cooldown period to expire before evaluating again. This makes it sluggish under rapidly changing load. Step Scaling is preferred because it can continue to fire as conditions worsen without waiting for the full cooldown, and it responds proportionally.

Sometimes you want to prevent specific instances from being terminated during scale-in—for example, an instance running a long-running batch job. You can enable instance scale-in protection on individual instances via the console or CLI. When the ASG selects candidates for termination it skips protected instances. Remember to remove protection after the job completes, or the ASG may be unable to scale in at all if all instances are protected.

You can attach multiple scaling policies to one ASG. When both a target tracking and a step scaling policy exist, the ASG uses whichever policy recommends the larger scale-out action (most conservative). For scale-in, the policy that recommends removing the fewest instances wins. This prevents the system from oscillating between over and under-provisioned states. A common pattern is a target tracking policy for steady-state and a step scaling policy for emergency surge protection.

For most web applications, start with target tracking on CPU or request count per target—it requires minimal configuration and AWS manages the math. Use step scaling when you need graduated, proportional responses to varying load intensities. Always set a minimum capacity high enough to handle baseline traffic without relying on scale-out, since scaling takes time. Monitor the GroupDesiredCapacity and GroupInServiceInstances CloudWatch metrics to verify your policies are working as expected.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: Target Tracking Scaling automatically calculates and applies scale-out/in actions to keep a metric at a desired value (like 50% CPU), Step Scaling fires proportionally larger responses as a metric crosses higher thresholds using CloudWatch alarm-based step adjustments, and combining policies on one ASG is safe—ASG uses the most conservative scale-out and least aggressive scale-in recommendation. Next up we explore scheduled and predictive scaling for known traffic patterns.