Amazon EC2 Auto Scaling predictive scaling forecasts recurring demand and can add instances before a familiar daily or weekly increase. It is useful when traffic follows repeatable patterns or instances take long enough to initialize that reactive scaling alone would arrive late. It cannot anticipate a one-off spike that has no signal in the history, and its active mode does not scale in. For a side-by-side decision guide, see predictive versus dynamic scaling.

When predictive scaling fits

Start with a workload whose load metric shows a repeatable time-of-day or day-of-week pattern. A forecast is less useful when traffic is irregular, the application recently changed, or the metric does not represent demand. Predictive scaling complements an EC2 Auto Scaling group and its dynamic policies; it does not replace a suitable baseline, health checks, or a response to unexpected load.

How predictive scaling produces a forecast

History, horizon, and refresh

The metric used by a policy needs at least 24 hours of data before EC2 Auto Scaling can produce its first forecast. It analyzes up to the previous 14 days to find recurring patterns and produces an hourly capacity forecast for the next 48 hours. Forecasts refresh every six hours with newer CloudWatch data. The 24-hour minimum starts forecasting; it does not guarantee that one day is representative. A full two weeks of history gives the service a better chance to observe weekly cycles. See AWS's forecast behavior and considerations.

Forecast only and forecast and scale

A predictive scaling policy starts in Forecast only mode. It generates forecasts but does not change group capacity. After reviewing the forecasts and console recommendations, you can switch the policy to Forecast and scale. In active mode, predictive scaling adds capacity when forecast demand rises. It does not remove capacity when the forecast falls.

You can create multiple forecast-only policies to compare metrics or target values for one group, but only one predictive policy can actively scale that group at a time.

Scale timing and instance warmup

By default, EC2 Auto Scaling applies the forecast for each hour at the start of that hour. The optional Pre-launch instances setting (SchedulingBufferTime in the API) can move a scale-out earlier so instances have time to boot and become ready. AWS strongly recommends setting the group's default instance warmup to reflect how long new instances take to serve traffic. Warmup also prevents dynamic policies from scaling in too soon after a scale-out.

Choose metrics and check the limits

Predefined and custom metrics

The console offers predefined metric pairs for average CPU utilization, network in, network out, and Application Load Balancer request count per target. The ALB option requires a target group attached to the Auto Scaling group. Use a custom metric pair when these signals do not describe the workload.

For custom metrics, use a load metric that represents demand across the group and a scaling metric that represents average utilization or throughput per instance. The scaling metric should fall roughly in proportion as capacity increases, and it should correlate with the load metric. Set the target in the units of that scaling metric. Custom metric policies require cloudwatch:GetMetricData; metrics you publish must have data points every five minutes or less. A metric specification can query up to 10 metrics, with each expression counting as one. AWS documents these custom metric requirements.

Requirements and limitations

Use predictive scaling in a supported AWS Region and allow at least 24 hours of metric history for the group. The forecast assumes instances provide comparable capacity. In a mixed-instance group, differences in vCPU count or network bandwidth can make a forecast inaccurate when those are the scaling signals. Review AWS's predictive scaling considerations and Region list before choosing a policy.

Create a forecast-only policy with the AWS CLI

Before creating the policy, confirm that the Auto Scaling group has the right minimum and maximum capacity, that its metric has enough history, and that its instances are represented by a suitable launch template or configuration. The example below uses the predefined group CPU metric. The target value is illustrative; choose a target from load tests and observed application behavior rather than copying a generic percentage.

CLI example

Save this as predictive-policy.json. If you omit Mode, the policy defaults to forecast-only mode. AWS's CLI policy examples document the supported fields and other metric choices.

{
  "MetricSpecifications": [
    {
      "TargetValue": 50.0,
      "PredefinedMetricPairSpecification": {
        "PredefinedMetricType": "ASGCPUUtilization"
      }
    }
  ]
}

Create the policy with put-scaling-policy:

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name my-asg \
  --policy-name predictive-cpu \
  --policy-type PredictiveScaling \
  --predictive-scaling-configuration file://predictive-policy.json

Replace my-asg and the target value with values for your group. To start active scaling after evaluation, add "Mode": "ForecastAndScale" at the top level of the JSON and run the same command to update the named policy. That change enables forecast-based scale-out.

Evaluate the forecast before enabling scale-out

Compare predictions with observed demand

Leave the policy in forecast-only mode while EC2 Auto Scaling builds a forecast. In the EC2 Auto Scaling console, review its recommendations and compare the load forecast with actual load, then compare predicted capacity with actual capacity and inferred required capacity. Check the periods that matter to the application, including recurring peaks and quieter periods. Recommendations are generated for forecast-only policies; starting in active mode can bias that comparison because the policy has already changed actual capacity.

Assess whether the forecast predicts the timing and size of recurring demand well enough for your service, and whether the requested capacity can be launched in time. Check instance startup and application readiness, the pre-launch interval, the group's capacity limits, and any launch constraints. There is no universal forecast error percentage that makes a policy safe for every workload.

Monitor after activation

When the forecast is suitable, enable forecast-and-scale mode and continue comparing predicted and actual load and capacity. Watch scaling activities and application signals as well as the policy graphs. If demand changes or forecasts stop matching the workload, return the policy to forecast-only mode while you investigate.

For scale-in, pair predictive scaling with a dynamic policy based on current load. AWS recommends target tracking for common utilization metrics; it can scale in as measured demand falls while predictive scaling prepares for a recurring rise. With both policies active, each computes its capacity request and EC2 Auto Scaling uses the larger request, so a forecast can keep capacity above what the dynamic policy alone would request. See AWS's policy-interaction guidance and our EC2 and CloudWatch monitoring guide for metric and alarm checks.

Keep capacity limits deliberate

By default, predictive scaling respects the Auto Scaling group's maximum capacity. The optional max-capacity behavior can raise that limit when forecast capacity approaches or exceeds it. Its buffer is a percentage above forecast capacity, and an increased maximum does not automatically return to its previous value; you must change the group limit yourself. Treat that option as a persistent capacity and cost decision, and keep it disabled unless the additional ceiling is intentional. AWS describes the maximum-capacity behavior and warning.

Set the minimum capacity from the service's measured baseline and availability needs. Scaling cannot guarantee that EC2 capacity, subnet addresses, quotas, or application dependencies will be available when a forecast requests more instances. Our high-availability guide explains how to set a floor that can carry the workload during failures.

Use forecasts as one scaling signal

Predictive scaling is most useful when the forecast captures a repeated workload pattern and capacity needs lead time. Start with forecast-only mode, inspect both load and capacity predictions against actual behavior, and activate scale-out only after the results fit the service's needs. Use a dynamic policy for unexpected changes and scale-in, and keep the group's limits aligned with availability and cost requirements.

FAQs

Does predictive scaling scale in?

No. Forecast-and-scale adds capacity for forecast increases but does not remove capacity for forecast decreases. A dynamic policy using current metrics can handle scale-in.

How much history does it need?

At least 24 hours of metric data is needed to start forecasting. The service analyzes up to 14 days, and two weeks of history helps it identify recurring weekly patterns.

How should I evaluate a policy?

Keep it in forecast-only mode and compare the load and capacity forecasts with actual values and the console recommendations over representative workload periods. Move to active scale-out only when the forecast timing and capacity suit your application.