What is an instance lifecycle? - Auto Scaling - Alibaba Cloud Documentation Center

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 into 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 either automatically created or manually added. The following table describes the lifecycle management modes for the two types of instances.

Instance classification

Adding method

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 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 events, Auto Scaling automatically creates instances. During scale-in events, 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 of manually added ECS instances or elastic container instances depends on whether the scaling groups are in charge of managing the instances.

If scaling groups are in charge of managing ECS instances or elastic container instances, Auto Scaling stops and releases the instances during scale-in events.
If scaling groups are not in charge of managing ECS instances or elastic container instances, Auto Scaling stops the instances but does not release them during scale-in events.

Note

You can add subscription ECS instances to a scaling group, but you cannot delegate the scaling group to manage the subscription ECS instances.

Health checks on instances in a scaling group

Auto Scaling regularly performs health checks on ECS or elastic container instances in a scaling group to manage their lifecycles. If an instance is not in the Running state, Auto Scaling will consider it unhealthy and promptly remove it from the scaling group or release it.

Note

The running status of an ECS or elastic container instance refers to its status from creation to release, not its service status in the scaling group.

You can enable or disable the health check feature when creating or modifying a 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 regularly monitors the health status of ECS instances or elastic container instances in the scaling group. If any of the instances are deemed unhealthy, Auto Scaling promptly removes or releases them from the scaling group. The following rules apply:

Auto Scaling automatically removes and releases ECS instances or elastic container instances that are either created automatically by Auto Scaling or manually added to the scaling group and their lifecycles are managed by the scaling group.
If you manually add ECS or elastic container instances to the scaling group without delegating the scaling group to manage the lifecycles of these instances, Auto Scaling removes unhealthy instances from the scaling group but does not release them.
The actual number of instances in the scaling group may fall below the minimum required number if unhealthy ECS or elastic container instances are removed. In this case, Auto Scaling automatically creates ECS instances or elastic container instances to uphold the minimum required 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 are stopped or released. For information about how the status of an ECS instance changes in the event of overdue payments, see Overdue payments.

Lifecycle states of instances in a scaling group

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

Note

The lifecycle of an ECS or elastic container instance begins when it is created and ends when it is released. This differs from the lifecycle of an instance in a scaling group, which begins when it is added to the group and ends when it is removed. For more information, see Instance lifecycle.

The following table describes the states of an ECS instance in a scaling group.

The following figure illustrates the state transitions of an ECS instance in a scaling group for which no lifecycle hook is created.
The parentheses in the figure display the status of the ECS instance retrieved through an API call. For more information about how to query instance status by calling an API operation, see DescribeScalingInstances.
The following figure illustrates the state transitions of an ECS instance in a scaling group for which a lifecycle hook is created.
The parentheses in the figure display the status of the ECS instance retrieved through an API call. For more information about how to query instance status by calling an API operation, see DescribeScalingInstances.

The following table describes the different states that an ECS instance goes through from being added to a scaling group to being removed from the scaling group.

The parentheses in the table display the status of the ECS instance retrieved through an API call. For more information about how to query instance status by calling an API operation, see DescribeScalingInstances.

Service status	Description	Related operation
Adding	The ECS instance is being added to the scaling group, during which the ECS instance is also being attached to the associated Server Load Balancer (SLB) instance as a backend server and its private IP address is being added to the IP address whitelist of the associated ApsaraDB RDS instance. 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 events. ECS instances that are in the Standby state can be manually or automatically added to the scaling group.	Automatically add ECS instances to a scaling group (Create scaling groups) Manually add ECS instances to a scaling group (Manually add instances to a scaling group) Manually execute scaling rules, scheduled tasks, or event-triggered tasks to add ECS instances to a scaling group Execute scaling rules Create a scheduled task Create event-triggered tasks
Pending Add (Pending:Wait)	If a lifecycle hook is created for the scaling group to monitor scale-out operations, the ECS instance enters the Pending Add state until the timeout period of the lifecycle hook ends. During this period, you can perform operations on the ECS instance. 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 address of the ECS instance to the IP address whitelist of the associated ApsaraDB for Redis instances. Note The Pending Add state is available only in scaling groups for which lifecycle hooks are created.	Learn more about lifecycle hooks (Overview) Create lifecycle hooks (Create a lifecycle hook)
In Service (InService)	The ECS instance is added to the scaling group and is providing services as expected. If one of the following conditions is met, the ECS instance exits the In Service state and enters another state: If Auto Scaling stops the ECS instance during a scale-in event, the ECS instance enters the Stopped state. If the ECS instance is considered unhealthy by Auto Scaling, Auto Scaling promptly stops the ECS instance. In this case, the ECS instance exits the In Service state and enters the Stopped state. When you terminate, troubleshoot, or modify the ECS instance, the ECS instance enters the Standby state. When the ECS instance is being removed from the scaling group, the ECS instance exits the In Service state and enters the Removing state.	Manually switch an ECS instance from the In Service state to the Stopped or Standby state (Manually change the status of instances) Manually remove an ECS instance from a scaling group. Manually delete an ECS instance (Manually change the status of instances)
Standby (Standby)	The ECS instance is not providing services and its load balancing weight is reset to zero, meaning no incoming traffic is being forwarded to it. Auto Scaling no longer manages the lifecycle of the ECS instance, so you must manage it manually. You can troubleshoot issues, update the image, and perform O&M operations on a Standby ECS instance. Once completed, you can add the ECS instance to the scaling group to return it to the In Service state. Note The ECS instances in Standby state are not active in your application until you return them to the In Service state.	Manually put instances into the Standby state or move instances out of the Standby state
Protected	To keep an ECS instance in a scaling group without removing it, you can put the ECS instance into the Protected state. Protected ECS instances can still operate normally, but Auto Scaling does not manage their lifecycles. You must manually manage the lifecycles of any ECS instances in the Protected state. If you do not want to manually manage the lifecycles of ECS instances in the Protected state, remove them from that state, so Auto Scaling can manage their lifecycles.	Manually put instances into the Protected state or move instances out of the Protected state
Removing (Removing)	The ECS instance is being removed from the scaling group, during which the ECS instance is also being detached from the associated SLB instance and its private IP address is being removed from the IP address whitelist of the associated ApsaraDB RDS instance. After the ECS instance is removed from the scaling group, it becomes independent and can be added to a different scaling group.	Manually remove an ECS instance from a scaling group (Manually remove or delete instances) Manually execute scaling rules, scheduled tasks, or event-triggered tasks to remove ECS instances from a scaling group Execute scaling rules Create a scheduled task Create event-triggered tasks
Pending Remove (Removing:Wait)	If a lifecycle hook is created for the scaling group to monitor scale-in operations, the ECS instance enters the Pending Remove state until the timeout period of the lifecycle hook ends. During this period, you can perform operations on the ECS instance. For example, you can install software, copy logs, and clean data on the ECS instance. Note The Pending Remove state is available only in scaling groups for which lifecycle hooks are created.	Learn more about lifecycle hooks (Overview) Create lifecycle hooks (Create a lifecycle hook)
Stopped	The ECS instance is not providing services and does not require any further management for its lifecycle. When you stop an ECS instance, take note that you are no longer charged for the vCPUs, memory, and public IP address that are reclaimed. You are still charged for any retained resources, such as disks and elastic IP addresses (EIPs). Auto Scaling prioritizes adding stopped ECS instances to the scaling group during scale-out events. Note Before you put an ECS instance into the Stopped state, make sure that you set the Instance Reclaim Mode parameter to Economical Mode when you create the scaling group.	Learn more about instance reclaim modes (Instance reclaim modes)