A scaling activity is triggered when a scaling rule is executed or when an instance is manually added to or removed from a scaling group. After a scaling activity is triggered, the system performs a scale-in or scale-out action. This topic describes the process of a scaling activity, its status, and instance rollback.
Process of a scaling activity when ECS instances are automatically added or removed
- Check the health status and boundary conditions of the scaling group.
- Assign the activity ID and execute the scaling activity.
- Create ECS instances.
- Modify the number of instances in the scaling group.
- Assign IP addresses to the added ECS instances.
- Add the ECS instances to the whitelist of the ApsaraDB for RDS instance.
- Start the ECS instances.
- Add the ECS instances to the backend server group of the SLB instance, and set the weights of these ECS instances to the values specified by the active scaling configuration of the scaling group.
- The cooldown period starts after the scaling activity is complete.
- Check the health status and boundary conditions of the scaling group.
- Assign the activity ID and execute the scaling activity.
- Remove the ECS instances from the backend server group of the SLB instance.
- Stop the ECS instances.
- Remove the ECS instances from the whitelist of the ApsaraDB for RDS instance.
- Release the ECS instances.
- Modify the number of instances in the scaling group.
- The cooldown period starts after the scaling activity is complete.
Process of a scaling activity when ECS instances are manually added or removed
- Check the health status and boundary conditions of the scaling group, and check the status and types of ECS instances.
- Assign the activity ID and execute the scaling activity.
- Add the ECS instances to the scaling group.
- Modify the number of instances in the scaling group.
- Add the ECS instances to the whitelist of the ApsaraDB for RDS instance.
- Add the ECS instances to the backend server group of the SLB instance and set the weights of these ECS instances to the values specified by the active scaling configuration of the scaling group.
- The cooldown period starts after the scaling activity is complete.
- Check the health status and boundary conditions of the scaling group.
- Assign the activity ID and execute the scaling activity.
- The SLB instance stops forwarding traffic to the ECS instances.
- Wait 60 seconds, and remove the ECS instances from the backend server group of the SLB instance.
- Remove the ECS instances from the whitelist of the ApsaraDB for RDS instance.
- Modify the number of instances in the scaling group.
- Remove the ECS instances from the scaling group.
- The cooldown period starts after the scaling activity is complete.
Status of a scaling activity
Status | Description | Reference |
---|---|---|
Rejected | The scaling activity is rejected in the request phase and does not perform the scale-in or scale-out action. | Scenarios:
Result: The scaling activity fails the condition check and is rejected. No subsequent processes are followed. After the scaling activity is complete, the number of instances in the scaling group is still 100. |
Executing | The scaling activity passes the condition check and is in progress.
Auto Scaling automatically scales in or out ECS instances based on the maximum and minimum numbers of instances in the scaling group. |
Scenarios:
Result: The scaling activity passes the condition check and is performed. Only five ECS instances are automatically created. After the scaling activity is complete, the number of instances in the scaling group is changed to 100. |
Successful | The scaling activity is complete, and all ECS instances are added to or removed from the scaling group. | Scenario:
Result: The scaling activity passes the condition check and is performed. After the scaling activity is complete, the number of instances in the scaling group is changed to 100. |
Warning | The scaling activity is complete. At least one ECS instance is added to or removed
from the scaling group, while at least one ECS instance fails to be added to or removed
from the scaling group.
An ECS instance is considered to be added to the scaling group if the instance is created, added to the backend server group of the SLB instance, and then added to the whitelist of the ApsaraDB for RDS instance. If any step fails, the instance is not considered to be added to the scaling group. When an instance fails to be added to a scaling group, the instance will be rolled back. For more information, see ECS instance rollback. |
Scenario:
Result: The scaling activity passes the condition check and is performed to create five ECS instances. However, four ECS instances fail to be added to the backend server group and cannot be added to the scaling group because the quota for backend servers of the SLB instance is 200. After the scaling activity is complete, only one instance is added to the scaling group. The number of instances in the scaling group is 200. |
Failed | The scaling activity is complete, and all ECS instances fail to be added to or removed from the scaling group. | Scenario:
Result: The scaling activity passes the condition check and is performed. The five instances fail to be created due to insufficient resources. After the scaling activity is complete, no instances are added to the scaling group. The number of instances in the scaling group is still 95. |
ECS instance rollback
When some ECS instances fail to be added to a scaling group during a scaling activity, Auto Scaling prioritizes the integrity of the ECS instances over that of the scaling activity. Auto Scaling will roll back the ECS instances that fail to be added to the scaling group, but not the scaling activity. Auto Scaling uses Alibaba Cloud Resource Access Management (RAM) to call ECS API operations to create ECS instances. ECS instances that are rolled back are still charged after they are created and before they are automatically released.

When ECS instances in a scaling group are rolled back, the scaling group does not reach its expected capacity. This means that the scaling group cannot provide the required computing power and maintain monitoring metrics at the required values. In this case, you can use other methods to ensure that the scaling group can provide the required computing power for your business needs. For example, you can manually trigger scaling rules, manually add existing ECS instances to the scaling group, or configure scheduled or event-triggered tasks to trigger a scaling activity.