Auto Scaling automates capacity management so your applications stay available and cost-efficient without manual intervention. Key benefits:
Automation — Scale-out and scale-in happen automatically based on your configurations, with integrated updates to load balancer and database allowlists.
Cost-effectiveness — Resources are provisioned when demand rises and released when it falls, so you pay for capacity only when you need it.
High availability — Unhealthy instances are detected and replaced automatically, without interrupting your service.
Flexible configuration — Five scaling modes, multiple instance configuration sources, and a range of scaling policies let you match capacity management to your workload.
Audit and monitoring — Every scaling activity is logged, and CloudMonitor provides ongoing visibility into instance health.
Automation
Auto Scaling performs scaling based on your configurations, eliminating the risk of errors from manual intervention.
Scale-out
Auto Scaling creates the specified number of Elastic Compute Service (ECS) instances or elastic container instances (ECI) and adds them to your scaling group.
If the scaling group is associated with a Server Load Balancer (SLB) instance, Auto Scaling attaches the new instances to the SLB instance so it can forward requests to them.
If the scaling group is associated with an ApsaraDB RDS instance, Auto Scaling adds the IP addresses of the new instances to the ApsaraDB RDS whitelist, allowing applications on those instances to write data to the database.
Scale-in
Auto Scaling removes the specified number of ECS instances or elastic container instances from your scaling group, releasing idle resources.
If the scaling group is associated with an SLB instance, Auto Scaling detaches the removed instances so the SLB instance stops forwarding requests to them.
If the scaling group is associated with an ApsaraDB RDS instance, Auto Scaling removes the IP addresses of the detached instances from the whitelist. Applications on those instances can no longer write to the ApsaraDB RDS instance.
Cost-effectiveness
Auto Scaling provisions resources when demand increases and releases them when it decreases, improving resource utilization and reducing costs. You do not need to provision extra instances in advance to handle peak load, and idle capacity does not accumulate during off-peak periods. Auto Scaling also reduces the time your team spends on manual capacity adjustments.
High availability
Auto Scaling monitors the health of every ECS instance and elastic container instance in your scaling group. If an instance fails a health check or stops running as expected, Auto Scaling marks it as unhealthy, terminates it, and launches a replacement without interrupting your service.
Scaling modes
Auto Scaling supports five scaling modes that you can combine based on your workload:
| Scaling mode | How it works |
|---|---|
| Fixed-number mode | Maintains a constant number of instances in your scaling group. |
| Health mode | Replaces instances that fail health checks to keep the group healthy. |
| Scheduled mode | Scales capacity up or down at predefined times. |
| Dynamic mode | Adjusts capacity in response to CloudMonitor metrics. You can also call API operations to integrate external monitoring systems with CloudMonitor. |
| Custom mode | Lets you define your own scaling logic. |
For details, see Scaling modes.
Instance configuration sources
Auto Scaling supports multiple instance configuration sources, giving you flexibility in how you define instances created during scale-out:
Specify an existing instance as the configuration source.
Create a scaling configuration from scratch.
If you set the Type parameter to ECS when creating a scaling group, specify a launch template as the configuration source.
You can also specify multiple instance types in a single configuration, which increases the success rate of scale-out activities when capacity for a specific instance type is limited:
For ECS scaling groups, specify multiple instance types and disk types in the template.
For ECI scaling groups, specify multiple vCPU and memory combinations to define the range of eligible instance types.
For details, see Instance configuration source overview.
Scaling policies
For scaling groups where Type is set to ECS, Auto Scaling provides the following scaling policies. For ECI scaling groups, the default scaling policy applies.
| Policy | Behavior |
|---|---|
| Priority policy | Scales instances in the highest-priority zone first. If that zone cannot fulfill the request, Auto Scaling falls back to the next highest-priority zone. |
| Balanced distribution policy | Creates ECS instances evenly across all availability zones to maintain high availability. |
| Cost optimization policy | When multiple instance types are configured, creates instances with the lowest vCPU unit price first and removes instances with the highest vCPU unit price first. |
| Instance removal policy | Removes instances created from the earliest scaling configuration, or removes instances created at the earliest or latest point in time. |
| Instance reclaim policy | Releases all ECS instances, or retains specific resources to reduce costs. |
For details on creating a scaling group and configuring these policies, see Create a scaling group.
Audit and monitoring
Auto Scaling records the details of each scaling activity, making it straightforward to identify and troubleshoot issues. CloudMonitor lets you track whether instances in your scaling group are running as expected, so you can maintain service availability without manual spot-checks.