Auto Scaling Policies: Target Tracking, Step, Simple

What Are Auto Scaling Policies?

Auto Scaling policies define how an Auto Scaling group (ASG) adjusts its desired capacity in response to changes in demand. They are the core mechanism for implementing elasticity in AWS. The three policy types—Target Tracking, Step, and Simple—differ in how they react to CloudWatch alarms and how they calculate the new desired capacity.

Target Tracking Scaling Policy

Target Tracking is the simplest and most intelligent policy. You select a predefined metric (e.g., average CPU utilization, request count per target, or average network in/out) and set a target value. AWS automatically creates the necessary CloudWatch alarms and calculates the scaling adjustment to keep the metric close to the target. It uses a proportional-integral-derivative (PID) controller internally to smooth out adjustments and avoid oscillations. - How it works: The policy continuously monitors the metric. When the metric deviates from the target, it computes a new desired capacity using the formula: desired_capacity = current_desired_capacity * (current_metric_value / target_value). This is a simple proportional calculation, but AWS applies additional logic to prevent overcorrection. - Key parameters: - TargetValue: The target value for the metric (e.g., 50 for CPU utilization). - DisableScaleIn: If true, the policy will only scale out, not in. Default is false. - CustomizedMetricSpecification: Allows you to use a custom metric instead of predefined ones. - Cooldown: Target Tracking does not use a cooldown period. Instead, it has a built-in stabilization period (default 300 seconds) during which it avoids scaling after a significant change. This prevents rapid oscillations. - Limitations: You can have only one Target Tracking policy per ASG at a time (though you can have multiple policies of different types). The metric must be a valid CloudWatch metric that represents the load on the instances.

Step Scaling Policy

Step Scaling gives you more control by defining how many instances to add or remove based on the magnitude of the alarm breach. You create a CloudWatch alarm and then define step adjustments. Each step has a lower and upper bound (or just one bound) for the metric deviation and a corresponding scaling adjustment (absolute or percentage). - How it works: When the alarm enters ALARM state, the policy evaluates which step the current metric value falls into and applies the associated adjustment. It then waits for a cooldown period before responding to another alarm breach. - Key parameters: - AdjustmentType: Can be ChangeInCapacity, ExactCapacity, or PercentChangeInCapacity. - StepAdjustments: A list of steps, each with a MetricIntervalLowerBound, MetricIntervalUpperBound, and ScalingAdjustment. - Cooldown: A cooldown period (seconds) after a scaling activity before the policy can respond again. Default is 300 seconds. - Important behavior: If the metric continues to breach after a scaling action, the policy will wait for the cooldown to expire and then re-evaluate. This can lead to slower response for rapid spikes. - Example: Suppose you have a step policy for CPU > 80%:

Simple Scaling Policy

Simple Scaling is the original scaling policy. You create a CloudWatch alarm and specify a single scaling adjustment (e.g., add 1 instance) and a cooldown period. When the alarm breaches, the policy executes the adjustment and then waits for the cooldown to expire before it can respond to another alarm breach. If the alarm remains in ALARM state after the cooldown, the policy will execute again. - How it works: Simple Scaling is essentially a one-shot action. It does not consider the magnitude of the breach; it always applies the same adjustment. - Key parameters: - AdjustmentType: Same as step scaling. - ScalingAdjustment: The amount to change capacity. - Cooldown: A mandatory cooldown period (default 300 seconds). - Limitations: Simple Scaling is prone to oscillations if the metric fluctuates around the threshold. It also cannot handle multiple alarms gracefully—you need separate policies for scale-out and scale-in.

Comparison of Policy Behaviors

CloudWatch Alarm Integration

All scaling policies rely on CloudWatch alarms. For Target Tracking, AWS automatically creates two alarms (one for scale-out, one for scale-in) with appropriate thresholds. For Step and Simple, you create the alarms manually. The alarm must be in ALARM state for the policy to trigger. Note that for Step Scaling, the alarm's metric must be the same as the one used in the step adjustments (usually the same metric, but you can use different metrics for different steps if you create multiple alarms).

Cooldown and Warm-Up

Instance Refresh and Health Checks

Auto Scaling policies work independently of instance refresh or health checks. However, if an instance is marked unhealthy and replaced, the policy may see a temporary dip in capacity and trigger scale-out. To avoid this, use health check grace periods.

CLI and API Examples

Interaction with Other Services

Best Practices

Enterprise Scenario 1: E-commerce Web Tier

A large e-commerce platform uses Target Tracking scaling for their web tier based on average CPU utilization. They set the target to 40% to ensure enough headroom for traffic spikes. During Black Friday, traffic surges 10x. The Target Tracking policy continuously adjusts capacity, launching hundreds of instances. The stabilization period prevents overreaction when a new instance starts and initially has low CPU. Without Target Tracking, they would have used Step Scaling, but the PID-like control of Target Tracking provides smoother scaling. They also use a custom metric for request count per target to handle sudden shifts in traffic patterns.

Enterprise Scenario 2: Batch Processing with Step Scaling

A data processing company runs batch jobs that cause CPU to spike to 90% for short periods. They use Step Scaling with two steps: if CPU exceeds 80% but less than 95%, add 2 instances; if CPU exceeds 95%, add 5 instances. This allows them to respond proportionally. They set a cooldown of 120 seconds because instances become operational quickly. The downside is that if CPU oscillates around 80%, they may see repeated scaling actions. They mitigated this by using a longer alarm evaluation period (3 periods of 60 seconds) to avoid flapping.

Enterprise Scenario 3: Legacy Application with Simple Scaling

A legacy application has predictable load patterns: every morning at 9 AM, traffic increases by about 20%. They use Simple Scaling with a scheduled action to add 2 instances at 8:45 AM, and a separate Simple Scaling policy to remove instances when CPU drops below 20% at night. They use a cooldown of 600 seconds to avoid premature scale-in. However, they found that Simple Scaling was insufficient for handling unexpected spikes because it only adds a fixed number of instances. They migrated to Target Tracking for better responsiveness.

Common Misconfigurations