Auto Scaling:Overview

Simple scaling rule

A simple scaling rule adds or removes a fixed number of instances, or sets the total instance count to a specific number. Use this rule when your workload changes are predictable and you want direct control over scaling increments.

If you attach a simple scaling rule to an event-triggered task, the task cannot execute until the scaling group's cooldown period ends.

Limitation: A single simple scaling rule cannot scale out and scale in at the same time. For bidirectional scaling based on a metric, use a target tracking scaling rule or a predictive scaling rule instead.

Step scaling rule

A step scaling rule is a multi-step scaling policy based on CloudMonitor event-triggered tasks. Each step defines a scaling adjustment triggered at a different metric threshold — for example, add 2 instances when CPU exceeds 60%, and add 5 more when it exceeds 80%. Each step behaves like a simple scaling rule.

Use this rule when you need fine-grained control over how aggressively the system scales at different load levels. If you want automatic metric-based scaling without defining thresholds manually, use a target tracking scaling rule instead.

Target tracking scaling rule

A target tracking scaling rule automatically adjusts instance count to keep a CloudMonitor metric close to a target value. Think of it like a thermostat: you set the target, and Auto Scaling continuously adjusts capacity to maintain it.

For example, to keep average CPU utilization at 60%, create a target tracking scaling rule with that metric and target value. Auto Scaling scales out when CPU exceeds 60% and scales in when it drops below.

When you create a target tracking scaling rule, Auto Scaling automatically creates and associates an event-triggered task with it. When the metric reaches the target, the event-triggered task executes the rule.

To delete the associated event-triggered task, delete the target tracking scaling rule first. Auto Scaling then deletes the event-triggered task automatically.

For more information, see Target tracking scaling rule.

Predictive scaling rule

A predictive scaling rule uses machine learning to forecast workload and automatically adjust the boundary values of your scaling group before demand arrives. Unlike the other rule types, it adjusts only the minimum and maximum instance counts — it does not directly add or remove instances.

Benefits

If your business has no specific pattern or you cannot accurately estimate business workloads, the boundary values configured when you created your scaling group may not meet actual business requirements. Predictive scaling rules help prevent the following issues:

• If the minimum number of instances in the scaling group is greater than the required number of instances, Auto Scaling purchases an excessive amount of computing resources, resulting in wasted resources and increased costs.

• If the maximum number of instances in the scaling group is less than the required number of instances, computing resources are insufficient to meet your business requirements, which affects service availability.

How it works

1. Auto Scaling analyzes at least 24 hours of historical monitoring data from your scaling group.

2. Machine learning predicts metric values for the next 48 hours.

3. Auto Scaling calculates the required instance count for each hour and creates 48 scheduled tasks accordingly.

4. Each scheduled task adjusts the boundary values at the predicted time.

5. Predictions are updated once per day.

Considerations

• A predictive scaling rule requires at least 24 hours of historical metric data before it can generate predictions.

• Changing the Target Value parameter clears the current prediction and generates a new one within 1 hour.

• Start with Predictive Mode set to Predict Only to review forecast accuracy before enabling Predict and Scale. For details, see View the prediction effect of a predictive scaling rule.

• When combining a predictive scaling rule with a target tracking scaling rule, use the same metric and target value for both rules. Mismatched metrics can cause frequent, unwanted instance count changes.