For Amazon EC2 Auto Scaling groups, predictive and dynamic scaling solve different parts of the capacity problem. Predictive scaling prepares for repeated demand patterns; dynamic scaling responds to current CloudWatch metrics. You can use both on one group, but their actions, limits, and capacity requests interact.

Predictive and dynamic scaling at a glance

Decision Predictive scaling Dynamic scaling
Signal Historical load with recurring daily or weekly patterns Current CloudWatch utilization or throughput metric
When it acts Forecasts hourly capacity for the next 48 hours, refreshed every six hours; by default, scale-out starts at the beginning of an hour Acts as current metrics and policy evaluation trigger a scaling decision; response depends on metric interval, evaluation, instance launch, and warmup
History needed At least 24 hours to start; up to 14 days are analyzed and two weeks improve pattern coverage No forecast-training period, but the chosen metric must be available and useful for the policy
Scale direction Scale-out from forecast demand; no forecast-based scale-in Target tracking and step policies can scale out and in according to their settings
Useful when Demand repeats, or instances need time to initialize before a known increase Demand is irregular, changes unexpectedly, or capacity should follow current utilization
Main limitation Cannot predict an unseen event, and may be inaccurate when instance capacity varies Cannot prepare capacity before a signal is published and evaluated; instances still need time to start

There is no fixed number of seconds or minutes that describes dynamic scaling response. It depends on the selected metric's publishing interval, the policy and alarm evaluation, instance launch time, and warmup. The forecast horizon is not a promise that predictive scaling will know about demand that has never appeared in its historical signal. AWS documents forecast timing and behavior and dynamic policy behavior.

What predictive scaling contributes

It anticipates recurring load

EC2 Auto Scaling analyzes up to 14 days of historical metric data, then generates an hourly capacity forecast for the next 48 hours and refreshes it every six hours. A group needs at least 24 hours of data to start forecasting. A complete two-week history is more useful for recognizing weekly cycles than the minimum. See AWS's forecasting, evaluation, and capacity-limit details.

It scales out from the forecast

In forecast-only mode, the policy changes no capacity and lets you compare its predictions with actual load. In forecast-and-scale mode, it can add instances for forecast increases, by default at the start of each hour. A pre-launch interval can start scale-out earlier. Forecast decreases do not remove instances. AWS's policy creation guide documents the console and CLI settings.

Choose it for repeatable patterns

Predictive scaling fits a service with predictable business-hour traffic, recurring batch windows, or other daily and weekly cycles. It is also useful when startup takes long enough that waiting for a dynamic signal would leave the service short on ready capacity.

What dynamic scaling contributes

It follows measured demand

Dynamic policies use current metric data to adjust desired capacity. AWS recommends target tracking for common utilization or throughput metrics because it changes group size toward a target and manages its alarms. Step scaling is useful when an application needs specific capacity changes for different alarm breaches. Metric collection and instance warmup still limit how quickly either policy can affect ready capacity; see AWS's dynamic scaling guidance.

It can scale in as well as out

A dynamic target-tracking policy can increase capacity when measured use rises and decrease it as measured use falls, subject to the group minimum and other active policies. It also gives the group a response to demand that departs from the predicted pattern.

Choose it for changing or irregular load

Dynamic scaling is the stronger fit when traffic has no stable daily or weekly cycle, or when queue depth, requests per target, or another current workload signal should drive capacity. Choose a metric that reflects useful work and responds predictably when the group gains instances.

Choose by workload pattern and response time

Use predictive scaling when demand repeats

Choose it when recent metric history shows recurring peaks that the service should prepare for, especially when instances take time to initialize. Before activation, compare forecast load and capacity with actual values over representative periods. The companion predictive scaling setup guide explains the evaluation and activation steps.

Use dynamic scaling for irregular demand

Choose it when traffic has no stable daily or weekly cycle, or when current utilization should control the group. Set targets from workload tests and observed service behavior, not a generic threshold. Keep enough baseline capacity for instances to launch and become ready; an Auto Scaling action does not guarantee immediate capacity.

Choose a metric tied to useful work

For HTTP services, request count per target can reflect work better than fleet-wide request count. For queue workers, backlog per instance can represent the remaining work for each worker. Confirm that a metric's units, aggregation, and publishing interval fit the policy. For custom predictive metrics, use a group-wide load metric and a per-instance scaling metric that falls as capacity increases; AWS explains the metric-pair requirements. Our EC2 Auto Scaling guide covers group limits and instance warmup.

Set targets from observed behavior

For proportional target tracking, prefer a metric that falls as useful capacity increases, such as average CPU utilization or requests per target. Monitor scaling activity and application health signals together; group capacity alone cannot show whether a request completed successfully.

How predictive and dynamic policies work together

Use the forecast as a capacity baseline

Predictive scaling can request capacity ahead of a recurring peak. A dynamic policy can request more when measured load exceeds the forecast and can request less when actual demand falls. This combines advance preparation with a response to current conditions, without requiring the two policies to use the same metric. AWS describes this predictive and dynamic policy interaction.

Understand the shared desired capacity

Each policy calculates the capacity it needs independently. The Auto Scaling group uses the largest capacity request, not the sum of the predictive and dynamic requests. A high forecast can therefore keep capacity up even when a dynamic policy is ready to scale in. If you use several target-tracking policies, EC2 Auto Scaling also scales in only when all enabled target-tracking scale-in conditions are met.

Both policies are constrained by the group's minimum and maximum capacity by default. Predictive scaling can optionally raise the maximum when forecast capacity approaches or exceeds it. A buffer is a percentage above predicted capacity, and the increased maximum does not automatically return to its original value. Keep the configured maximum as a deliberate cost and availability boundary; AWS documents the max-capacity settings and CLI fields. Choose the minimum from tested service needs, launch constraints, and availability requirements. See our EC2 Auto Scaling high-availability guide for capacity-floor considerations.