Target tracking scaling rules

A target tracking scaling rule integrates Auto Scaling with CloudMonitor to automatically scale instances in or out based on a specified metric target value, keeping your system stable under varying loads.

Introduction

A target tracking scaling rule is an advanced type built upon simple scaling rules. You select a CloudMonitor metric and specify a target value. Auto Scaling automatically calculates how many instances to add or remove to keep the metric at or near that target.

Note

Auto Scaling supports four types of scaling rules: step scaling rules, predictive scaling rules, simple scaling rules, and target tracking scaling rules. Overview of scaling rules.

Metrics and features

Metrics

The metric you choose must reflect the overall load of instances in the scaling group and change proportionally as the instance count changes.

The supported CloudMonitor metrics vary by scaling group type:

ECS scaling groups

API metric	Console metric
CpuUtilization	(ECS) Average CPU utilization
IntranetRx	(ECS) Average Inbound Internal Traffic
IntranetTx	(ECS) Average Outbound Internal Traffic
ClassicInternetRx/VpcInternetRx	(ECS) Average Inbound Public Traffic Note If the scaling group uses the Classic Network, this metric refers to the average inbound public traffic over the classic network. If the scaling group uses a VPC, this metric refers to the average inbound public traffic over the VPC.
ClassicInternetTx/VpcInternetTx	(ECS) Average Outbound Public Traffic Note If the scaling group uses the Classic Network, this metric refers to the average outbound public traffic over the classic network. If the scaling group uses a VPC, this metric refers to the average outbound public traffic over the VPC.
MemoryUtilization	(Agent) memory Memory utilization collected by the CloudMonitor agent.
LoadBalancerRealServerAverageQps	(ALB) QPS per Backend Server Note If you select this metric, you must also specify the corresponding ALB server group.

ECI scaling groups

API metric	Console metric
EciPodCpuUtilization	CPU Utilization
EciPodMemoryUtilization	Memory
LoadBalancerRealServerAverageQps	(ALB) QPS per Backend Server Note If you select this metric, you must also specify the corresponding ALB server group.

Features

Disable Scale-in: Prevents the rule from automatically removing instances. Enable the Disable Scale-in feature to use scale-out only.

To enable Disable Scale-in, on the Create Scaling Rule page, turn on the switch for Disable Scale-in. Alternatively, call CreateScalingRule and set DisableScaleIn to true.
- When Disable Scale-in is enabled, the rule creates only a scale-out event-triggered task. You control scale-in separately — for example, by using another event-triggered task that monitors a different metric and triggers a simple scaling rule.
- When Disable Scale-in is disabled, the rule manages event-triggered tasks for both scale-out and scale-in.
Instance Warmup Time: The time a newly added instance needs to initialize before contributing to the scaling group's metrics.

A new instance must complete service deployment, load balancer health checks, and data collection before reporting stable metrics. Set an appropriate Instance Warmup Time for the scaling rule. The scaling group rejects scaling rule executions during this period.

Effects of the warmup period:
- During warmup, the instance does not report data to CloudMonitor. CloudMonitor excludes warming-up instances from metric aggregation.
- After warmup, the instance reports data and is counted in the scaling group's capacity.
- Warming-up instances are excluded from the base capacity when calculating the next scale-out.
  
  Example: A scaling group has 2 instances. A scale-out adds 5 instances with a 300-second warmup. If another scale-out triggers during warmup, the calculation still uses 2 as the base.
- During scale-in, Auto Scaling sets a default cooldown time based on historical activity to prevent warming-up instances from being removed due to continuous scale-in activities caused by data latency.

Comparison with simple scaling rules

The following table compares target tracking scaling rules with simple scaling rules:

Item	Simple scaling rule	Target tracking scaling rule
User involvement	High. You customize scaling activities for on-demand resource usage, but must monitor activities and manage thresholds manually.	Low. Scaling is fully managed. You only specify the target metric value.
Adjustment granularity	Fixed. You configure a fixed number of instances to add or remove based on experience. The rule cannot react to real-time metric changes.	Precise. The rule calculates instance count from historical metrics and the target value, making small dynamic adjustments to stay near the target.
Adjustment process	Lacks fine-grained control: Data jitter: No instance warmup support. Newly added instances may report inaccurate metrics, causing unnecessary event-triggered tasks. Frequent instance count oscillation: Instance count and metric changes are not always synchronized. Event-triggered tasks may fire when the metric has not yet reflected the latest instance count change. Low instance stability: Maintaining a metric within a range typically requires both scale-out and scale-in rules for the same metric. Improper settings cause instance count fluctuation.	Offers flexible control: Stable data: Supports instance warmup. New instances enter a warmup period during which they do not affect metric aggregation, preventing over-provisioning. No instance count oscillation: Auto Scaling calculates the required instance count and triggers scaling to keep the metric near the target value. High instance stability: The rule operates within a dynamic stability range calculated from historical metrics.

Create a target tracking scaling rule

Notes

Before you create a target tracking scaling rule, note the following:

Only one target tracking scaling rule per metric type is allowed within a scaling group.
Creating a target tracking scaling rule automatically creates two CloudMonitor event-triggered tasks.
- You cannot modify or delete these tasks. You can only view, enable, or disable them. To delete the tasks, delete the corresponding target tracking scaling rule.
- The scale-out task uses an aggressive policy; the scale-in task uses a conservative policy.
  
  Example: With a 60-second sampling interval, scale-out triggers after 3 consecutive minutes exceeding the threshold; scale-in triggers after 15 consecutive minutes below the threshold.
- When triggered, Auto Scaling calculates the instance count based on historical metrics. Scale-out rounds up; scale-in rounds down.
  
  Example: If the calculation yields 1.5 instances to add, 2 are added. If 1.5 instances need removal, 1 is removed.
If metric data is insufficient, no scaling activity is triggered.
With a small number of instances, the metric value may deviate significantly from the target because each instance has a large impact on the aggregated metric.

Example: During scale-in, an event-triggered task may stay in the Alarm state without triggering activity if the calculated removal count is less than 1.

Procedure

Create a target tracking scaling rule by using the Auto Scaling console or an API operation:

Console: Select the scaling group and configure the rule. Configure scaling rules.
API: Call CreateScalingRule to create a target tracking scaling rule.