A scaling activity starts when a scaling rule runs or when an Elastic Compute Service (ECS) instance or elastic container instance is manually added to or removed from a scaling group. This topic covers the scaling activity process for each trigger type, the status values a scaling activity can reach, and what happens when ECS instances roll back.
All examples in this topic use an ECS-type scaling group.
How scaling activities work
Auto-triggered scaling activities
Scale-out: automatically create ECS instances
Check the health status and capacity limits of the scaling group (minimum and maximum instance counts).
Assign a scaling activity ID and start the scaling activity.
Create ECS instances.
Update the instance count in the scaling group.
Assign IP addresses to the new ECS instances.
(Optional) Add the IP addresses to the IP address whitelist of the associated ApsaraDB RDS instance.
Start the new ECS instances.
(Optional) Attach the new ECS instances to the associated Classic Load Balancer (CLB) instance as backend servers and set their CLB weights based on the scaling configuration.
Complete the scale-out and start the cooldown period.
Scale-in: automatically remove ECS instances
Check the health status and capacity limits of the scaling group (minimum and maximum instance counts).
Assign a scaling activity ID and start the scaling activity.
(Optional) Detach ECS instances from the associated CLB instance.
Put the ECS instances into the Stopped state.
(Optional) Remove the IP addresses of the ECS instances from the IP address whitelist of the associated ApsaraDB RDS instance.
Release the ECS instances.
Update the instance count in the scaling group.
Complete the scale-in and start the cooldown period.
Manually triggered scaling activities
Scale-out: manually add independent ECS instances
Run a health check to verify the scaling group status, capacity limits, ECS instance types, and ECS instance states.
Assign a scaling activity ID and start the scaling activity.
Add ECS instances to the scaling group.
Update the instance count in the scaling group.
(Optional) Add the IP addresses of the ECS instances to the IP address whitelist of the associated ApsaraDB RDS instance.
(Optional) Attach the ECS instances to the associated CLB instance as backend servers and set their CLB weights based on the scaling configuration.
Complete the scale-out and start the cooldown period.
Scale-in: manually remove ECS instances
Check the health status and capacity limits of the scaling group (minimum and maximum instance counts).
Assign a scaling activity ID and start the scaling activity.
(Optional) Stop forwarding traffic to the ECS instances. The ECS instances are detached from the CLB instance after 60 seconds.
(Optional) Remove the IP addresses of the ECS instances from the IP address whitelist of the associated ApsaraDB RDS instance.
Update the instance count in the scaling group.
Remove the ECS instances from the scaling group.
Complete the scale-in and start the cooldown period.
Scaling activity status
Monitor scaling activity status on the Activity tab of your scaling group in the Auto Scaling console. The Status column shows the current or final state of each activity.
| Status | What it means | Example |
|---|---|---|
| Rejected | The scaling request was rejected before any instances were added or removed. To see the reason, click View Rejection Reason in the Status column. | The scaling group has reached its maximum of 100 instances. A scale-out rule that adds 10 instances is triggered. The request is rejected and the group stays at 100 instances. |
| Executing | The scaling condition is met, but the actual change is clamped to stay within the group's capacity limits. Auto Scaling adjusts the target count to the nearest allowed boundary. | The scaling group maximum is 100 instances and the current count is 95. A scale-out rule adds 10 instances, but Auto Scaling creates only 5 to stay within the limit. The group ends at 100 instances. |
| Successful | The scaling activity completed and all instances were added or removed as requested. | The scaling group maximum is 100 instances and the current count is 90. A scale-out rule adds 10 instances. The group ends at 100 instances. |
| Warning | The scaling activity completed, but at least one instance failed and at least one succeeded. When a CLB backend server quota or similar limit is reached, Auto Scaling adds as many instances as the constraint allows and rolls back the rest. For more information about CLB quota limits, see Limits. | The scaling group maximum is 300 instances and the CLB backend server quota is 200. The current count is 199. A scale-out rule adds 5 instances. Only 1 instance attaches to the CLB successfully; the other 4 fail. The group ends at 200 instances. |
| Failed | The scaling activity completed, but all instances failed to be added or removed. The group count is unchanged. | The instance types in the active scaling configuration are unavailable in the region. A scale-out rule adds 5 instances. All instance creation attempts fail and the group stays at its previous count. |
An ECS instance is considered successfully added to a scaling group only when all three conditions are met: the instance is created, attached to the associated CLB instance, and its IP address is added to the IP address whitelist of the associated ApsaraDB RDS instance. If any condition fails, the instance is not considered successfully added.
ECS instance rollback
When one or more ECS instances fail to join a scaling group, Auto Scaling rolls them back while allowing the rest of the scaling activity to complete.
A rollback means the scaling group does not reach its intended capacity. To restore the expected instance count, trigger scaling manually — for example, by executing a scaling rule, adding independent ECS instances, or configuring a scheduled or event-triggered task.
Automatically added instances
If the scaling activity status is Warning, Auto Scaling releases the rolled-back instances. Billing for those instances stops when they are released.
If a RAM user calls API operations to create ECS instances, charges apply from creation until the instances are released.
For example, a scale-out rule adds 5 instances, all of which are created and submitted to the CLB backend server group. Only 2 instances attach to the CLB and join the scaling group. The other 3 fail and are automatically released.
Manually added instances
Auto Scaling removes rolled-back instances from the scaling group but does not release them. The instances continue to exist and are not deleted.