What is the expected number of instances-Auto Scaling(ESS)-阿里云帮助中心

The expected number of instances feature lets Auto Scaling automatically adjust the number of instances in a scaling group to a specified value. This feature also enables flexible execution of parallel scaling activities.

Overview

If the current number of instances in a scaling group deviates from the configured expected number, Auto Scaling automatically initiates a scaling activity to match the target value.

Benefits

Compared to a scaling group that does not use the expected number of instances feature, enabling this feature improves scaling group utilization and automates the execution of scaling activities. This helps resolve the following issues:

Note

For more information about the differences between scaling groups with and without the expected number of instances feature enabled, see Comparison of scaling groups with and without the expected number of instances feature.

For a scaling group without this feature, new scaling activities cannot start while another is in progress.
For example, if a scaling activity is in progress, a scaling activity triggered by a health check cannot be executed.
For a scaling group that does not use the expected number of instances feature, you must manually retry scaling activities if they fail.

Enable or disable the expected number of instances feature

You can enable or disable the expected number of instances feature in the following ways:

When you create or modify a scaling group, you can enable the expected number of instances feature by setting the Expected Number of Instances parameter. For more information, see Configure a scaling group.
Note
After you enable the expected number of instances feature for a scaling group, you can modify the current expected number of instances based on your business requirements.
For a scaling group that has the expected number of instances enabled, you can use an API to disable this feature. For more information, see ModifyScalingGroup - Modify a scaling group.

Key concepts

Before you use the expected number of instances feature, familiarize yourself with the following concepts:

Concept	Description
steady-state instance	An instance in a scaling group that is in the In Service, Protected, or Standby state.
parallel scaling activity	A scaling activity that can run concurrently with other parallel scaling activities. The following actions trigger parallel scaling activities: Manually executing a scaling rule, or a scheduled task executing a scaling rule. Manually adding or removing an instance. System tasks, such as expected number of instances checks, instance health checks, and min/max instance count checks.
non-parallel scaling activity	An exclusive scaling activity. When a non-parallel scaling activity is in progress, no other scaling activities can run. Any activity not explicitly defined as parallel is considered non-parallel. An event-triggered task automatically executes a scaling rule. Manually rebalancing the instance distribution on the Instances tab. The system automatically performs a spot instance supplementation task. Note When you create a scaling group, if you set the Scaling Policy to Cost Optimization Policy and enable Enable Supplemental Spot Instances, the system automatically performs a spot instance supplementation task 5 minutes before a spot instance is reclaimed. The scaling group proactively creates a new spot instance to replace the one that is about to be reclaimed.

Limitations

A scaling group with this feature enabled cannot run parallel and non-parallel scaling activities simultaneously.
The expected number of instances must be between the group's minimum and maximum instance counts, inclusive.

Instance count change rules

Besides manual adjustments, scaling activities can also change the expected number of instances. The specific change depends on how the scaling activity is triggered.

Scaling activity type	Trigger	Effect	Expected count change	Example
parallel scaling activity	Manually executing a scaling rule	Only modifies the expected number of instances. Auto Scaling waits for the expected number of instances check task to trigger scaling.	Number of steady-state instances ± number of instances to scale	Use case: Current expected number of instances: 3 Current number of steady-state instances: 2 A scaling rule is configured to create 4 ECS instances. Result: The expected number of instances changes to 6, but no ECS instances are created immediately. Auto Scaling waits for the expected number of instances check task to trigger scaling.
	Executing a scaling rule by a scheduled task	Only modifies the expected number of instances. Auto Scaling waits for the expected number of instances check task to trigger scaling.	Number of steady-state instances ± number of instances to scale	Use case: Current expected number of instances: 3 Current number of steady-state instances: 2 A scaling rule is configured to create 4 ECS instances. Result: The expected number of instances changes to 6, but no ECS instances are created immediately. Auto Scaling waits for the expected number of instances check task to trigger scaling.
	Manually adding instances	Immediately triggers scaling, and then modifies the expected number of instances.	Current expected number of instances + number of instances to add	Use case: Current expected number of instances: 3 Current number of steady-state instances: 2 Manually add 4 existing ECS instances. Result: Four ECS instances are added to the scaling group, and the number of steady-state instances becomes 6. Then, the expected number of instances changes to 7.
	Manually removing instances	Immediately triggers scaling, and then modifies the expected number of instances.	Current expected number of instances - number of instances to remove	Use case: Current expected number of instances: 3 Current number of steady-state instances: 2 Manually remove 1 ECS instance. Result: One ECS instance is removed from the scaling group, and the number of steady-state instances becomes 1. Then, the expected number of instances changes to 2.
	Min/max instance count check	-	You must manually set the expected number of instances.	Use case: Current maximum number of instances: 5 Current minimum number of instances: 0 Current expected number of instances: 3 Current number of steady-state instances: 2 You attempt to change the maximum number of instances to 1. Result: The modification fails because the current expected number of instances (3) would violate the new maximum of 1.
	Instance health check	Immediately triggers scaling.	Unchanged	Use case: Current expected number of instances: 3 Current number of steady-state instances: 2 One ECS instance is diagnosed as unhealthy. Result: The expected number of instances remains unchanged. The unhealthy ECS instance is removed from the scaling group, and the number of steady-state instances becomes 1. The scaling group detects a discrepancy between the expected number of instances and the number of steady-state instances and automatically runs an expected number of instances check task. This triggers a scaling activity to create 2 ECS instances.
	Expected number of instances check	Immediately triggers scaling.	Unchanged	Use case: Current expected number of instances: 3 Current number of steady-state instances: 2 Result: The expected number of instances remains unchanged. The scaling group detects a discrepancy between the expected number of instances and the number of steady-state instances and automatically runs an expected number of instances check task. This triggers a scaling activity to create one ECS instance.
non-parallel scaling activity	Executing a scaling rule by an event-triggered task	Immediately triggers scaling, and then modifies the expected number of instances.	Number of steady-state instances ± number of instances to scale	Use case: Current expected number of instances: 3 Current number of steady-state instances: 2 A scaling rule is configured to create 4 ECS instances. Result: A scaling activity is triggered to create 4 ECS instances, and then the expected number of instances changes to 6.

Note

For more information about how the expected number of instances changes when concurrent scaling activities are performed, see Parallel scaling activity examples and Non-parallel scaling activity example.

With and without expected instances

The following table describes the main differences between scaling groups with and without the expected number of instances feature enabled.

Item	With expected instances	Without expected instances
Maintenance	Automatic maintenance: The scaling group automatically scales to meet the expected number of instances. If a scaling activity fails, the system automatically retries it.	Manual maintenance: You must manually maintain the number of instances in the scaling group. If a scaling activity fails, you must also manually retry it.
Result of scaling activity	The result of a scaling activity varies based on how the activity is triggered: Executing a scaling rule (manually or via a scheduled task) only updates the expected number of instances. A subsequent background check then triggers the actual scaling to match this new number. When you manually add, remove, or delete an instance, or when an event-triggered task executes a scaling rule, the scaling group immediately triggers a scaling activity and automatically modifies the expected number of instances.	When you manually execute a scaling rule, a scheduled task executes a scaling rule, you manually add, remove, or delete an instance, or an event-triggered task executes a scaling rule, the scaling group immediately triggers a scaling activity to add or remove instances.
Parallel execution	The scaling group supports parallel scaling activities. For more information, see Parallel scaling activity examples.	The scaling group supports only one scaling activity at a time. A scaling activity can be time-consuming. During this period, you cannot adjust the number of instances in the scaling group.

Parallel scaling activities

After you specify an expected number of instances, the scaling group can run compatible scaling activities in parallel. The following examples demonstrate this behavior.

Example 1: Executing two scaling rules consecutively
Use case:
- Expected number of instances: 3
- Number of steady-state instances: 3
- Scaling rule add3 is configured to create 3 ECS instances.
- Scaling rule add1 is configured to create 1 ECS instance.
- You manually execute add3 and then immediately execute add1.
Result: After add3 is executed, the expected number of instances changes from 3 to 6 (3 steady-state instances + 3). Immediately executing add1 recalculates and sets the expected number to 4 (3 steady-state instances + 1), overriding the previous value. The combined effect of these parallel scaling activities is the creation of one ECS instance to meet the final expected number of 4. After the scaling activities are complete, the number of steady-state instances in the scaling group is 4.
The scaling group generates three scaling activity records, all with status Successful. Expanding the details of the first activity (described as Add "1" ECS ins...) shows that the activity was triggered because the user changed the Desired Capacity from 3 to 4, successfully creating 1 ECS instance, bringing the total capacity to 4.
Example 2: Executing a scaling rule while manually adding an instance
Use case:
- Expected number of instances: 3
- Number of steady-state instances: 3
- Scaling rule add1 is configured to create 1 ECS instance.
- You manually execute add1 and then immediately add one existing ECS instance.
Result: After add1 is executed, the expected number of instances changes from 3 to 4 (3 steady-state instances + 1). You can immediately add the existing ECS instance. This manual addition increases the number of steady-state instances to 4 and changes the expected number of instances from 4 to 5 (the current expected number of 4 + 1). The combined effect is the creation of one ECS instance and the manual addition of one existing ECS instance. After the scaling activities are complete, the number of steady-state instances in the scaling group is 5.
After executing add1 and manually adding an instance, the scaling activity list shows multiple parallel scaling activity records, all with status Successful. The activity details for the manual instance addition show that the activity was triggered by a request to attach a specified instance to the scaling group, with the Desired Capacity changing from 4 to 5, successfully adding 1 ECS instance.

Non-parallel scaling activities

After you specify an expected number of instances, the scaling group does not support running parallel and non-parallel scaling activities at the same time. The following example demonstrates this behavior.

Use case:

Expected number of instances: 1
Number of steady-state instances: 1
A scaling rule for an event-triggered task is configured to create 3 ECS instances.
Scaling rule add1 is configured to create 1 ECS instance.
The event-triggered task is triggered, and then you immediately and manually execute add1.

Result: The event-triggered task triggers a scaling activity, and the expected number of instances changes from 1 to 4. Because this is a non-parallel scaling activity, other scaling activities are blocked. Therefore, the manual execution of the add1 rule is rejected, and the expected number of instances remains 4. The effect of the non-parallel scaling activity is the creation of three ECS instances. After the activity is complete, the number of steady-state instances in the scaling group is 4.

The scaling activity triggered by the event-triggered task (Add 3 ECS instances) executed successfully, while the manually executed add1 scaling activity (Add 1 ECS instance) was Rejected with the message The current status of the specified scaling group does not support this action., indicating that the scaling group does not support executing non-parallel scaling activities while another scaling activity is in progress.