A scaling group may contain Elastic Compute Service (ECS) instances or elastic container instances. An instance goes through a series of states after the instance is added to a scaling group and before the instance is removed from the scaling group. These states constitute the lifecycle of the instance in the scaling group. You can create a lifecycle hook for your scaling group to put the ECS instances or elastic container instances in the scaling group to the Pending state. The lifecycle hook provides a period of time for you to perform operations on the instances. This topic describes the lifecycle management modes and health checks for ECS instances or elastic container instances in a scaling group. This topic also describes all possible states of an instance in a scaling group.

Lifecyle management modes for instances in a scaling group

ECS instances or elastic container instances in a scaling group are classified into instances that are automatically created and instances that are manually added. The following table describes the lifecycle management modes for these two types of instances.

Instance category How instances are added Lifecycle management mode
Instances that are automatically created ECS instances or elastic container instances are automatically created in a scaling group based on the instance configurations of the scaling group. Auto Scaling manages the lifecycle of the ECS instances or elastic container instances that are automatically created. During scale-out activities, Auto Scaling automatically creates instances. During scale-in activities, Auto Scaling stops and releases instances.
Instances that are manually added ECS instances or elastic container instances are manually created and added to scaling groups. The lifecycle management mode for the manually added ECS instances or elastic container instances varies based on whether the scaling groups are delegated to manage the lifecycle of the instances.
  • If the scaling groups are delegated to manage the lifecycle of the ECS instances or elastic container instances, Auto Scaling stops and releases the instances during scale-in activities.
  • If the scaling groups are not delegated to manage the lifecycle of the ECS instances or elastic container instances, Auto Scaling removes the instances from the scaling groups but does not release the instances during scale-in activities.
Note You can add subscription ECS instances to a scaling group. However, you cannot delegate the scaling group to manage the lifecycle of the subscription ECS instances that are added to the scaling group.

Health checks on instances in a scaling group

To manage the lifecycle of ECS instances or elastic container instances in a scaling group, Auto Scaling performs health checks on the instances at regular intervals. If Auto Scaling detects an instance that is not in the Running state, Auto Scaling considers the instance unhealthy and immediately removes the unhealthy instance from the scaling group or releases the unhealthy instance.

Note The Running state of an ECS instance or elastic container instance does not necessarily mean that the instance is in the In Service state in a scaling group.

You can enable or disable the health check feature when you create a scaling group. You can also enable or disable the feature for an existing scaling group. For more information, see Create a scaling group and Modify scaling groups.

After the health check feature is enabled for a scaling group, Auto Scaling checks the health status of ECS instances or elastic container instances in the scaling group. If Auto Scaling considers the instances in the scaling group unhealthy, Auto Scaling immediately removes the instances from the scaling group or releases the instances.
  • If the ECS instances or elastic container instances are automatically created by Auto Scaling, or are manually added to the scaling group and their lifecycle is managed by the scaling group, Auto Scaling removes and releases these instances.
  • If you manually add the ECS instances or elastic container instances to the scaling group and you have not delegated the scaling group to manage the lifecycle of these instances, Auto Scaling removes the instances from the scaling group but does not release the instances.
  • If the number of instances is less than the minimum value due to the operation to remove the unhealthy instances, Auto Scaling automatically creates ECS instances or elastic container instances to maintain the minimum number.
    Warning Make sure that you have sufficient balance in your account. If you have overdue payments in your account, pay-as-you-go and preemptible instances are stopped or released. For information about status changes of ECS instances in a scaling group due to overdue payments, see Overdue payments.

Lifecycle states of instances in a scaling group

The possible lifecycle states of ECS instances or elastic container instances in a scaling group vary based on whether a lifecycle hook is created for the scaling group.

Note The real lifecycle of an ECS instance or elastic container instance starts when the instance is created and ends when the instance is released. The real lifecycle is different from the lifecycle of the ECS instance or elastic container instance in a scaling group that starts when the instance is added to the scaling group and ends when the instance is removed from the scaling group. For more information, see Instance lifecycle.

In this example, ECS instances in a scaling group are used to describe the possible states of instances in a scaling group.

  • The following figure shows the transitions between states of ECS instances in a scaling group that does not use a lifecycle hook.Without a lifecycle hook
  • The following figure shows the transitions between states of ECS instances in a scaling group that uses a lifecycle hook.With a lifecycle hook
The following table describes all possible states of an ECS instance from the point in time when the instance is added to a scaling group to the point in time when the instance is removed from the scaling group.
State Description Related operations
Pending ECS instances that are in the Pending state are being added to the scaling group. For example, the instances may be being added to the backend server group of the Server Load Balancer (SLB) instance associated with the scaling group or the whitelist of the ApsaraDB RDS instance associated with the scaling group.

ECS instances that are in the following states can be added to a scaling group:

  • ECS instances that are in the Running state can be manually added to the scaling group.
  • ECS instances that are in the Running state can be automatically added to the scaling group during scale-out activities.
  • ECS instances that are in the Standby state can be manually or automatically added to the scaling group.
Pending:Wait If a lifecycle hook is configured for the scaling group to monitor scale-out activities, ECS instances enter the Pending:Wait state when they are added to the scaling group until the lifecycle hook times out.

During this waiting period, you can perform operations on the ECS instances. For example, you can pre-install software on the ECS instances, attach secondary elastic network interfaces (ENIs) to the ECS instances, and add the IP addresses of the ECS instances to the whitelist of associated ApsaraDB for Redis instances.

Note The Pending:Wait state is available only in scaling groups with lifecycle hooks.
In Service ECS instances in the In Service state can provide services as expected.

If one of the following conditions is met, the state of the ECS instances changes from the In Service state:

  • After Auto Scaling stops ECS instances in the scaling group during scale-in activities, the ECS instances enter the Stopped state.
  • After Auto Scaling removes ECS instances or releases ECS instances that the system considers unhealthy, the ECS instances enter the Stopped state.
  • ECS instances that are being stopped, troubleshot, or replaced enter the Standby state.
  • ECS instances that are being removed from the scaling group enter the Removing state.
Standby ECS instances that are in the Standby state stop working. The weights of the ECS instances that are used as backend servers of the SLB instance are set to zero. The SLB instance stops forwarding traffic to the ECS instances, and Auto Scaling no longer manages the lifecycle of the ECS instances. You must manually manage the lifecycle of these ECS instances.

You can update the images of the ECS instances that are in the Standby state and resolve issues that occur on these ECS instances. Then, you can put these ECS instances back into the In Service state and add them to the scaling group again.

Note The ECS instances that are in the Standby state are not an active part of your application until you put them back into the In Service state.
Protected
  • If you do not want to remove an ECS instance from a scaling group, you can change the state of the ECS instance to Protected. ECS instances that are in the Protected state can provide services. Auto Scaling does not manage the lifecycle of the ECS instances that are in the Protected state. You must manually manage the lifecycle of the ECS instances that are in the Protected state.
  • If you do not want to manually manage the lifecycle of the ECS instances that are in the Protected state, you can change the state of the ECS instances from the Protected state to another state. Then, Auto Scaling can manage the lifecycle of these ECS instances.
Removing ECS instances in the Removing state are being removed from the group. For example, the instances may be being removed from the backend server group of the associated SLB instance or the whitelist of the associated ApsaraDB RDS instance.

You can add the ECS instances that are removed from a scaling group to other scaling groups.

Removing:Wait If a lifecycle hook is configured for the scaling group to monitor scale-in activities, ECS instances in the scaling group enter the Removing:Wait state when they are removed from the scaling group until the lifecycle hook times out.

During this waiting period, you can perform operations on the ECS instances. For example, you can install software, copy logs, and clean data on the ECS instances.

Note The Removing:Wait state is available only in scaling groups with lifecycle hooks.
Stopped ECS instances whose lifecycles are no longer managed enter the Stopped state and cannot provide services. When an ECS instance is stopped, the vCPUs, memory, and public IP address of the ECS instance are reclaimed. You are no longer charged for these resources. You are charged for resources that are retained, such as disks and elastic IP addresses (EIPs). During scale-out activities, Auto Scaling preferentially adds the ECS instances that are in the Stopped state to a scaling group.
Note If you want to stop an ECS instance in a scaling group, make sure that you set the instance reclaim mode to Shutdown and Reclaim Mode when you create the scaling group.
Put an ECS instance into the Stopped state