Help Center/ Auto Scaling/ User Guide/ Instance Scaling/ Scaling Actions
Updated on 2026-01-07 GMT+08:00
View PDF
Share

Scaling Actions

When instances need to be added to or removed from an AS group, or the load balancer of an AS group needs to be changed, the group will perform various scaling actions.

Starting a Scaling Action

The system automatically starts a scaling action when specific conditions are met. An ongoing scaling action is not interrupted even if the AS group is disabled.

Condition

Action

Triggered By

Description
  • The AS group is enabled.
  • The expected number of instances is greater than the current number of instances.

Scale-out
  • Manually changing the number of expected instances
  • Executing an AS policy

-
  • The AS group is enabled.
  • The expected number of instances is less than the number of current instances.

Scale-in
  • Manually changing the number of expected instances
  • Executing an AS policy

-
  • The AS group is enabled.
  • Instances are added manually.

Scale-out

Manually adding instances

After an instruction for adding or removing instances is submitted, the AS group increases or decreases the expected number of instances automatically. You do not need to change the expected number manually.

Instances are removed manually.

Scale-in

Manually removing instances
  • The AS group is enabled.
  • Instances failed to pass the health check.

Scale-in

Stopping or deleting instances

ELB health check: A scaling action can be triggered by disabling backend node ports of a load balancer.

The expected number of instances will not be changed if a scale-in action is triggered by a health check failure.
  • The AS group is enabled.
  • The load balancer associated with an AS group is modified.

Load balancer migration

Manually modifying the load balancer associated with an AS group

After an instruction for modifying the load balancer associated with an AS group is submitted, initially, the old load balancer information continues to be displayed in the AS group details. After the load balancer migration is complete, the load balancer information will be automatically updated.

Instance Deletion Rules for Scale-In

During a scale-in action, the system determines whether an ECS instance should be deleted based on the ECS type, method to add it, and its billing mode.

Table 1 Instance deletion rules

Instance Type

Method to Add

Billing Mode

Whether to Delete

Automatically added instance

The instance is automatically created and added to an AS group during a scale-out action.

Pay-per-use or spot

Yes

Yearly/Monthly

In this scenario, you manually changed the billing mode of an instance from pay-per-use to yearly/monthly after the instance is automatically added to an AS group.

No

Manually added instance

The instance is manually created and added to an AS group.

Pay-per-use, spot, or yearly/monthly

No

Scaling Action Status

There are three scaling action statuses.

Status

Description

Scaling

This is the default status of a scaling action after it is started.

Failed

For a scale-in or scale-out action, if any number of instances fail to be added or removed, the status will be "failed".

Assume that five instances need to be added. Four instances are added successfully but one fails due to insufficient resources. The action will be in the failed state.

For a load balancer migration, if any number of instances fail to be re-associated with a load balancer, the migration status will be "failed".

Successful

A scale-in or scale-out action can only be considered successful if all required instances are added or removed successfully.

A load balancer migration can only be considered successful if all required instances are re-associated to the load balancer successfully.
  • If a scaling action failed, the added instances will be retained in the AS group and the number of instances in the AS group will increase.
  • In some special cases, a scaling action will fail. The AS group status will be Abnormal. For example, if the key pair used by the AS configuration has been deleted or the subnet used by the AS group cannot be found, the scaling action will fail.

Automatic Retry of Scaling Actions

If a scaling action fails and the actual number of instances is different from the expected number of instances, the AS group will retry the scaling action after a period of time.

If a scaling action fails multiple times in a row, the interval between two retries gradually increases. The minimum interval is 10 seconds and the maximum is 20 minutes.

  • The interval is for reference only. The actual interval varies depending on the system status.
  • Load balancer migrations cannot be retried. If a migration fails, you need to issue the instruction for modifying the AS group's load balancer again.
  • If an AS group is abnormal, scaling actions cannot be retried after a failure.

Priority Policies for Multi-AZ or Multi-Flavor Scale-Out

If your AS group is configured with multiple AZs, a scale-out action will try to create instances in each AZ until the scale-out succeeds or the creation failed in all of the AZs. The AZ priority is determined by the Multi-AZ Scaling Policy parameter for that AS group.

If your AS configuration has multiple instance flavors, a scale-out action will try to use each flavor to create instances until the scale-out succeeds or the creation failed for all of the flavors. The flavor priority is determined by the Flavor selection policy parameter for that AS configuration.

You can view scaling action records.

Instance Removal Priority for Scale-In

When instances are automatically removed from your AS group, AS will preferentially remove instances that are not in the current AZ. Then the instance removal policy you select will be applied.

There are four instance removal policies:

  • Oldest instance: The oldest instance is removed from the AS group first. Use this policy if you want to upgrade instances in an AS group to a new ECS type. This way, you can gradually replace instances of an old type with a new type.
  • Newest instance: The newest instance is removed from the AS group first. Use this policy if you want to test a new AS configuration but do not want to keep it in production.
  • Oldest instance created from oldest AS configuration: The oldest instance created from the oldest configuration is removed from the AS group first. Use this policy if you want to update an AS group and phase out instances created from a previous AS configuration.
  • Newest instance created from oldest AS configuration: The newest instance created from the oldest configuration is removed from the AS group first.

Manually added ECS instances are the last to be removed. If AS does remove a manually added instance, it only removes the instance from the AS group. It does not delete the instance. If multiple manually added instances must be removed, AS preferentially removes the earliest-added instances first.

Viewing Scaling Action Records

  1. Log in to the AS console.
  2. On the Instance Scaling page, click the name of an AS group.
  3. Click the Scaling Actions tab to view scaling action records.

    You can see the ID, status, type, description, start time, and end time of each scaling action. Click next to a scaling action ID to view the resource name, status, and failure cause. You can also filter scaling actions in a specified period in the upper right corner.

Parent topic: Instance Scaling