Scaling activities

Updated at:

Scaling activities are triggered when scaling rules execute or when you manually add or remove ECS or ECI instances. Auto Scaling automatically completes all resulting scale-out and scale-in actions, including instance creation, removal, and rollback.

Scaling activity workflow

Automatic scaling workflow

  • Automatic ECS instance creation

    1. Checks the health status and boundary conditions of the scaling group, such as the maximum instance count or minimum instance count.

    2. Assigns a scaling activity ID and executes the scaling activity.

    3. Creates ECS instances.

    4. Updates the instance count in the scaling group.

    5. Assigns IP addresses to the ECS instances.

    6. (Optional) Adds the ECS instances to the ApsaraDB for RDS instance whitelist.

    7. Starts the ECS instances and waits for them to start up.

    8. (Optional) Adds the ECS instances to the backend server group of a Classic Load Balancer (CLB) instance. Their weight is set to the value specified in the scaling configuration.

    9. The scaling activity is complete. The cooldown starts.

  • Automatic ECS instance removal

    1. Checks the health status and boundary conditions of the scaling group, such as the maximum instance count or minimum instance count.

    2. Assigns a scaling activity ID and executes the scaling activity.

    3. (Optional) Removes the ECS instances from the backend server group of the Classic Load Balancer (CLB) instance.

    4. Stops the ECS instances and waits for them to stop.

    5. (Optional) Removes the ECS instances from the ApsaraDB for RDS instance whitelist.

    6. Releases the ECS instances.

    7. Updates the instance count in the scaling group.

    8. The scaling activity is complete. The cooldown starts.

Manual scaling workflow

  • Manually adding ECS instances

    1. Checks the health status and boundary conditions of the scaling group, such as the maximum instance count or minimum instance count, and the status and type of the ECS instances.

    2. Assigns a scaling activity ID and executes the scaling activity.

    3. Adds the ECS instances to the scaling group.

    4. Updates the instance count in the scaling group.

    5. (Optional) Adds the ECS instances to the ApsaraDB for RDS instance whitelist.

    6. (Optional) Adds the ECS instances to the backend server group of a Classic Load Balancer (CLB) instance. The weight is set to the value specified in the active scaling configuration of the scaling group.

    7. The scaling activity is complete. The cooldown starts.

  • Manually removing ECS instances

    1. Checks the health status and boundary conditions of the scaling group, such as the maximum instance count or minimum instance count.

    2. Assigns a scaling activity ID and executes the scaling activity.

    3. (Optional) The Classic Load Balancer (CLB) instance stops forwarding traffic to the ECS instance. After 60 seconds, the ECS instance is removed from the backend server group of the CLB instance.

    4. (Optional) Removes the ECS instance from the ApsaraDB for RDS instance whitelist.

    5. Updates the instance count in the scaling group.

    6. Removes the ECS instance from the scaling group.

    7. The scaling activity is complete. The cooldown starts.

Scaling activity statuses

Scaling activities can have the following statuses.

Status

Description

Example

Rejected

The request for the scaling activity was rejected. No scale-out or scale-in action was performed.

Note

You can click View Rejection Reason next to the Rejected status to see why the activity was rejected.

Scenario:

  • The maximum instance count for a scaling group is 100.

  • The scaling group already contains 100 ECS instances.

  • A scaling rule requests the creation of 10 ECS instances.

Result: The scaling activity fails the condition check and is rejected. No subsequent actions are performed. After the activity ends, the instance count in the scaling group remains 100.

Running

The scaling activity passed the condition check and is in progress.

Auto Scaling adjusts the number of instances to add or remove based on the scaling group's maximum and minimum instance counts.

Scenario:

  • The maximum instance count for a scaling group is 100.

  • The scaling group contains 95 ECS instances.

  • A scaling rule requests the creation of 10 ECS instances.

Result: The scaling activity passes the condition check and proceeds, but the number of ECS instances to create is adjusted to 5. After the activity ends, the instance count in the scaling group is 100.

Successful

The scaling activity completed successfully, adding or removing all target ECS instances from the scaling group.

Scenario:

  • The maximum instance count for a scaling group is 100.

  • The scaling group contains 90 ECS instances.

  • A scaling rule requests the creation of 10 ECS instances.

Result: The scaling activity passes the condition check and is executed. After the activity ends, the instance count in the scaling group is 100.

Warning

The scaling activity is complete but only partially successful. At least one instance was added or removed, while at least one other failed.

For an ECS instance to be successfully added, all the following steps must complete: the instance is created, added to the Classic Load Balancer (CLB) backend server group, and added to the ApsaraDB for RDS instance whitelist. If any step fails, the instance fails to join the scaling group.

Note

A rollback is triggered when an ECS instance fails to join a scaling group. For more information, see ECS instance rollback.

Scenario:

  • A scaling group is associated with a Classic Load Balancer (CLB) instance, and newly created ECS instances are automatically added to its backend server group.

  • The quota for backend servers in the CLB instance is 200.

    Note

    For more information, see Usage notes.

  • The maximum instance count for the scaling group is 300.

  • The scaling group contains 199 ECS instances that are in the backend server group of the CLB instance.

  • A scaling rule requests the creation of 5 ECS instances.

Result: The activity passes the condition check and creates 5 ECS instances. However, because the CLB instance's backend server quota is 200, only one new instance can be added. The other four fail to join the backend server group and are rolled back. After the activity ends, the instance count in the scaling group is 200.

Failed

The scaling activity is complete, but no target ECS instances are added to or removed from the scaling group.

Scenario:

  • In the region where the scaling group resides, the instance type specified in the scaling configuration is out of stock.

  • The maximum instance count for the scaling group is 100.

  • The scaling group contains 95 ECS instances.

  • A scaling rule requests the creation of 5 ECS instances.

Result: The activity passes the condition check, but instance creation fails due to insufficient inventory. After the activity ends, the instance count in the scaling group remains 95.

ECS instance rollback

If not all ECS instances join a scaling group during a scaling activity, Auto Scaling rolls back only the failed instances, not the entire activity.

Important

When an ECS instance rollback occurs, the scaling group's instance count may fall short of the desired number, which can affect compute capacity or metric targets. To compensate, add instances through other methods, such as manually executing a scaling rule, manually adding existing ECS instances, or configuring a scheduled or event-triggered task.

  • Automatically added ECS instances

    When you use OpenAPI to elastically create ECS instances, Auto Scaling relies on Alibaba Cloud Resource Access Management (RAM). You are charged for any rolled-back instances from their creation time until they are automatically released.

    For example, if a scaling activity creates five ECS instances that must also join a load balancer's backend server group, and only two succeed, the three failed instances are automatically released. The activity completes with a status of Warning. On the Scaling Activities page, you can view the activity status (Successful, Warning, or Failed), instance counts, and other details. Click the activity to view the failure cause, such as a load balancer backend server quota being exceeded.

  • Manually added ECS instances

    If you manually add existing instances and some fail to join the group, Auto Scaling removes them from the scaling group but does not release (terminate) them.