This topic describes how to manage the lifecycle of ECS instances in a scaling group and lists all the possible service states of the instances. When Auto Scaling manages the lifecycle of ECS instances, it checks whether ECS instances are healthy, and removes or even releases unhealthy instances.
Methods for managing the ECS instance lifecycle
|Automatically created ECS instances||Instances that are automatically created based on the instance configuration source of a scaling group||Auto Scaling manages the whole lifecycle of an ECS instance. During a scale-out event, Auto Scaling automatically creates ECS instances. During a scale-in event, Auto Scaling stops and releases ECS instances.|
|Manually added ECS instances||Instances that are manually created and then added to a scaling group||The management method depends on whether the scaling group is enabled to manage the
lifecycle of the ECS instances:
Instance service states
|Service state||Corresponding operation||Description|
|Pending (Pending)||The ECS instance is being added to a scaling group. During this process, Auto Scaling adds the ECS instance to the backend server groups of the associated Server Load Balancer (SLB) instances and the whitelists of the associated ApsaraDB for RDS instances.|
|Adding:Wait (Pending:Wait)||Create a lifecycle hook.||If a lifecycle hook that applies to scale-out events is created for a scaling group,
when the ECS instance is being added to the scaling group, the instance is put into
the wait state until the lifecycle hook times out.
You can perform customized operations on the instance during the timeout period, such as binding a secondary elastic network interface (ENI) and adding the instance to the whitelist of an ApsaraDB for RDS instance.
|In Service (InService)||None||The ECS instance is added to a scaling group and can provide services normally.|
|Standby (Standby)||Put an ECS instance into the Standby state.||The ECS instance stops providing services and its weight as a backend server of an
SLB instance is set to zero. The SLB instance stops forwarding traffic to the ECS
instance and Auto Scaling does not manage the lifecycle of the instance. You can manage
You can troubleshoot and update the image of the ECS instance that is in the Standby state, and then put the instance into service again.
|Protected (Protected)||Put an ECS instance into the Protected state.||The ECS instance can provide services normally. However, Auto Scaling does not manage the lifecycle of the instance. You can manage it manually.|
|Stopped (Stopped)||Put an ECS instance into the Stopped state.||The ECS instance is stopped and put out of service. The vCPUs, memory, and bandwidth
of this instance are not charged. During scale-out events, Auto Scaling preferentially
starts ECS instances that are in the Stopped state in a scaling group.
Note If you want to stop an ECS instance in a scaling group, make sure that the instance reclaim mode is set to Shutdown and Reclaim Mode when you create the scaling group.
||The ECS instance is being removed from a scaling group. During this process, Auto Scaling removes the instance from the backend server groups of the associated SLB instances and from the whitelists of the associated ApsaraDB for RDS instances.|
|Removing:Wait (Removing:Wait)||Create a lifecycle hook.||If a lifecycle hook that applies to scale-in events is created for a scaling group,
when the ECS instance is being removed from the scaling group, the instance is put
into the wait state until the lifecycle hook times out.
You can perform customized operations on the instance during the timeout period, such as copying logs and clearing data.
Instance health check
The health check feature is automatically enabled for a scaling group when it is created. You can also manually disable the feature. For more information, see Modify a scaling group.
- If the instances are automatically created by Auto Scaling, or are manually added to the scaling group and their lifecycle is managed by Auto Scaling, Auto Scaling removes and releases these instances.
- If the instances are manually added to the scaling group and their lifecycle is not managed by Auto Scaling, Auto Scaling removes these instances from the scaling group but does not release them.