Lifecycle of an instance in a scaling group-Auto Scaling(ESS)-阿里云帮助中心

Instances in a scaling group, such as ECS or ECI instances, progress through a series of states from creation to release. You can use lifecycle hooks to control the creation and removal of ECS or ECI instances within a scaling group, giving you more control over their lifecycle. This topic describes how to manage instance lifecycles, the health check process, and the possible lifecycle states of instances in a scaling group.

Instance lifecycle management

How an instance's lifecycle is managed depends on how it was added to the scaling group.

Instance type

Addition method

Lifecycle management

Automatically created instances

ECS or ECI instances that are automatically created based on the instance configuration source of the scaling group.

Auto Scaling manages the entire lifecycle of the instance. It creates the instance during a scale-out event and stops and releases it during a scale-in event.

Manually added instances

You manually create an ECS or ECI instance and then add it to the scaling group.

Lifecycle management depends on whether the instance's lifecycle is delegated to the scaling group:

If delegated to the scaling group: During a scale-in event, Auto Scaling stops and releases the instance.
If not delegated to the scaling group: During a scale-in event, Auto Scaling removes the instance from the scaling group but does not release it.

Note

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

Health checks in a scaling group

Auto Scaling regularly checks the health of ECS and ECI instances. An instance that is not in the Running state is considered unhealthy, and the scaling group promptly removes or releases it.

Note

The running status of an ECS or ECI instance refers to its possible operational states from creation to release, which is different from its service state within the scaling group.

You can enable or disable health checks when you create a scaling group or for an existing one. For more information, see Configure a scaling group and Modify a scaling group.

When health checks are enabled, Auto Scaling monitors the health of instances in the scaling group and promptly removes or releases unhealthy ones as follows:

If an instance was automatically created by Auto Scaling, or was manually added with its lifecycle delegated to the scaling group, Auto Scaling removes and releases the unhealthy instance.
If an instance was manually added and its lifecycle is not delegated to the scaling group, Auto Scaling removes the instance from the scaling group but does not release it.
The removal of unhealthy instances is not constrained by the minimum instance count. If the total number of instances falls below the minimum, Auto Scaling automatically creates new instances to restore the minimum count.
Warning
Make sure that your account has a sufficient balance. If your account has overdue payments, all post-paid ECS instances, including pay-as-you-go instances and preemptible instances, are stopped or even released. For more information about how overdue payments affect ECS instances in a scaling group, see Overdue payments.

Instance lifecycle states

The lifecycle states of an instance in a scaling group depend on whether a lifecycle hook is configured.

Note

The lifecycle of an ECS or ECI instance itself, which spans from creation to release, is different from the lifecycle of an instance within a scaling group. For more information, see Instance lifecycle.

This section uses an ECS instance as an example to illustrate the relationship between its lifecycle states and service states.

The following figure shows the lifecycle state transitions for an ECS instance in a scaling group that does not have a lifecycle hook.
The values in parentheses are the instance states returned by the API. To query the states of instances in a scaling group by using the API, see DescribeScalingInstances - Query the list of ECS instances in a scaling group.
The following figure shows the lifecycle state transitions for an ECS instance in a scaling group that has a lifecycle hook.
The values in parentheses are the instance states returned by the API. To query the states of instances in a scaling group by using the API, see DescribeScalingInstances - Query the list of ECS instances in a scaling group.

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

In the Service State column of the following table, the value in parentheses is the instance state returned by the API. To query the states of instances in a scaling group by using the API, see DescribeScalingInstances - Query the list of ECS instances in a scaling group.

Service state	Description	Related actions
Pending (Pending)	The instance is being added to the scaling group. This process includes adding the instance as a backend server to a Server Load Balancer (SLB) instance and adding its IP address to the IP address whitelist of an ApsaraDB RDS instance. An ECS instance can be added to a scaling group if it is in one of the following states: Running: When you manually add an ECS instance, or when a scaling group scales out. Standby: When you return a standby ECS instance to service. ECS instances in the Standby state can rejoin a scaling group to return to service.	Automatically add ECS instances: Create a scaling group. Manually add ECS instances: Manually add instances to a scaling group. Add ECS instances by executing a scaling rule, scheduled task, or event-triggered task: Execute a scaling rule. Create a scheduled task. Create an event-triggered task.
Pending Add (Pending:Wait)	If a lifecycle hook for scale-out events is configured for the scaling group, the instance is suspended and waits for the hook to time out before being added to the group. During this pending period, you can perform custom actions on the instance, such as pre-installing software, attaching a secondary elastic network interface, or adding it to the IP address whitelist of a Redis instance. Note An instance enters this state only if a lifecycle hook for scale-out events is enabled for the scaling group.	Lifecycle hooks. Create a lifecycle hook.
In Service (InService)	The ECS instance has been successfully added to the scaling group and is serving traffic. An ECS instance leaves the In Service state in any of the following situations: During a scale-in event or if the instance becomes unhealthy, the scaling group may remove or terminate the instance, which then enters the Stopped state. When an ECS instance in a scaling group becomes unhealthy, the scaling group promptly removes or even releases the unhealthy ECS instance, and the instance enters the Stopped state. When you need to troubleshoot or modify the instance, you can place it in the Standby state. When an ECS instance is removed from the scaling group, it enters the Removing state.	You can manually change the state of an In Service instance to Stopped or Standby, or remove or delete the instance. For more information, see Manually change the status of an instance.
Standby (Standby)	The instance is temporarily removed from service. Its load balancing weight is set to zero, the SLB instance stops forwarding traffic to it, and Auto Scaling ceases to manage its lifecycle. You must manage it manually. While an instance is in the Standby state, you can perform maintenance such as troubleshooting issues or updating its image, and then return the instance to service in the scaling group. Note An instance in the Standby state is not considered a functional part of your application until you return it to service.	Put an instance into standby or remove it from standby.
Protected (Protected)	To prevent an instance from being removed from a scaling group, you can put it in the Protected state. The instance continues to serve traffic, but Auto Scaling no longer manages its lifecycle. You must manage it manually. If you want Auto Scaling to resume managing the instance's lifecycle, you can remove its protection.	Enable or disable instance protection.
Removing (Removing)	The ECS instance is being removed from the scaling group. This process includes removing the instance from the backend servers of an SLB instance and from the IP address whitelist of an ApsaraDB RDS instance. After an instance is removed, it becomes independent of the scaling group. You can then add the instance to other scaling groups.	Manually remove an ECS instance: Manually remove or delete an instance. Remove an ECS instance by executing a scaling rule, scheduled task, or event-triggered task: Execute a scaling rule. Create a scheduled task. Create an event-triggered task.
Pending Remove (Removing:Wait)	If a lifecycle hook for scale-in events is configured for the scaling group, the instance is suspended and waits for the hook to time out before being removed from the group. During this pending period, you can perform custom actions on the instance, such as uninstalling software, copying logs, or clearing data. Note An instance enters this state only if a lifecycle hook for scale-in events is enabled for the scaling group.	Lifecycle hooks. Create a lifecycle hook.
Stopped (Stopped)	The ECS instance enters the Stopped state and no longer provides services. When an ECS instance is stopped, its vCPUs, memory, and fixed public IP address are reclaimed, and you are no longer charged for these resources. However, resources such as disks and elastic IP addresses (EIPs) are retained and continue to be billed. During a scale-out event, Auto Scaling prioritizes starting instances that are in the Stopped state. Note If you want instances to enter the Stopped state, make sure that the Instance Reclaim Mode is set to Shutdown and Reclaim when you create the scaling group.	Instance reclaim mode.