Auto Scaling monitors your scaling group and automatically adjusts the number of Elastic Compute Service (ECS) instances based on the scaling modes you configure. It manages elastic container instances the same way. This document uses ECS instances to illustrate the workflow.
Workflow
The following diagram shows the components involved when Auto Scaling adds ECS instances.
The diagram uses a three-tier web application as an example. A Server Load Balancer (SLB) instance at the top layer forwards client requests to ECS instances in the scaling group at the middle layer. The ECS instances process the requests, while ApsaraDB RDS instances at the bottom layer store the application data. Auto Scaling adjusts the number of ECS instances at the middle layer.
When a scaling condition is met, Auto Scaling runs the following sequence:
Evaluate the scaling condition. Auto Scaling checks whether the conditions defined in your configured scaling modes are satisfied. For details on each mode, see Scaling modes.
Trigger the scaling rule. Auto Scaling calls the
ExecuteScalingRuleAPI operation with the unique identifier of the target scaling rule, for example:ari:acs:ess:cn-hangzhou:140692647406**:scalingrule/asr-bp1dvirgwkoowxk7**.To find the scaling rule identifier in the console, open the scaling rule list, click the ID in the Scaling Rule ID/Name column, and note the identifier on the details page (for example:
asr-bp14u7kzh8442w9z****).To find it via API, call DescribeScalingRules.
Resolve the scaling details. Auto Scaling uses the scaling rule identifier to retrieve the associated scaling group and scaling configuration. It determines the required number of ECS instances and queries any attached SLB and ApsaraDB RDS instances. It also retrieves the instance configuration, including the required vCPUs, memory, and bandwidth.
Execute the scaling activity. Auto Scaling provisions the required ECS instances based on the instance configuration source, then:
Adds the private IP addresses of the new instances to the ApsaraDB RDS instance whitelists.
Registers the new instances as backend servers for the SLB instance.
Activate the cooldown period. After the scaling activity completes, Auto Scaling starts the cooldown period for the scaling group. The cooldown period prevents rapid, repeated scaling triggered by metric fluctuations, ensuring that each scaling action has time to take effect before another is evaluated. The scaling group does not process new scaling requests until the cooldown period ends.
Create a corresponding scale-in configuration for each scale-out configuration. This ensures that Auto Scaling can remove instances when demand drops, not just add them when demand rises.
Scaling modes
Auto Scaling supports six scaling modes. Each mode triggers scaling under different conditions. Choose the mode that matches your traffic pattern.
| Scaling mode | When to use | Configuration method | Description |
|---|---|---|---|
| Fixed-quantity mode | When your application needs a fixed floor, ceiling, or exact instance count regardless of load | Scaling group + Instance configuration source | Controls instance count via three parameters: Minimum Number of Instances, Maximum Number of Instances, and (optional) Expected Number of Instances. Auto Scaling adds instances if the count falls below the minimum, removes instances if it exceeds the maximum, and adjusts to the expected count if one is set. |
| Health mode | Always recommended as a baseline — removes unhealthy instances automatically | Scaling group + Instance configuration source | Monitors ECS instances at specified intervals. Unhealthy instances are automatically removed and replaced. If an SLB instance with health check enabled is attached to the scaling group, both the SLB health check and the scaling group health check run simultaneously. The SLB instance can be a Classic Load Balancer (CLB) instance or an Application Load Balancer (ALB) instance. Enable this mode by turning on Instance Health Check when configuring the scaling group. |
| Scheduled mode | When demand follows a predictable schedule (for example, a daily traffic spike at noon) | Scaling group + Instance configuration source + Scaling rule + Scheduled task | A scheduled task triggers a scaling rule at a designated time. For example, create a scheduled task to add 20 ECS instances at 12:00 PM daily to handle a predictable midday spike. |
| Dynamic mode | When demand is unpredictable and you want to scale in response to real-time metrics | Scaling group + Instance configuration source + Scaling rule + Event-triggered task | An event-triggered task monitors a CloudMonitor performance metric (such as CPU utilization). When the metric crosses the alert condition — for example, average CPU utilization across all instances exceeds 60% — Auto Scaling executes the corresponding scaling rule. |
| Custom mode | When you need full manual control over instance count | Custom | Manually execute scaling rules or add, remove, or delete ECS instances directly. |
| Multi-mode | When a single mode is not enough to cover all traffic patterns | Combination of the above | Combine any of the above modes. Each mode operates independently with no priority order — Auto Scaling applies the configuration of whichever mode is triggered first. For example, if you use both scheduled and dynamic modes and the scheduled task fires before the event-triggered task, Auto Scaling executes the scheduled task first. |
Combining scheduled mode with dynamic mode is a common pattern. Use a scheduled task to pre-provision instances before a known traffic spike, and use dynamic mode to handle unexpected load on top of that baseline.
Configure scaling modes
Each scaling mode requires a specific set of components. The table below maps each mode to its required components.
| Scaling mode | Configuration method | Required components |
|---|---|---|
| Fixed-quantity mode | Basic | Scaling group + Instance configuration source |
| Health mode | Basic | Scaling group + Instance configuration source |
| Scheduled mode | Scheduled | Basic + Scaling rule + Scheduled task |
| Dynamic mode | Dynamic | Basic + Scaling rule + Event-triggered task |
| Custom mode | Custom | Manual operations on the scaling group |
| Multi-mode | Combination | Any combination of the above methods |
Configuration method details:
Basic: Create a scaling group, attach an instance configuration source, and enable both. Auto Scaling can only scale instances after both the scaling group and the instance configuration source are active. This is the foundation for all other modes.
Scheduled: Build on the basic method by creating a scaling rule and a scheduled task. The scheduled task triggers the scaling rule at the configured time.
Dynamic: Build on the basic method by creating a scaling rule and an event-triggered task. The event-triggered task monitors a CloudMonitor metric and triggers the scaling rule when the alert condition is met.
Workflows
Auto Scaling supports three core workflows. Scale-out and scale-in work together — configure both to ensure your application can respond to traffic increases and decreases.
Figure 1: Scale-out workflow
Figure 2: Scale-in workflow
Figure 3: Elastic recovery workflow
