Auto Scaling Strategies & Triggers
Key concepts
Target tracking scaling
Step scaling
Scheduled scaling
Predictive scaling
Cooldown periods
Overview
Amazon EC2 Auto Scaling adjusts the number of EC2 instances in an Auto Scaling group (a managed collection of instances treated as one logical unit) so that capacity follows demand. A scaling policy is the rule that decides when to add or remove instances, and the trigger is the signal (a CloudWatch metric, a schedule, or a forecast) that fires that rule. The goal is to keep an application responsive during demand spikes while removing idle capacity to control cost.
This topic is high-yield on the SAA-C03 exam through "which scaling policy" scenarios. You should know the four policy types (target tracking, step, scheduled, and predictive), the metric-based triggers that drive them, how cooldown periods and instance warmup prevent over-scaling, and which policy fits a given pattern such as steady load, sharp bursts, predictable daily peaks, or recurring forecastable demand.
Match the Policy to the Demand Pattern
Use target tracking as the default for a smooth metric goal such as keeping average CPU at 50%. Use step scaling when you need graduated responses to alarm severity. Use scheduled scaling for known time-based changes, and add predictive scaling to provision ahead of recurring forecastable peaks.
Map the scenario to the trigger: a single metric target points to target tracking, alarm-based graduated steps point to step scaling, a known clock-based event points to scheduled scaling, and a recurring daily or weekly pattern points to predictive scaling. Remember that predictive scaling looks ahead with machine learning while the others react to current state, and that cooldown periods apply to simple and step scaling to avoid thrashing.
Key Concepts
Target Tracking Scaling
Hold a Metric at a Target
Target tracking scaling keeps a chosen metric at a target value by automatically adding or removing instances, much like a thermostat holds a temperature. You pick a metric such as average CPU utilization, the average number of requests per target on an Application Load Balancer (ALBRequestCountPerTarget), or average network in/out, then set a target number such as 50%. Auto Scaling creates and manages the CloudWatch alarms for you and adjusts the desired capacity to stay near the target. This is the recommended default policy for most workloads because it is simple to configure and self-correcting.
{
"TargetValue": 50.0,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ASGAverageCPUUtilization"
},
"EstimatedInstanceWarmup": 300,
"DisableScaleIn": false
}Step Scaling
Graduated Response to Severity
Step scaling adjusts capacity by different amounts depending on how far a metric has breached an alarm threshold. You define steps tied to a CloudWatch alarm: for example, add 1 instance when CPU is between 50% and 70%, add 2 instances between 70% and 90%, and add 3 instances above 90%. This gives a proportional reaction to severity that a single target cannot express. Step scaling continues to evaluate alarms even while a scaling activity is in progress, using an instance warmup setting rather than a cooldown to decide when new instances count toward the metric.
Target Tracking vs Step Scaling
| Dimension | Target Tracking | Step Scaling |
|---|---|---|
| Configuration | Pick a metric and target value | Define alarm thresholds and step adjustments |
| Alarm management | Created and managed automatically | You create the CloudWatch alarms |
| Response shape | Smooth toward a single target | Graduated by breach size |
| Best for | Most general workloads | Workloads needing tiered reactions |
| Throttling control | Built in via target logic | Instance warmup period |
Scheduled Scaling
Scale on the Clock
Scheduled scaling changes capacity at specific times that you know in advance, independent of any metric. You create a scheduled action that sets the minimum, maximum, or desired capacity on a one-time date or on a recurring cron schedule. A common use is raising desired capacity before a daily 9 AM business peak and lowering it after hours, or pre-scaling for a known sale event. Because it ignores live metrics, it provisions capacity ahead of demand for predictable, clock-driven changes.
# Scale up to 10 instances every weekday at 08:30 UTC
aws autoscaling put-scheduled-update-group-action \
--auto-scaling-group-name web-asg \
--scheduled-action-name weekday-morning-scaleup \
--recurrence "30 8 * * 1-5" \
--min-size 4 --max-size 20 --desired-capacity 10Predictive Scaling
Provision Ahead of Forecast Demand
Predictive scaling uses machine learning to analyze at least 24 hours of historical CloudWatch metric data (it needs 14 days for the best results) and forecasts load up to 48 hours ahead, then schedules capacity in advance so instances are warm before demand arrives. It is built for recurring patterns such as predictable daily or weekly cycles. You can run it in forecast-only mode to evaluate predictions before letting it act, and you can pair it with target tracking so predictive scaling handles the recurring baseline while target tracking absorbs unexpected real-time spikes.
Reactive vs Proactive Scaling
| Policy | Trigger Source | Timing | Best For |
|---|---|---|---|
| Target tracking | Live metric vs target | Reactive | General steady or variable load |
| Step scaling | CloudWatch alarm breach | Reactive | Tiered response to severity |
| Scheduled scaling | Date or cron time | Proactive (known) | Predictable clock-based changes |
| Predictive scaling | ML forecast of history | Proactive (learned) | Recurring daily or weekly cycles |
Cooldown Periods and Instance Warmup
Prevent Thrashing After a Scaling Activity
A cooldown period is a configurable pause (default 300 seconds) that applies to simple scaling policies. After a scaling activity, Auto Scaling waits out the cooldown before starting another simple-scaling activity, which prevents launching or terminating instances before the previous change has taken effect. Step scaling and target tracking do not use cooldowns; they use instance warmup, the time a newly launched instance needs before its metrics are stable enough to count toward the group aggregate. Setting an appropriate warmup stops new instances from being treated as overloaded while they are still booting, which would otherwise trigger excess scale-out.
Cooldown vs Instance Warmup
| Dimension | Cooldown Period | Instance Warmup |
|---|---|---|
| Applies to | Simple scaling policies | Step scaling and target tracking |
| Purpose | Pause before next scaling activity | Delay counting a new instance metric |
| Default | 300 seconds | Configurable per policy |
| Effect | Blocks back-to-back actions | Avoids false over-scaling during boot |
Best Practices
1. Default to target tracking
└── Pick one representative metric (CPU or ALBRequestCountPerTarget) and a target value
2. Use step scaling only when you need tiers
└── Define graduated adjustments for different breach severities
3. Add scheduled scaling for known events
├── Pre-scale before recurring business peaks
└── Combine with sale or batch-window calendars
4. Layer predictive scaling on recurring cycles
├── Run forecast-only first to validate predictions
└── Pair with target tracking for unexpected spikes
5. Tune instance warmup to match boot time
└── Set warmup to how long instances need before metrics stabilize
6. Set min, max, and desired deliberately
└── Max protects cost, min protects availabilityCommon Pitfalls
Pitfall 1: Using Scheduled Scaling for Unpredictable Spikes
Mistake: Configuring fixed scheduled actions to handle traffic that arrives at unpredictable times.
Why it fails: Scheduled scaling ignores live metrics, so it under-provisions during unexpected surges and wastes capacity when the surge does not arrive.
Correct Approach: Use target tracking or step scaling for metric-driven demand, and reserve scheduled scaling for genuinely clock-based changes.
Pitfall 2: Ignoring Instance Warmup
Mistake: Leaving warmup at zero so a booting instance reports high CPU and is immediately counted in the group metric.
Why it fails: New instances appear overloaded while they start, which triggers more scale-out and causes oscillation.
Correct Approach: Set instance warmup to the realistic time an instance needs before its metrics are representative.
Pitfall 3: Expecting Predictive Scaling to Work Immediately
Mistake: Enabling predictive scaling on a brand-new Auto Scaling group and relying on it from day one.
Why it fails: Predictive scaling needs at least 24 hours of history to produce a forecast and performs best with 14 days of data, so early forecasts are weak.
Correct Approach: Allow history to accumulate, run in forecast-only mode to validate, and keep a target tracking policy active to cover real-time demand.
Pitfall 4: Setting Cooldown Too Long
Mistake: Configuring a very long cooldown on simple scaling to avoid flapping.
Why it fails: A long cooldown blocks needed scale-out during a real spike, hurting performance and availability.
Correct Approach: Prefer target tracking or step scaling with tuned warmup; if you use simple scaling, keep cooldown close to the default and aligned with boot time.
Test Your Knowledge
An application has variable traffic, and the architect wants the simplest policy that keeps average CPU near 50% by adding or removing instances automatically. Which scaling policy fits best?
A reporting service has a predictable surge every weekday at 9 AM and is quiet overnight. The team wants capacity raised before the surge regardless of current metrics. Which approach is most appropriate?
An architect notices that during sharp load increases the group should add 1 instance for a moderate breach and 3 instances for a severe breach. Which policy expresses this graduated response?
Related Services
Quick Reference
Policy and Limit Summary
Scaling Quick Facts
| Item | Detail |
|---|---|
| Default cooldown (simple scaling) | 300 seconds |
| Predictive minimum history | At least 24 hours (14 days for best results) |
| Predictive forecast horizon | Up to 48 hours ahead |
| Target tracking common metric | Average CPU or ALBRequestCountPerTarget |
| Policies that use warmup | Step scaling and target tracking |
| Policies that use cooldown | Simple scaling |
Common CLI Commands
# Create a target tracking policy holding CPU at 50%
aws autoscaling put-scaling-policy \
--auto-scaling-group-name web-asg \
--policy-name cpu50 --policy-type TargetTrackingScaling \
--target-tracking-configuration file://cpu50.json
# Create a step scaling policy from a JSON definition
aws autoscaling put-scaling-policy \
--auto-scaling-group-name web-asg \
--policy-name step-cpu --policy-type StepScaling \
--step-adjustments file://steps.json
# Create a recurring scheduled action
aws autoscaling put-scheduled-update-group-action \
--auto-scaling-group-name web-asg \
--scheduled-action-name nightly-scaledown \
--recurrence "0 20 * * *" \
--min-size 1 --max-size 10 --desired-capacity 2
# Enable predictive scaling in forecast-only mode
aws autoscaling put-scaling-policy \
--auto-scaling-group-name web-asg \
--policy-name predictive --policy-type PredictiveScaling \
--predictive-scaling-configuration file://predictive.json