This topic provides answers to some frequently asked questions about Auto Scaling.
Am I charged when I use Auto Scaling?
Auto Scaling is free of charge. You are not charged when you activate Auto Scaling or create scaling groups. However, you are charged for resources that are used in Auto Scaling. These resources include Elastic Compute Service (ECS) instances, elastic container instances, Server Load Balancer (SLB) instances, ApsaraDB RDS instances, and resources of other cloud services. For more billing information, see Billable items.
Why are ECS instances or elastic container instances that have overdue payments immediately released?
Auto Scaling provides the Health Check feature. If Auto Scaling detects a specific ECS instance or elastic container instance in a scaling group is not in the In Service state, the instance is considered unhealthy. Auto Scaling automatically removes the unhealthy instance from the scaling group and even releases the instance. For more information, see Instance lifecycles.
If you have overdue payments in your Alibaba Cloud account, all pay-as-you-go and preemptible ECS instances or elastic container instances in your scaling group are stopped. Auto Scaling considers stopped instances unhealthy and releases the unhealthy instances.
Make sure that you have sufficient balance in your Alibaba Cloud account. For information about status changes of ECS instances and elastic container instances in the event of overdue payments, see Expiration or overdue payment.
Am I charged for ECS instances or elastic container instances in scaling groups that are in the Disabled state?
Yes, you are still charged for the ECS instances or elastic container instances in a scaling group after the scaling group is disabled. You are not charged for the scaling group. However, you are charged for the instances in the scaling group.
Does Auto Scaling support automatic scaling of data disks?
No, Auto Scaling does not support automatic scaling of data disks.
Auto Scaling can automatically adjust only the number of ECS instances or elastic container instances in a scaling group. Auto Scaling cannot automatically change the number or sizes of data disks that are attached to an ECS instance or an elastic container instance.
Do I have to use Auto Scaling together with other Alibaba Cloud services such as SLB, CloudMonitor, and ApsaraDB RDS?
No, you do not have to use Auto Scaling together with other Alibaba Cloud services.
Auto Scaling is an open and flexible platform. You can decide whether to use SLB, ApsaraDB RDS, and CloudMonitor based on your business requirements. If you want to experience enhanced Auto Scaling capabilities, we recommend that you use Auto Scaling together with these Alibaba Cloud services.
For information about how to use Auto Scaling together with SLB, see What is CLB?
For information about how to use Auto Scaling together with ApsaraDB RDS, see What is ApsaraDB RDS?
For information about how to use Auto Scaling together with CloudMonitor, see Overview of CloudMonitor.
How many instances can I add to a scaling group?
You can add only a limited number of instances to a scaling group. For information about the limits, see Limits.
Can I add existing instances to scaling groups?
Yes, you can add existing instances to scaling groups.
Before you add existing instances to a scaling group, make sure that the following requirements are met:
The ECS instances or elastic container instances reside in the same region as the scaling group to which you want to add the instances. For more information, see Regions and zones.
The ECS instances or elastic container instances must be in the Running state. For more information, see Instance lifecycle or Lifecycle of an elastic container instance.
The ECS instances or elastic container instances are independent of other scaling groups.
Can I add existing subscription ECS instances to scaling groups?
Yes, you can add existing subscription ECS instances to scaling groups.
Auto Scaling automatically creates pay-as-you-go instances and preemptible instances in scaling groups. Auto Scaling also allows you to add existing subscription and pay-as-you-go instances to scaling groups.
Can I add an ECS instance or an elastic container instance to multiple scaling groups at the same time?
No, you cannot add an ECS instance or an elastic container instance to multiple scaling groups at the same time.
An ECS instance or elastic container instance can belong to one scaling group at a time. If you want to add an instance of a scaling group to another scaling group, you must first remove the instance from the original scaling group. For more information, see Manually remove or delete instances and Manually add ECS instances or elastic container instances to a scaling group.
Can I control how instances are removed from scaling groups?
Yes, you can control how instances are removed from scaling groups.
If you want to control how instances are removed from a scaling group, you can configure an instance removal policy that supports two-level filtering for the scaling group. In the instance removal policy, you can specify to remove instances that are created based on the earliest scaling configuration, instances that are created at the earliest point in time, or instances that are most recently created. For more information, see Create scaling groups.
Does Auto Scaling release ECS instances that are automatically created in a scaling group after I disable the scaling group?
No, Auto Scaling does not release automatically created ECS instances or elastic container instances in a scaling group after you disable the scaling group by using the Auto Scaling console or calling an API operation.
For information about how to enable a scaling group, see Disable a scaling group.
What factors may affect the time required to complete a scale-out process in a scaling group of the Elastic Container Instance type?
The scale-out latency is affected by factors such as the latency in initializing containers, the latency in starting applications, the latency in configuring lifecycle hooks, and the latency in registering external resources for the containers.
The time required to complete a scale-out process in a scaling group of the Elastic Container Instance type is the effective time of the lifecycle hook of an elastic container instance that is scaled out. For more information, see Overview of the Lifecycle Hook feature.
Can I add ECS instances of multiple instance types to a scaling group?
Yes, you can add ECS instances of multiple instance types to a scaling group.
When you create a scaling configuration, you can create multiple ECS instance types. This improves the success rate of scale-outs. However, you can add only a limited number of ECS instances each time. For more information, see Limits.
Can I create ECS instances that have 8 vCPUs or 16 vCPUs in a scaling group?
Yes, you can create ECS instances that have 8 vCPUs or 16 vCPUs in a scaling group.
If the currently available instance types cannot meet your business requirements, you can submit a ticket to request more ECS instance types.
How do I specify the disk size of ECS instances that are automatically created by Auto Scaling?
When you create a scaling configuration in the Auto Scaling console, you can specify the disk size in the Storage section. For more information, see Create a scaling configuration of the ECS type.
How do I make sure that Auto Scaling can dynamically create ECS instances when images from Alibaba Cloud Marketplace are used?
If you want Auto Scaling to create N instances that use the same Alibaba Cloud Marketplace image, you must purchase the image N times from Alibaba Cloud Marketplace in advance.
Can I buy multiple images from Alibaba Cloud Marketplace at the same time?
No, you cannot buy multiple images from Alibaba Cloud Marketplace at the same time.
How do I make sure that ECS instances can be created if the image that was used to create ECS instances is unavailable in Alibaba Cloud Marketplace?
In this case, we recommend that you purchase another available image from Alibaba Cloud Marketplace.
Why does an error message that indicates the Alibaba Cloud Marketplace image is unavailable appear when Auto Scaling creates ECS instances?
Problem: When Auto Scaling creates ECS instances based on an Alibaba Cloud Marketplace image, the following error is reported:
Fail to create Instance into scaling group("The specified image is from the image market. You have not bought it or your quota has been exceeded.").Cause: You specified a third-party image in your scaling configuration but you did not pay for the image, or your image quota has exceeded the upper limit.
Solution: Auto Scaling cannot create ECS instances based on a third-party image unless you pay for the third-party image in Alibaba Cloud Marketplace.
Can images from different regions use the same product code?
Yes, images from different regions can use the same product code only if the images are supported in the region of the product code.
Can I use 100 images that have the same product code in any region after I purchase the images?
No, you cannot use the images that have the same product code in any region. Alibaba Cloud Marketplace images are region-specific. If you want to use images in a specific region, you must purchase the images in the region.
Can I create scheduled tasks that are periodically executed?
Yes, you can create scheduled tasks that are periodically executed. For more information, see Create scheduled tasks.
Is there an execution priority between an event-triggered task and a scheduled task?
Event-triggered tasks and scheduled tasks cannot be triggered at the same time. They are independent of each other and are not prioritized over each other.
If an event-triggered task is rejected but the trigger conditions are still met, the event-triggered task is still executed after the current scaling activity is complete.
You can specify a retry interval for a scheduled task. This prevents the scheduled task from being rejected when you attempt to retry it upon failure. For more information, see Create scheduled tasks.
What metrics are used by event-triggered tasks to trigger scaling activities?
Event-triggered tasks can trigger scaling activities based on CloudMonitor metrics such as the CPU utilization, memory usage, average system load, and inbound or outbound traffic. For more information, see Event-triggered tasks of the system monitoring type.
How do I configure trigger conditions for event-triggered tasks?
Before you configure trigger conditions for event-triggered tasks, you must install the latest version of CloudMonitor on your ECS instances. For information about how to install the CloudMonitor agent, see Install the CloudMonitor agent for Java.
Then, you can configure trigger conditions based on your business requirements when you create event-triggered tasks. For more information, see Create event-triggered tasks.
How do I use event-triggered tasks to delete instances that are created by Auto Scaling?
To use an event-triggered task to delete instances that are created by Auto Scaling, specify a scale-in rule as the trigger rule in the event-triggered task. For more information, see Create a scaling rule and Create event-triggered tasks.
Does Auto Scaling support dynamic scaling based on custom CloudMonitor metrics?
Yes, Auto Scaling supports dynamic scaling based on custom CloudMonitor metrics. For more information, see Event-triggered tasks of the custom monitoring type.
What kind of Auto Scaling information do I need to provide when I submit a ticket to troubleshoot issues?
When you submit a ticket, you must provide the scaling activity ID and relevant logs to facilitate troubleshooting.
For more information about scaling activities, see View the details of a scaling activity.
Why does an error message appear when Auto Scaling creates ECS instances?
If the following error messages appear when Auto Scaling creates ECS instances, the resources may be insufficient in the current zone. Switch to another zone and try again.
Fail to create Instance into scaling group("The resource is out of usage.").Fail to create Instance into scaling group("The specified region is in resource control, please try later.").How do I prevent scale-out failures caused by insufficient instance types?
We recommend that you specify multiple zones (select vSwitches of different zones) when creating a scaling group and select multiple instance types when creating a scaling configuration. If an instance type is insufficient in one of the specified zones, Auto Scaling automatically switches to another zone that has sufficient instance types and executes the scale-out. For more information, see Create scaling groups and Create a scaling configuration of the ECS type.
Why are ECS instances still released even if I enabled the Release Protection feature for the instances?
If you enabled the Release Protection feature for an automatically created ECS instance by using the ECS console or calling the ModifyInstanceAttribute operation, the Release Protection feature cannot prevent the ECS instance from being released by Auto Scaling.
In you do not want to automatically release the ECS instance, you can put the ECS instance into the Protected state. For more information, see Manually put instances into the Protected state or move instances out of the Protected state.
How do I prevent instances that are manually added to a scaling group from being removed from the scaling group?
To prevent ECS instances or elastic container instances from being removed from your scaling group, you can put the instances into the Protected state. For more information, see Manually put instances into the Protected state or move instances out of the Protected state.
Does Auto Scaling automatically add or remove the private IP addresses of ECS instances to or from the IP address whitelists of ApsaraDB RDS instances or ApsaraDB for Memcache instances during scaling activities?
Auto Scaling only adds the private IP addresses of ECS instances to the IP address whitelists of the associated ApsaraDB RDS instances during scaling activities.
How do I prevent instances that are manually added to a scaling group from being automatically released?
For example, if your scaling group has 100 ECS instances or elastic container instances, you can perform the following operations to prevent the 100 instances from being automatically released:
Set the Minimum Number of Instances parameter of your scaling group to 100.
Set the first step of the Scale-in Policy parameter to Earliest Instance Created Using Scaling Configuration.
The earliest scaling configuration does not apply to ECS instances or elastic container instances that are manually added to your scaling group. Therefore, the scale-in policy cannot take effect on instances that are manually added. Auto Scaling preferentially releases ECS instances or elastic container instances that are automatically created. If all automatically created instances are removed, Auto Scaling removes the instances that are manually added but does not release the instances.
Do not stop ECS instances or elastic container instances that are manually added to your scaling group. Otherwise, Auto Scaling considers the stopped instances unhealthy and removes the unhealthy instances from your scaling group.
Is data stored on ECS instances retained after the ECS instances are removed from a scaling group and released?
No, data stored on ECS instances is not retained.
Auto Scaling may automatically release ECS instances. Do not store application status information or important data of sessions, databases, and logs on ECS instances. We recommend that you use independent ECS instances, ApsaraDB RDS instances, or Simple Log Service projects to store your application status information.
How do I delete instances that are automatically created by Auto Scaling?
You can go to the Instances tab of the Auto Scaling console to delete automatically created ECS instances or elastic container instances. For more information, see Manually remove or delete instances.
Does Auto Scaling continue to create ECS instances after it fails to create the required number of ECS instances?
No, Auto Scaling maintains the integrity of instance-level transactions rather than scaling activity-level transactions. You can go to the Scaling Activities tab of the Auto Scaling console to view the status of a scaling activity. For more information, see View the details of a scaling activity.
For example, your business requires Auto Scaling to create 20 ECS instances, but Auto Scaling creates only 19 ECS instances. Then, only 19 ECS instances are added to your scaling group. Auto Scaling considers the scaling activity completed without retrying to create the failed ECS instance. The scaling activity enters the Warning state.
How do I obtain the password that is required to log on to an ECS instance that is created by Auto Scaling?
Auto Scaling does not allow you to specify custom passwords in scaling configurations. If you use a Linux OS, we recommend that you specify an SSH key pair in your effective scaling configuration. Then, you can use the SSH key pair to log on to the ECS instance.
If you do not use the SSK key pair to log on to the ECS instance, you must reset the password of the ECS instance in the ECS console, and then restart the ECS instance to put the new password into effect.
Why am I unable to use the password that is specified in my custom image to log on to an ECS instance that is automatically created by Auto Scaling?
To ensure security, Auto Scaling does not support logons to automatically created ECS instances based on the passwords specified in custom images. We recommend that you specify an SSH key pair in the effective scaling configuration. Then, you can use the SSH key pair to log on to the ECS instance.
If you do not use the SSK key pair to log on to the ECS instance, you must reset the password of the ECS instance in the ECS console, and then restart the ECS instance to put the new password into effect.
How do I synchronize data to ECS instances in a scaling group?
You can specify a custom image in the scaling configuration to create ECS instances. This way, you can synchronize data to the created ECS instances. To synchronize data to or from a running ECS instance, we recommend that you install rsync on the ECS instance and use rsync to synchronize data.
Why is IP address 127.0.0.1 deleted from the /etc/hosts file of ECS instances that are automatically created by Auto Scaling?
If you use a custom image in which the /etc/hosts file is modified, the file is restored to the default settings when Auto Scaling automatically creates ECS instances by using the custom image. Therefore, your modifications to the /etc/hosts file are lost. To retain the modifications to the /etc/hosts file, add a script to the rc.local file to check whether the required information exists in the /etc/hosts file, and add the information if the information does not exist.
What does an SLB instance do after it is associated with a scaling group?
The SLB instance forwards traffic to ECS instances in the scaling group based on the routing method. By associating an SLB instance with a scaling group, you can improve the performance and availability of your application. For more information, see What is CLB?
How do SLB instances work with scaling groups?
You can associate an SLB instance with one or more scaling groups. Then, Auto Scaling automatically adds ECS instances in the scaling groups to the backend server groups of the SLB instance. By default, the SLB weight of an ECS instance is 50. For information about SLB backend servers, see Add an ECS instance to the default server group.
Can Auto Scaling add ECS instances that are automatically created to the backend server group of an SLB instance?
Yes, Auto Scaling can add ECS instances that are automatically created to the backend server group of an SLB instance. However, the SLB instance must be associated with the scaling group in which Auto Scaling creates the ECS instances.
Can Auto Scaling add ECS instances that are automatically created to the backend server groups of multiple SLB instances?
Yes, Auto Scaling can add ECS instances that are automatically created to the backend server groups of multiple SLB instances.
You can associate a scaling group with multiple SLB instances, but the number of SLB instances is limited. For more information, see Limits.
Can I change the SLB weight of an ECS instance?
Yes, you can change the SLB weight of an ECS instance. For more information, see Add an ECS instance to the default server group.
An SLB instance balances loads among the backend servers based on the ratio of their weights. For example, you have two ECS instances and the SLB weights of the instances are 50. If you change the SLB weights of the ECS instances from 50 to 100, the SLB instance balances loads among the two ECS instances in the same manner. This is because the weight ratio remains 1:1. In most cases, ECS instances in a scaling group provide the same service and are of the same instance type. Therefore, the SLB weights of the ECS instances are the same. The default SLB weight of an ECS instance is 50.
Do I need to configure the public bandwidth for ECS instances when I create a scaling configuration if my scaling group is associated with an Internet-facing SLB instance?
No, public bandwidth is an optional setting for ECS instances. However, when you create a scaling configuration, we recommend that you set the public bandwidth to at least 1 Mbit/s to facilitate the management of ECS instances.
Why is a health check error about the specified SLB instance reported when I create a scaling group?
If the following error message appears, the Health Check feature is disabled for the specified SLB instance.
The current health check type of load balancer "xxxx" does not support this action.You must enable the Health Check feature for the SLB instance that is associated with your scaling group. For more information, see Configure and manage health checks.
How does an SLB instance check whether a new ECS instance can process requests?
After a new ECS instance is added to a scaling group, the SLB instance that is associated with the scaling group checks whether the corresponding ports on the ECS instance respond to requests. The SLB instance forwards requests to the new ECS instance only when the ports on the ECS instance pass the check.
Why does the timeout period of a Layer-7 HTTP listener on an SLB instance exceed 60 seconds?
Problem: The timeout period of an HTTP listener on an SLB instance is approximately 60 seconds. However, when multiple ECS instances are attached to the SLB instance, the timeout period for configuring the ECS instances exceeds 60 seconds, or the 505 error code is returned.
Cause: The timeout period of an HTTP listener on an SLB instance is used to ensure that a response can be returned within the allowed time range. The total timeout period of all HTTP listeners varies based on the number of attached ECS instances.
If you attach multiple ECS instances to an SLB instance and the request to the first ECS instance times out, the SLB instance forwards the request to the next ECS instance to obtain a response. The SLB instance continues the forwarding until one of the attached ECS instances returns a response for the request within the allowed time range. For example, if you attach three ECS instances to an SLB instance, the actual timeout period of an HTTP request may reach 180 seconds. In addition, specific Alibaba Cloud services may place limits on the timeout period setting of an HTTP listener on an SLB instance.
Solution: We recommend that you configure timeout periods of HTTP listeners in applications deployed on ECS instances.
What does an ApsaraDB RDS instance do after it is associated with a scaling group?
ApsaraDB RDS is a stable, reliable, and scalable online database service. When you associate an ApsaraDB RDS instance with a scaling group, you can back up data of the scaling group to the ApsaraDB RDS instance based on custom backup policies. This improves the security and reliability of your data and allows you to restore data that is deleted by mistake. For more information, see What is ApsaraDB RDS?
How do ApsaraDB RDS instances work with scaling groups?
If you associate a scaling group with one or more ApsaraDB RDS instances, Auto Scaling adds the private IP addresses of the ECS instances that are scaled out in the scaling group to the IP address whitelists of the associated ApsaraDB RDS instances. This enables communication between ECS instances over an internal network. You can associate multiple ApsaraDB RDS instances with a scaling group. For more information about the IP Address Whitelist feature of ApsaraDB RDS, see Use a database client or the CLI to connect to an ApsaraDB RDS for MySQL instance.