This topic answers frequently asked questions (FAQs) to help you troubleshoot and resolve issues when you use Auto Scaling.
Is Auto Scaling a paid service?
Auto Scaling itself is a free service. You are not charged for activating the service or creating a scaling group. However, you are charged for the resources you use with the service, such as ECS instances, ECI instances, SLB instances, and ApsaraDB RDS instances. For more information, see Billing of associated resources.
Why are my ECS or ECI instances released immediately after my account has an overdue payment?
Auto Scaling provides a health check feature. If an ECS or ECI instance is not in the Running state, Auto Scaling considers the instance unhealthy. Unhealthy instances are automatically removed from the scaling group and may be released. For more information, see Instance lifecycle in a scaling group.
If your account has an overdue payment, all postpaid instances in the scaling group, including pay-as-you-go and spot instances, are stopped. Auto Scaling identifies these stopped instances as unhealthy, and then removes and releases them.
Ensure your account has a sufficient balance. For information about how instance statuses change due to overdue payments, see Expiration and overdue payments.
Am I still charged for ECS or ECI instances after I disable a scaling group?
Yes. The scaling group itself is free, but you are charged for the ECS or ECI instances within it. If instances remain in a scaling group after you disable it, you continue to be charged for those instances.
Can Auto Scaling scale out pay-as-you-go instances if my account balance is less than CNY 100?
No.
If the combined total of your Alibaba Cloud account balance (cash balance) and vouchers is less than CNY 100.00, you cannot purchase new pay-as-you-go instances, such as ECS or ECI instances. As a result, scale-out activities fail.
Does Auto Scaling support automatic scaling of data disks?
No.
Auto Scaling can automatically increase or decrease the number of ECS or ECI instances in a scaling group. It does not support changing the configuration of an individual instance, such as the number or size of its data disks.
Must I use Auto Scaling with SLB, CloudMonitor, and ApsaraDB RDS?
No.
Auto Scaling is a flexible service that can be used independently. However, integrating it with other services such as SLB, CloudMonitor, and ApsaraDB RDS can enhance its capabilities. For example:
-
Deploy with SLB for traffic distribution. For more information, see What is Classic Load Balancer (CLB)?.
-
Deploy with ApsaraDB RDS for managed databases. For more information, see What is ApsaraDB RDS?.
-
Use CloudMonitor to trigger scale-out and scale-in activities. For more information, see Overview of event-triggered tasks.
How many instances can I add to a scaling group?
For information about the limits on the number of instances and other Auto Scaling resources, see Limits.
Can I add existing instances to a scaling group?
Yes.
The ECS or ECI instances you want to add must meet the following conditions:
-
The instance must be in the same region as the scaling group. For more information, see Regions and zones.
-
The instance must be in the Running state. For more information, see Instance lifecycle or ECI instance lifecycle.
-
The instance must not belong to another scaling group.
Can I add existing subscription ECS instances to a scaling group?
Yes.
Auto Scaling can automatically create pay-as-you-go or spot instances. It also supports adding existing subscription and pay-as-you-go instances to a scaling group.
Can an ECS or ECI instance be added to multiple scaling groups?
No.
An instance can belong to only one scaling group at a time. To move an instance from one scaling group to another, you must first remove it from the original group and then add it to the new one. For more information, see Manually remove instances and Manually add instances to a scaling group.
How can I control which instances are removed during a scale-in?
You can configure a scale-in policy for a scaling group. The policy uses a two-level filtering system to select which instances to remove, such as those created from the earliest scaling configuration, the oldest instances, or the newest instances. For more information, see Create a scaling group.
Are instances that are automatically added to a scaling group released after the group is disabled?
No.
Disabling a scaling group in the console or by using an API call does not automatically release the ECS or ECI instances within it. For information about how to disable a scaling group, see Disable a scaling group.
What factors affect the scale-out latency for a scaling group of ECI instances?
The main factors that affect scale-out latency for scaling groups of ECI instances include container initialization time, application startup time, lifecycle hook configuration time, and the time required for scaled-out containers to register with external resources.
For a scaling group of ECI instances, the scale-out time is the duration of the entire lifecycle of the ECI being scaled out. For more information about ECI lifecycle hooks, see Lifecycle hooks.
Can a scaling group contain multiple ECS instance types?
Yes.
You can select multiple ECS instance types in a single scaling configuration. This increases the probability of a successful scale-out. However, limits apply to the number of instance types you can add. For more information, see Limits.
Can I configure 8-core or 16-core ECS instances in a scaling group?
Yes.
If the available instance types do not meet your requirements, you can submit a ticket to request additional ECS instance types.
How do I specify the data disk capacity for ECS instances that are automatically created by Auto Scaling?
When you create a scaling configuration, you can specify the data disk capacity in the storage settings. For more information, see Create a scaling configuration for ECS instances.
How can I ensure that ECS instances are launched successfully when I use an image from Alibaba Cloud Marketplace?
If you need to launch N instances of the same image, you must first purchase N licenses for the image from Alibaba Cloud Marketplace.
Does Alibaba Cloud Marketplace support purchasing images in bulk?
Bulk purchasing is not currently supported.
How can I ensure that ECS instances are launched successfully if an Alibaba Cloud Marketplace image I used is no longer available?
Select another available image from Alibaba Cloud Marketplace.
Why did a scale-out activity fail with an "Alibaba Cloud Marketplace image unavailable" error?
Symptom: When a scaling group attempts to create an ECS instance, 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: This error occurs because the scaling configuration uses a third-party image from Alibaba Cloud Marketplace that you have not purchased, or you have exceeded your purchase quota for the image.
Solution: Auto Scaling cannot automatically create ECS instances from third-party images in Alibaba Cloud Marketplace unless you purchase them first. Go to Alibaba Cloud Marketplace to purchase the required third-party image. After purchasing the image, you can use Auto Scaling to create ECS instances from that image.
Can one product code be used for images in different regions?
Yes, provided the image is available in the region.
If I purchase 100 licenses for an image with the same product code, can I use them in any region?
Alibaba Cloud Marketplace images are region-specific. You must purchase images for the region where you intend to use them.
Can I set up recurring scheduled tasks?
Yes. For more information, see Create a scheduled task.
Is there an execution priority between event-triggered tasks and scheduled tasks?
Event-triggered tasks and scheduled tasks are independent and do not trigger simultaneously. There is no execution priority between them.
If an event-triggered task fails but its trigger conditions are still met, the task runs again after the current scaling activity is complete.
You can set a retry interval for a scheduled task to ensure it re-triggers after a failed execution. For more information, see Create a scheduled task.
What conditions can trigger an event-triggered task in Auto Scaling?
An event-triggered task can automatically add or remove ECS or ECI instances based on monitoring metrics such as CPU utilization, memory usage, average system load, and internal network traffic. For more information, see Event-triggered tasks based on system monitoring.
How do I set the trigger conditions for an event-triggered task?
Before you use an event-triggered task, make sure that the latest version of the CloudMonitor agent is installed on your ECS instances. If it is not installed, see Install the CloudMonitor agent for Java.
When you create an event-triggered task, select the trigger conditions that match your business requirements. For more information, see Create an event-triggered task.
How do I use an event-triggered task to delete instances created by Auto Scaling?
When you create an event-triggered task, select a scaling rule for removing instances as the trigger. For more information, see Create a scaling rule and Create an event-triggered task.
Can Auto Scaling perform dynamic scaling based on custom metrics in CloudMonitor?
Yes. For more information, see Event-triggered tasks based on custom monitoring.
What information should I provide when I submit a ticket for an Auto Scaling issue?
When you submit a ticket, provide the scaling activity ID (ScalingActivityId) and any relevant logs to help us quickly troubleshoot the issue.
To view scaling activities, see View scaling activity details.
Why do I encounter a resource error when a scaling group creates an ECS instance?
If you receive the following error messages, these errors may indicate insufficient ECS resources. We recommend that you 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 can I prevent scale-out failures caused by insufficient inventory of a single instance type?
Configure multiple zones for your scaling group by selecting vSwitches in different zones. Additionally, specify multiple instance types in your scaling configuration. If an instance type is unavailable in one zone, Auto Scaling automatically attempts to create an instance of another specified type in a different available zone. For more information, see Create a scaling group and Create a scaling configuration for ECS instances.
Why was an ECS instance in my scaling group automatically released even though I enabled Release Protection for it?
After Auto Scaling automatically creates an ECS instance, if you enable Release Protection for the instance on the instance list page of the ECS console or by using the ModifyInstanceAttribute API, it does not prevent Auto Scaling from automatically releasing the instance.
To prevent an instance from being automatically released during a scale-in, you must set the instance to a protected state within the scaling group. For more information, see Set instance protection.
How do I prevent manually added instances from being removed from a scaling group?
To prevent an ECS or ECI instance from being automatically removed, you can set it to a protected state within the scaling group. For more information, see Set instance protection.
Does Auto Scaling auto-update the IP whitelist of ApsaraDB RDS or Memcache instances?
Auto Scaling automatically adds the IP address of an ECS instance to or removes it from the IP address whitelist of an associated ApsaraDB RDS instance. This does not apply to Memcache instances.
How do I prevent manually added instances in a scaling group from being automatically removed?
To ensure that 100 manually added ECS or ECI instances are not automatically removed from a scaling group, use the following configuration:
-
Set the minimum number of instances to 100 or greater.
-
Set the first-level scale-in policy to Instances Created From Earliest Scaling Configuration.
Because manually added instances were not created by a scaling configuration, this policy does not apply to them. The scaling group first removes automatically created instances. Only after all automatically created instances are removed does the scaling group remove manually added instances until the minimum instance count is reached.
Do not stop manually added instances if you want to prevent them from being removed. Auto Scaling considers stopped instances unhealthy and automatically removes them from the scaling group regardless of other settings.
Is data on an ECS instance retained after the instance is removed from a scaling group and released?
No.
Auto Scaling automatically releases ECS instances. You must ensure that instances in a scaling group do not store stateful information or critical data, such as session data, databases, or logs. If your application needs to maintain state, store state information on a separate stateful server such as a dedicated ECS instance, in a managed database such as ApsaraDB RDS, or in a logging service.
How do I delete instances created by Auto Scaling?
You can delete automatically created ECS or ECI instances from the instance list within the scaling group. For more information, see Manually remove or delete instances.
What happens if some ECS instances fail to be created during a scale-out activity?
Auto Scaling ensures the integrity of instance-level transactions, not scaling activity-level transactions. You can view the completion status of a scaling activity in the console. For more information, see View scaling activity details.
For example, if a scaling activity requests to add 20 ECS instances but only 19 are successfully created and one fails, the 19 successful instances are added to the scaling group. The system does not retry creating the failed instance. The scaling activity is completed, but its status is set to Warning. In another example, a scaling activity requests to add five ECS instances, but only two are successfully created because the backend server quota of the SLB instance is exceeded. The other three are ignored. In this case, the scaling activity status is set to Warning. You can view the scaling activity details to find the cause, status, and specific reason for the failure, such as "Backend server quota exceeded in load balancer".
How do I find the password and log on to an instance automatically created by Auto Scaling?
Scaling configurations do not support setting a unified custom password. If you use a Linux operating system, specify an SSH key pair in the scaling configuration.
If you do not use an SSH key pair to log on to an instance, you must reset the instance password in the console. The new password takes effect after the instance restarts.
Why is the instance password different from the image password?
When an ECS instance is created, the instance does not inherit its login password from the custom image. For security reasons, specify an SSH key pair in the scaling configuration.
If you do not use an SSH key pair to log on to an instance, you must reset the instance password in the console. The new password takes effect after the instance restarts.
How do I synchronize data to ECS instances within a scaling group?
When you create a scaling configuration, you can use a custom image to create instances with pre-configured data. To synchronize data between running ECS instances, install and use a tool like rsync.
Why is the 127.0.0.1 entry I added to /etc/hosts cleared on a newly launched instance?
If you create a custom image after you modify the /etc/hosts file, your changes are cleared when an ECS instance is automatically created from that custom image because the file is restored to its default system settings. If you need to retain the /etc/hosts settings, you can try adding script code to the rc.local file to check whether the relevant information exists in the /etc/hosts file and automatically add the information if it does not exist.
What is the purpose of associating a scaling group with an SLB instance?
An SLB instance distributes incoming traffic across multiple ECS instances based on forwarding rules. Associating an SLB instance with your scaling group helps scale your application's capacity and improve its availability. For more information about load balancing, see What is Classic Load Balancer (CLB)?.
How do scaling groups use SLB instances?
If you associate an SLB instance when you create a scaling group, the scaling group automatically adds new ECS instances to that SLB instance. A single SLB instance can be associated with multiple scaling groups. The default weight for an ECS instance added to an SLB instance is 50. For more information about backend servers, see Manage the default server group.
When Auto Scaling creates an ECS instance, is the new instance automatically added to the associated SLB instance?
Yes, provided that you have associated an SLB instance with the scaling group beforehand.
Can a new instance created by Auto Scaling be added to multiple SLB instances?
Yes.
You can associate a scaling group with multiple SLB instances, but a limit applies. For more information, see Limits.
Can I change the weight of an instance within a scaling group in the associated SLB instance?
Yes. For more information, see Manage the default server group.
An SLB instance calculates the weights of its backend servers as a ratio, not an absolute value. For example, if you have two instances, setting their weights to 50 and 50 has the same effect as setting them to 100 and 100, as the ratio is 1:1 in both cases. Typically, all backend ECS instances in a scaling group handle the same type of traffic and have the same specifications. The default weight for an ECS instance configured by Auto Scaling is 50.
Do ECS instances need public bandwidth if the SLB is internet-facing?
Configuring a public bandwidth for ECS instances is optional. However, to make managing your instances easier, we recommend that you assign a public bandwidth of at least 1 Mbit/s when you create the scaling configuration.
Why do I receive a health check error for the SLB instance when creating a scaling group?
If you receive the following error, it means that health checks are not enabled for the SLB instance.
The current health check type of load balancer "xxxx" does not support this action.You must enable health checks for any SLB instance that you associate with a scaling group. For more information, see Configure and manage health checks for a CLB instance.
How can I determine if a newly created ECS instance is ready to handle traffic?
If you have configured an SLB instance for your scaling group, the SLB instance forwards requests to a new instance only after the instance passes the health checks for your backend ECS ports.
Why does the timeout for a Layer 7 HTTP listener on an SLB instance exceed 60 seconds?
Symptom: A single HTTP request forwarded by an SLB instance times out after about 60 seconds. However, when multiple ECS instances are configured as backend servers, the total time to receive a timeout or a 504 error is much longer than 60 seconds.
Cause: The SLB HTTP listener timeout is the final guardrail to ensure a request returns within an allowed time. The total timeout depends on the number of configured ECS instances.
When multiple ECS instances are configured, if a request to the first instance times out, the SLB instance automatically retries the request with the second instance, and so on, until it has tried all instances. For example, if an SLB instance has three backend ECS instances, the actual HTTP request timeout could be approximately 180 seconds. Other services might also impose their own limits on the SLB timeout setting.
Solution: Do not rely on the SLB listener timeout setting. Instead, configure the timeout directly in the application deployed on your ECS instances.
What is the purpose of associating a scaling group with an ApsaraDB RDS instance?
ApsaraDB RDS is a stable, reliable, and scalable online database service. Associating an ApsaraDB RDS instance with a scaling group can improve data security and reliability. You can use custom backup policies to prevent data loss or accidental deletion. For more information about ApsaraDB RDS, see What is ApsaraDB RDS?.
How do scaling groups use ApsaraDB RDS instances?
If you add an ApsaraDB RDS instance when you create a scaling group, the scaling group automatically adds the private IP address of any new ECS instance to the IP address whitelist of the ApsaraDB RDS instance. This allows internal network communication between the ECS instances and the database. You can associate a scaling group with multiple ApsaraDB RDS instances. For more information about ApsaraDB RDS whitelists, see (Deprecated) Configure an IP address whitelist for an ApsaraDB RDS for MySQL instance.