An Elastic Compute Service (ECS) instance in a scaling group transitions through different states from the moment the instance is created to the moment the instance is released. You can create a lifecycle hook for your scaling group to put the ECS instances in the scaling group to the Pending state. The lifecycle hook provides a period of time for you to perform operations on the ECS instances. This topic describes how to manage the lifecycle of ECS instances in a scaling group and how to perform health checks on the ECS instances. This topic also describes all possible states of an ECS instance.

How to manage the lifecycle of ECS instances in a scaling group

ECS instances in a scaling group are classified into instances that are automatically created and instances that are manually added. The following table describes how to manage the lifecycle of these two types of ECS instances.

Type Method used to add instances Method used to manage the lifecycle
ECS instances that are automatically created ECS instances are automatically created in a scaling group based on the instance configuration source of the scaling group. Auto Scaling manages the lifecycle of the ECS instances that are automatically created. During scale-out activities, Auto Scaling automatically creates the ECS instances. During scale-in activities, Auto Scaling stops and releases ECS instances.
ECS instances that are manually added ECS instances are manually created and added to scaling groups. The method that is used to manage the lifecycle of the ECS instances that are manually created varies based on whether scaling groups are used to manage the lifecycle of the ECS instances.
  • If scaling groups are used to manage the lifecycle of the ECS instances, Auto Scaling stops and releases the ECS instances during scale-in activities.
  • If scaling groups are not used to manage the lifecycle of the ECS instances, Auto Scaling removes the ECS instances from the scaling groups but does not release the ECS instances during scale-in activities.
Note You can add subscription instances to scaling groups. The scaling groups cannot be used to manage the lifecycle of the subscription instances.

Instance health checks

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

Note The running states of an ECS instance are not its service states in a scaling group. The running states refer to all possible states of an ECS instance from the point in time when the instance is created to the point in time when the instance is released.

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

After the health check feature is enabled for a scaling group, Auto Scaling checks the health status of ECS instances in the scaling group. If Auto Scaling determines that the ECS instances in the scaling group are unhealthy, Auto Scaling immediately removes the ECS instances from the scaling group or releases the ECS instances.
  • If the ECS 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 ECS instances.
  • If you manually add the ECS instances to the scaling group and you do not use the scaling group to manage the lifecycle of these ECS instances, Auto Scaling removes the ECS instances from the scaling group but does not release the ECS instances.
  • If the removal of unhealthy instances results in the number of instances to be less than the minimum number, Auto Scaling automatically creates the required number of ECS 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 ECS instances in scaling groups

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

Note The lifecycle of an ECS instance starts when the instance is created and ends when the instance is released. The lifecycle of an ECS instance is different from the process that starts from the point in time when the ECS instance is added to a scaling group and ends at the point in time when the instance is removed from the scaling group. For more information, see Instance lifecycle.
  • 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 being added to a scaling group to the point in time when the instance is being removed from the scaling group.
State Description References
Adding ECS instances that are in the Adding state are being added to the backend server group of the Server Load Balancer (SLB) instance that is associated with the scaling group and the whitelist that manages access to the ApsaraDB RDS instance that is 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:Add If you create a lifecycle hook for a scaling group to perform scale-out activities, ECS instances enter the Pending:Add state and can be added to the scaling group only after the lifecycle hook times out.

After you create a lifecycle hook, you can perform operations on 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 that manages access to ApsaraDB for Redis instances.

Note The Pending:Add state becomes available only after you create lifecycle hooks for scaling groups.
In Service ECS instances that are added to the scaling group enter the In Service state and can provide services.

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 determines 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 providing services. 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 switch 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 switch the state of the ECS instances from the Protected state. Then, Auto Scaling can manage the lifecycle of these ECS instances.
Removing ECS instances that are in the Removing state are being removed from the backend server group of the SLB instance that is associated with the scaling group and the whitelist that manages access to the ApsaraDB RDS instance that is associated with the scaling group.

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

Pending:Remove If you create a lifecycle hook for a scaling group to perform scale-in activities, ECS instances in the scaling group enter the Pending:Remove state. The ECS instances can be removed from the scaling group only after the lifecycle hook times out.

After you configure the lifecycle hook for the scaling group, you can uninstall software on the ECS instances that are in the Pending Remove state or perform other operations on the ECS instances, for example, you can copy logs and clean the data of the ECS instances.

Note The Pending:Add state becomes available only after you create lifecycle hooks for scaling groups.
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 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