Auto Scaling automatically adjusts the number of computing resources based on configured policies. Users of Auto Scaling are subject to feature and resource limits. For example, the number of Elastic Compute Service (ECS) instances in each automatic adjustment has an upper limit. This topic describes the limits on Auto Scaling features and resources.
Limits on features
Auto Scaling features have the following limits:
The applications that are hosted on ECS instances or elastic container instances in a scaling group must be stateless and horizontally scalable.
ECS instances or elastic container instances in a scaling group may be automatically released. Therefore, we recommend that you do not store session data, application data and logs on the instances. If the applications that are hosted on ECS instances or elastic container instances require persistent storage of data, we recommend that you store status information such as session data on independent ECS instances or elastic container instances, store application data in ApsaraDB RDS, and store logs in Simple Log Service. For more information, see What is ApsaraDB RDS? and What is Simple Log Service?
Auto Scaling cannot automatically add the IP addresses of ECS instances or elastic container instances to the IP address whitelists of ApsaraDB for Memcache instances. Therefore, you must manually add the IP addresses of the instances to the IP address whitelists. For more information, see Configure an IP address whitelist.
If the ApsaraDB RDS instances, Application Load Balancer (ALB) instances, Classic Load Balancer (CLB) instances, or CLB backend server groups that are associated with a scaling group are deleted, Auto Scaling automatically detaches the deleted resources from the scaling group.
If a scaling activity that is automatically triggered in a scaling group fails consecutively for more than 30 days, Auto Scaling inspects the scaling group and disables automatic trigger of scaling activities. Auto Scaling also sends notifications to you by text messages and emails.
ImportantIf a scaling activity fails consecutively, we recommend that you log on to the Auto Scaling console to resolve the issue.
Limits on resources
The following table describes the limits on the Auto Scaling resources within a single Alibaba Cloud account.
Resource | Quota |
Maximum number of scaling groups allowed in a region | To view the quota, visit Quota Center. Note You can submit a ticket to request a quota increase. |
Maximum number of scaling configurations allowed in a scaling group | |
Maximum number of scaling rules allowed in a scaling group | |
Maximum number of ApsaraDB RDS instances that can be associated with a scaling group | |
Maximum number of CLB instances that can be associated with a scaling group | |
Maximum number of ALB server groups that can be associated with a scaling group | |
Maximum number of Network Load Balancer (NLB) server groups that can be associated with a scaling group | |
Maximum number of vServer groups that can be associated with a scaling group | |
Maximum number of instances allowed in a scaling group | |
Maximum number of scheduled tasks allowed in a region | |
Maximum number of ECS instances or elastic container instances that can be scaled at a time | 1000 |
Maximum number of instance types allowed in a scaling configuration | 10 |
Maximum number of notification rules allowed in a scaling group | 6 |
Maximum number of lifecycle hooks allowed in a scaling group | 10 |