Auto Scaling supports two auto-scaling methods: scheduled tasks and alarm tasks (which include target tracking rules). If you use both methods without proper configuration, an alarm task can override a scheduled scale-out, resulting in a lower-than-expected capacity. This topic describes the coordination mechanism between scheduled and alarm tasks and provides a best practice for avoiding scaling conflicts.
Problematic scenarios
If you enable desired capacity, scheduled tasks, and alarm tasks (such as target tracking rules) for a scaling group, a conflict can occur. A scheduled task triggers a scale-out at the specified time, but before the scale-out is complete, an alarm task can trigger and override the desired capacity set by the scheduled task. As a result, the scheduled scale-out does not take effect.
Typical cases
Root cause analysis
The root cause of these issues is the difference in execution mechanisms between scheduled and alarm tasks:
Dimension | Scheduled task | Alarm task |
Execution method | Modifies only the desired capacity value and does not directly trigger a scaling activity. | Immediately triggers a scaling activity and synchronously modifies the desired capacity. |
Effective time | After the desired capacity is modified, it takes 30 to 60 seconds to take effect. | Takes effect immediately. |
Conflict risk | During the delay before the change takes effect, the setting can be overridden by other tasks. | Updates the desired capacity based on the current instance count upon execution. |
Core problem: When a scheduled task only modifies the desired capacity, the operation lacks atomicity and does not result in an immediate capacity change. During the 30- to 60-second delay, an alarm task can trigger a scaling activity based on the current instance count, and then recalculate and override the desired capacity.
Best practice: Base and elastic capacity
Solution overview
Adopt a layered "base + elastic" capacity model that clearly separates the responsibilities of scheduled and alarm tasks:
Base capacity (managed by scheduled tasks): Use scheduled tasks to synchronously set the minimum instance count and desired capacity. This establishes a baseline capacity for peak business hours and prevents alarm tasks from scaling in below this baseline.
Elastic capacity (managed by alarm tasks): Use target tracking rules or other alarm tasks to dynamically add or remove instances on top of the base capacity, based on real-time load.

Procedure
The following example demonstrates the recommended configuration. Assume you need to scale out from a normal capacity of 10 instances to 50 instances at 08:00 every day for peak hours, and scale back to 10 instances at 22:00. In parallel, a target tracking rule maintains the CPU utilization at 60%.
Step 1: Create a scheduled scale-out task
Create a scheduled task that synchronously sets the minimum instance count and desired capacity at the beginning of peak hours. This ensures that the base capacity takes effect immediately and cannot be overridden by an alarm task.
Log on to the Auto Scaling console.
In the left-side navigation pane, click Scaling group management.
Find the target scaling group and click its name to open the details page.
Click the Scaling rules and tasks tab. In the Scheduled Tasks list, click Create scheduled task.
Create a scheduled scale-out task with the following settings:
Parameter
Value
Task name
scheduled-scale-up
Execution time
08:00 every day (or the start of your peak business hours)
Recurrence
Daily
Scaling method
Instance Number Setting
Minimum instance count
50
Desired capacity
50
Key configuration: For Scaling method, select Instance Number Setting and set both Minimum instance count and Desired capacity to 50. This ensures the scheduled task synchronously modifies both the minimum instance count and desired capacity of the group, preventing an alarm task from scaling in below 50 instances.
Step 2: Create a scheduled scale-in task
Create a scheduled scale-in task to pair with the scale-out task. This task restores the minimum instance count to its normal level after peak hours, preventing resource waste.
In the Scheduled Tasks list, click Create scheduled task and use the following settings:
Parameter
Value
Task name
scheduled-scale-down
Execution time
22:00 every day (or the end of your peak business hours)
Recurrence
Daily
Scaling method
Instance Number Setting
Minimum instance count
10
Desired capacity
10
Step 3: Configure a target tracking rule
Create a target tracking rule. This allows an alarm task to automatically handle elastic scaling on top of the base capacity set by the scheduled task.
Click the Scaling rules and tasks tab. In the Scaling Rules list, click Create scaling rule.
Create a target tracking rule with the following settings:
Parameter
Value
Scaling rule type
Target tracking rule
Metric type
Average CPU Utilization (ECS)
Target value
60%
The target tracking rule automatically adjusts the number of instances between the group's minimum and maximum instance counts based on CPU utilization. Because the scheduled task sets the minimum instance count to 50, the number of instances will not drop below 50, even if the CPU utilization is low.
Execution results
Time | Event | Minimum instance count | Desired capacity | Actual result |
08:00 every day | Scheduled scale-out task triggers. | 10 → 50 | 10 → 50 | Scaling out to 50 instances begins immediately. |
08:00 - 22:00 | The target tracking rule is active. | 50 | ≥50 | If CPU utilization exceeds 60%, the group scales out from the baseline of 50 instances. If it is below 60%, the group scales in to a minimum of 50 instances. |
22:00 every day | Scheduled scale-in task triggers. | 50 → 10 | 50 → 10 | Capacity returns to the normal level. Excess instances are gradually terminated. |
Other times | The target tracking rule is active. | 10 | ≥10 | The group scales elastically from a baseline of 10 instances based on CPU utilization. |
Configuration summary
For scheduled tasks, use the "instance number setting" scaling method and set both the minimum instance count and desired capacity, rather than modifying only the desired capacity.
Create scheduled tasks in pairs: A scale-out task should have a corresponding scale-in task. This ensures that the minimum instance count returns to its normal level after peak hours, avoiding resource waste.
Understand the relationship among the minimum instance count, desired capacity, and maximum instance count:
Scheduled tasks control the base capacity by setting the minimum instance count and desired capacity.
Alarm tasks and target tracking rules adjust capacity elastically between the minimum instance count and maximum instance count.
The system enforces the rule that minimum instance count ≤ desired capacity ≤ maximum instance count. This clear priority eliminates the need for extra conflict-avoidance mechanisms.
FAQ
Can alarm tasks scale in after a scheduled scale-out?
No. The scheduled task synchronously sets the minimum instance count. A target tracking rule will not scale in the group to a size below the minimum instance count. This is why it is critical to set the minimum instance count.
Should scheduled tasks modify only desired capacity?
This is not recommended. Modifying only the desired capacity has the following risks:
There is a 30- to 60-second delay before the change to desired capacity takes effect. During this window, an alarm task can override the value.
Even if the scale-out is successful, the minimum instance count is not adjusted. A target tracking rule might later reduce the instance count to a level below your expectation.
Should scheduled tasks set the maximum instance count?
Usually, no. The maximum instance count is typically kept at a fixed upper limit to prevent unlimited scaling during abnormal conditions. However, if your business requires different instance limits at different times, you can also adjust the maximum instance count in the scheduled task.
Do conflicts occur with simple scaling rules?
Yes, a conflict can still occur. Regardless of whether an alarm task is associated with a simple scaling rule, a step scaling rule, or a target tracking rule, it will override the desired capacity if it triggers during the scheduled task's delay window. The solution in this topic applies to all types of alarm tasks.