This page covers the operations available for managing Elastic Compute Service (ECS) instances and elastic container instances in Auto Scaling groups — including manual management, instance state changes, rebalancing, and integration with Server Load Balancer (SLB) and ApsaraDB RDS.
Instance management operations
Auto Scaling supports the following operations on instances in a scaling group.
| Operation | Description | User guide | API reference |
|---|---|---|---|
| Check health status | Check the health status of instances in a scaling group. | Instance lifecycles | SetInstanceHealth |
| Add instances | Manually add ECS instances or elastic container instances to a scaling group. | Manually configure instances for a scaling group | AttachInstances |
| Query instance list | List all instances in a scaling group. | — | DescribeScalingInstances |
| Remove instances | Remove or delete instances from a scaling group. | — | DetachInstances, RemoveInstances |
| Put instances into Standby state | Temporarily remove instances from active service for maintenance. Return them to service when ready. | Manually change the status of instances | EnterStandby, ExitStandby |
| Put instances into Protected state | Prevent specific instances from being removed during scale-in events. Use this to protect instances running critical workloads that must not be terminated automatically. | — | SetInstancesProtection |
| Put instances into Stopped state | Stop instances while keeping them in the scaling group. | — | N/A |
| Rebalance instance distribution | Evenly redistribute ECS instances across zones in a scaling group. | Rebalance the distribution of ECS instances | RebalanceInstances |
| Associate with SLB instances | Attach or detach instances from one or more SLB instances. | Associate SLB instances with or disassociate SLB instances from a scaling group | AttachLoadBalancers, DetachLoadBalancers |
| Associate with ApsaraDB RDS instances | Attach or detach instances from one or more ApsaraDB RDS instances. | Associate ApsaraDB RDS instances with a scaling group or disassociate ApsaraDB RDS instances from a scaling group | AttachDBInstances, DetachDBInstances |
Failure scenarios
Auto Scaling lets you delete instances that it automatically created — even from another service's console. For example, deleting an ECS instance from the ECS console also removes it from the scaling group in Auto Scaling. This can interrupt the services those instances were running.
The tables below describe what happens in each scenario and how Auto Scaling responds.
Forcibly deleted instances or resources
| Resource | What you did | Auto Scaling response |
|---|---|---|
| ECS instances or elastic container instances | Deleted instances from the ECS console or Elastic Container Instance console, or via API operations | If health check is enabled, Auto Scaling detects unhealthy instances and removes them. If the remaining instance count drops below the minimum, Auto Scaling creates new ECS instances or elastic container instances to restore the minimum. Note The private IP addresses of unhealthy ECS instances or elastic container instances are not automatically deleted from the IP address whitelists of associated ApsaraDB RDS instances. |
| SLB instances | Forcibly detached ECS or elastic container instances from an SLB instance in the SLB console or via API operations | Auto Scaling does not detect the detachment and does not handle the exception. The instances remain in the scaling group. On the next scale-in event, Auto Scaling releases the instances if they meet the removal policy criteria. |
| SLB instances | Deleted the associated SLB instance or disabled its health check in the SLB console or via API operations | The instances in the scaling group are no longer attached to the deleted SLB instance. Scale-in events can still remove instances from the scaling group. Unhealthy instances are removed automatically. |
| ApsaraDB RDS | Removed instance private IP addresses from the ApsaraDB RDS IP address whitelist in the RDS console or via API operations | Auto Scaling does not detect the change. The instances remain in the scaling group. On the next scale-in event, Auto Scaling releases the instances if they meet the removal policy criteria. |
| ApsaraDB RDS | Deleted the associated ApsaraDB RDS instance in the RDS console or via API operations | Private IP addresses of scaling group instances are no longer added to the deleted RDS instance's whitelist. Scale-in events can still remove instances. Unhealthy instances are removed automatically. |
Revoked API permissions
| Resource | What you did | Auto Scaling response |
|---|---|---|
| ECS instances or elastic container instances | Revoked Auto Scaling's permissions on ECS API or Elastic Container Instance API | Auto Scaling rejects all scaling requests. |
| SLB instances | Revoked Auto Scaling's permissions on SLB API | Auto Scaling rejects all scaling activities in scaling groups associated with SLB instances. |
| ApsaraDB RDS | Revoked Auto Scaling's permissions on ApsaraDB RDS API | Auto Scaling rejects all scaling requests in scaling groups associated with ApsaraDB RDS instances. |
Unavailable resources
| Resource | Cause | Auto Scaling response |
|---|---|---|
| SLB instances | SLB instances became unavailable due to reasons such as overdue payments or system failures | Only manual removal of instances from the scaling group is possible. No other scaling activities can be triggered. |
| ApsaraDB RDS | ApsaraDB RDS instances became unavailable due to reasons such as overdue payments or system failures | Only manual removal of instances from the scaling group is possible. No other scaling activities can be triggered. |
该文章对您有帮助吗？