Predictive Scaling on AWS, Google Cloud, and Azure

Predictive scaling is an autoscaling mode that analyses historical load, detects daily or weekly patterns, and adds capacity ahead of the demand it forecasts. Reactive policies such as target tracking wait for a metric to move and then respond; if your instances take minutes to boot and warm caches, users feel that lag at the start of every busy period. Predictive scaling closes the gap by launching instances before the curve rises.

It only helps when load is cyclical. All three providers say so, and none of them forecast one-off events: for a launch or a sale you still need scheduled capacity, as described in the event readiness playbook.

Amazon EC2 Auto Scaling

• Data needed: at least 24 hours of history before forecasting starts. It analyses up to the past 14 days.
• Forecast: an hourly capacity forecast for the next 48 hours, refreshed every 6 hours from the latest CloudWatch data. By default the group is scaled at the start of each hour.
• Modes: forecast only lets you compare predictions with reality; forecast and scale acts on them. A new policy starts in forecast only mode, and AWS suggests evaluating the forecast and its console recommendations before switching.
• Scale-in: predictive scaling does not scale in when it expects load to fall. You need a dynamic policy to remove capacity.
• Lead time: the SchedulingBufferTime property (Pre-launch instances in the console) launches instances ahead of the forecast so they are ready in time.
• Maximum capacity: forecasts are capped by the group’s maximum unless you allow the maximum to rise automatically. AWS warns that a raised maximum does not come back down on its own.

Amazon ECS services can also use predictive scaling through Application Auto Scaling.

Google Cloud Compute Engine MIGs

• Metric: predictive autoscaling works only with CPU utilization as the scaling signal.
• Data needed: 3 days of CPU-based autoscaling history before predictions start; until then the group scales on real-time data. It uses up to 3 weeks of load history.
• What it ignores: monthly, annual, and one-time events, and patterns shorter than 10 minutes.
• Lead time: the initialization period tells the forecaster how early to create VMs. With a 300 second initialization period, VMs are created 5 minutes ahead of forecast load. Google suggests predictive mode when initialization exceeds roughly 2 minutes and load follows daily or weekly cycles.

Azure Virtual Machine Scale Sets

• Metric: only Percentage CPU with the Average aggregation is supported.
• Data needed: a minimum of 7 days of history, using a rolling window of up to 15 days.
• Scale-in: predictive autoscale is scale-out only; standard autoscale rules handle scale-in. You must configure standard reactive autoscale conditions before enabling it.
• Forecast only: a forecast-only mode shows predicted versus actual CPU in charts covering the last seven days and the next 24 hours, without acting.
• Scope: available for scale sets in the Azure commercial cloud, not Azure Government.

Pitfalls to plan for

The common thread is that predictive scaling adds capacity and something else must take it away. On AWS and Azure that means keeping a dynamic scale-in policy in place. It also means watching the maximum: a forecast that keeps bumping the ceiling can leave a group permanently larger than intended if automatic maximum increases are enabled.

A second pitfall is a changed baseline. A new group, or one rebuilt from scratch, starts without history, so AWS needs 24 hours and Azure 7 days before forecasts exist.

ZopNight does not write predictive policies. Its adopt-or-replace flow can adopt an existing AWS predictive scaling policy without mutating it, and refuses to replace one, because the forecast model lives with the provider and cannot be reconstructed on removal. For the wider decision between policy types, see autoscaling fundamentals.