A scaling group may contain Elastic Compute Service (ECS) instances or elastic container instances. After an instance is added to a scaling group, the instance goes through a series of states before it 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 ECS instances or elastic container instances to the Pending:Add or Pending:Remove state. The lifecycle hook provides a period of time during which you can 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.

Lifecycle management modes for instances in a scaling group

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

CategoryHow instances are addedLifecycle management mode
Instances that are automatically createdECS instances or elastic container instances are automatically created in a scaling group based on the instance configuration source of the scaling group. Auto Scaling manages the lifecycles 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 addedECS 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 lifecycles of the instances.
  • If the scaling groups are delegated to manage the lifecycles 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 lifecycles 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 lifecycles of the subscription ECS instances that are added to the scaling group.

Health checks on instances in a scaling group

To manage the lifecycles 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 indicate 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 Manage scaling groups 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 lifecycles are 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 do not delegate the scaling group to manage the lifecycles 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 number that must be maintained due to the removal of 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 within your Alibaba Cloud account. If you have overdue payments within your Alibaba Cloud account, pay-as-you-go and preemptible instances will be 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 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.Scaling group without a lifecycle hook
  • The following figure shows the transitions between states of ECS instances in a scaling group that uses a lifecycle hook.Scaling group with a lifecycle hook
The following table describes all states of an ECS instance from the time when the instance is added to a scaling group to the time when the instance is removed from the scaling group.
StateDescriptionReferences
AddingECS instances that are in the Adding state are being added to the scaling group. For example, the instances are being added to the backend server group of the Server Load Balancer (SLB) instance associated with the scaling group or the private IP addresses of the instances are being added to 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:AddIf a lifecycle hook is created for the scaling group to monitor scale-out activities, ECS instances enter the Pending:Add state before they are added to the scaling group.

During this 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 private IP addresses of the ECS instances to the whitelist of the associated ApsaraDB for Redis instances.

Note The Pending:Add state is available only in scaling groups that use lifecycle hooks.
In ServiceECS instances that are in the In Service state can provide services as expected.

If one of the following conditions is met, ECS instances exit from the In Service state and enter other states:

  • 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 are considered 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.
ECS instances can exit from the In Service state and enter the Stopped state or the Standby state. You can also manually remove ECS instances that are in the In Service state from scaling groups or delete ECS instances that are in the In Service state. For more information, see Manually change the status of instances.
StandbyWhen an ECS instance enters the Standby state, the ECS instance stops 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 lifecycles of the ECS instances. You must manually manage the lifecycles 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 groups 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.
Manually put instances into the Standby state or move instances out of the Standby state
Protected
  • If you do not want to remove an ECS instance from a scaling group, you can put the ECS instance into the Protected state. ECS instances that are in the Protected state can provide services. Auto Scaling does not manage the lifecycles of ECS instances that are in the Protected state. You must manually manage the lifecycles of the ECS instances that are in the Protected state.
  • If you do not want to manually manage the lifecycles of the ECS instances that are in the Protected state, you can put the ECS instances into other states. Then, Auto Scaling can manage the lifecycles of these ECS instances.
Manually put instances into the Protected state or move instances out of the Protected state
RemovingECS instances in the Removing state are being removed from the scaling group. For example, the ECS instances are being removed from the backend server group of the associated SLB instance or the private IP addresses of the ECS instances are being deleted from 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.

Pending RemoveIf a lifecycle hook is created for the scaling group to monitor scale-in activities, ECS instances in the scaling group enter the Pending:Remove state before they are removed from the scaling group.

During this 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 Pending:Remove state is available only in scaling groups that use lifecycle hooks.
StoppedECS 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 parameter to Economical Mode when you create the scaling group.
Manually put instances into the Standby state or move instances out of the Standby state