All Products
Search
Document Center

Auto Scaling:Coordinating scheduled and alarm tasks

Last Updated:Apr 16, 2026

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

Case 1: Scheduled scale-out is overridden by a target tracking rule

A user's scaling group is configured as follows:

  • Desired capacity is enabled.

  • Scheduled task: Increases the instance count to 200 at 08:00 every day.

  • Target tracking rule: Maintains CPU utilization at 60%.

Actual execution:

Time

Event

Desired capacity change

08:00:15

A scheduled task triggers, changing the desired capacity from 80 to 200.

80 → 200

08:00:28

The target tracking rule triggers a scale-out of 10 instances, overriding the desired capacity from 200 to 90.

200 → 90

Result: The scheduled target of 200 instances is overridden. The final capacity is only 90 instances, which is far below business requirements.

Case 2: Scheduled task is overridden by a target tracking rule

A user's scaling group is configured as follows:

  • Desired capacity is enabled.

  • Scheduled task: Uses a cron expression to scale out the number of instances in the group by a specific percentage.

  • Target tracking rule: Maintains memory utilization at a target value.

Actual execution:

Time

Event

Desired capacity change

12:00:08

A scheduled task triggers, changing the desired capacity from 20 to 40.

20 → 40

12:00:50

An alarm task triggers a scale-out of one instance, overriding the desired capacity from 40 to 21.

40 → 21

Result: The scheduled target of 40 instances is overridden. The final capacity is only 21 instances.

Case 3: Desired capacity set by a scheduled task is overridden by a simple scaling rule

A user's scaling group is configured as follows:

  • Desired capacity is enabled.

  • Scheduled task: Changes the desired capacity to 50.

  • Alarm task: Associated with a simple scaling rule.

Actual execution:

Time

Event

Desired capacity change

09:00:10

A scheduled task triggers, changing the desired capacity from 2 to 50.

2 → 50

09:00:22

An alarm task triggers a scale-out of 3 instances, overriding the desired capacity from 50 to 5.

50 → 5

Result: The scheduled target of 50 instances is overridden. The final capacity is only 5 instances.

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.

定时任务与报警任务协同配置-设计原则_v1

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.

  1. Log on to the Auto Scaling console.

  2. In the left-side navigation pane, click Scaling group management.

  3. Find the target scaling group and click its name to open the details page.

  4. Click the Scaling rules and tasks tab. In the Scheduled Tasks list, click Create scheduled task.

  5. 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.

  1. 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.

  1. Click the Scaling rules and tasks tab. In the Scaling Rules list, click Create scaling rule.

  2. 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

  1. 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.

  2. 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.

  3. 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 countdesired capacitymaximum 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.

Related topics