Scheduled Scaling and Predictive Scaling

Dynamic scaling policies (target tracking and step scaling) are reactive—they respond after a metric threshold is already breached. For known, predictable traffic patterns like business-hours peaks, end-of-month batch runs, or Black Friday sales, reactive scaling is too slow because instances take minutes to launch and warm up. Scheduled Scaling and Predictive Scaling address this by proactively adjusting capacity before the load arrives.

A Scheduled Scaling Action changes the ASG's min, max, or desired capacity at a specific date and time, or on a recurring cron schedule. This is ideal when you know exactly when load will increase—for example, pre-warming before a planned marketing event, or scaling down overnight when traffic is minimal to save costs. Scheduled actions override the current desired capacity at the specified time.

Scheduled actions use Unix cron format: minute hour day-of-month month day-of-week. All times are in UTC. Common patterns include 0 8 * * 1-5 (weekday mornings at 08:00 UTC) for scale-up and 0 20 * * * (every night at 20:00 UTC) for scale-down. You can create multiple scheduled actions on the same ASG, for example one to scale up and one to scale back down each day.

Scheduled actions can be one-time (executed once at a specific start time) or recurring (executed on a cron schedule). A one-time action is perfect for a known future event like a product launch. A recurring action handles regular patterns like daily or weekly traffic cycles. You can also set a start time and end time on a recurring action to automatically enable and disable a schedule within a date range.

Scheduled actions and dynamic scaling policies can coexist. A scheduled action sets a new baseline capacity at its scheduled time. After that, dynamic policies (target tracking or step scaling) continue to adjust capacity within the updated min/max bounds. For example: a morning scheduled action sets min=4, desired=8; during the day, target tracking scales up to 15 under load; the evening scheduled action then resets to min=2, desired=2.

Predictive Scaling uses machine learning to analyse historical load patterns from CloudWatch metrics and forecast future capacity needs. It proactively schedules scale-out actions before the predicted load arrives—typically 5-60 minutes in advance. Predictive scaling is best for workloads with repeating daily or weekly traffic cycles. It continuously updates its forecast as it collects more data.

You enable predictive scaling by attaching a PredictiveScaling policy to your ASG. You specify the metric pair: a load metric (what drives scaling, like CPU or ALB request count) and a scaling metric (what you track on each instance). AWS then forecasts the load metric and computes the number of instances needed to keep the scaling metric at your target value.

Predictive Scaling has two modes: ForecastOnly generates forecasts without actually changing capacity—useful for reviewing predictions before committing to automated scaling. ForecastAndScale both generates forecasts and automatically applies capacity changes. Start with ForecastOnly for a few weeks to validate accuracy, then switch to ForecastAndScale. AWS requires at least 24 hours of metric data before generating the first forecast.

Predictive Scaling fires scale-out actions in advance, but you can configure a SchedulingBufferTime to pre-warm instances even earlier. A SchedulingBufferTime of 5 minutes means capacity is added 5 minutes before the forecast predicts it is needed. You can also set a MaxCapacityBuffer to allow ASG to scale beyond the forecasted need by a percentage, providing a headroom buffer against forecast inaccuracy.

The recommended pattern for variable but predictable workloads is to combine both: Predictive Scaling handles the expected cyclical load by pre-positioning capacity, while Target Tracking Scaling handles unexpected spikes that exceed the forecast. Together they provide both proactive and reactive coverage. The ASG safely applies the most conservative scale-out recommendation across both policies.

Use Scheduled Scaling when traffic spikes are fully predictable and you know exact times (event-driven or business-hour patterns). Use Predictive Scaling when patterns repeat but exact timing may shift—ML learns the pattern automatically. Use Target Tracking as the always-on dynamic safety net for unexpected load. For completely random load, rely on target tracking or step scaling alone. The SAA-C03 exam often asks you to pick the most operationally efficient approach, and predictive scaling wins for recurring cyclical workloads.

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

In this lesson you learned: Scheduled Scaling uses cron expressions to change ASG capacity at known times, ideal for predictable events or recurring business-hour patterns, Predictive Scaling uses machine learning on historical CloudWatch data to proactively scale before load arrives, and combining Predictive + Target Tracking provides both proactive and reactive coverage for the most resilient scaling strategy. Next up we explore Instance Refresh and Lifecycle Hooks for controlled deployments.