When database traffic spikes unexpectedly, manually scaling up an instance takes time—and if you forget to scale back down, you pay for resources you no longer need. Automatic performance scaling, powered by Database Autonomy Service (DAS), handles both directions automatically: the instance scales up when CPU utilization crosses your threshold, and scales back down when the load subsides.
How it works
Scaling behavior differs between cloud disk instances and premium local disk instances.
Cloud disk instances (ESSD and premium performance disks)
During the Observation Window, the system checks CPU utilization periodically. Each time the average CPU utilization meets or exceeds the CPU Trigger Threshold, the instance scales up one step—CPU, memory, IOPS, and maximum connections all increase together. This repeats until the instance reaches the Maximum Specifications you set.
Scale-down is triggered when both of the following are true:
-
The instance is not in the Cool-down Period.
-
During the Scale-down Observation Window (Observation Window + 10 minutes), CPU utilization stays below 30% for more than 99% of the time.
The system scales down in steps back to the specifications before the scale-up.
A transient connection lasting up to 30 seconds may occur during a configuration change. Schedule changes during off-peak hours and make sure your application has a reconnection mechanism.
Premium local disk instances (General-purpose)
During the Scale-up Observation Window, if CPU utilization meets or exceeds the threshold, the number of CPU cores is doubled. IOPS increases by 1,000 for each added CPU core. Memory and maximum connections are not increased, and no further scale-ups occur after the initial doubling.
If host resources are insufficient (probability less than 1%), the scale-up is not performed.
Scale-down is triggered when CPU utilization stays below 30% for more than 99% of the time during the Scale-down Observation Window. Both CPU and IOPS return to the level before the scale-up.
Premium local disk scale-up and scale-down operations complete within 30 seconds with no instance switchover and no perceptible impact to users.
Prerequisites
Before you begin, ensure that you have:
-
An ApsaraDB RDS for MySQL instance that meets all of the following:
-
Billing method: subscription or pay-as-you-go (Serverless instances scale automatically and do not require configuration)
-
Storage class: cloud disks (General-purpose or Dedicated) or premium local disks (General-purpose)
-
Product series: High-availability Edition
-
Instance type: Standard Edition
-
Region: supports the DAS anomaly detection feature
-
-
Sufficient account balance to cover the cost of a scale-up
Automatic performance scaling is not supported for instances that use phased-out instance types with cloud disks. To use this feature, first change the phased-out instance type to a current instance type.
Limits and side effects
Read-only instances
Automatic scale-up settings on the primary instance are not applied to its read-only instances. Configure automatic scale-up separately for each read-only instance.
After a primary/secondary switchover
Scale-up operations run on the primary instance only. If a switchover occurs after a scale-up:
-
The new primary instance (originally the secondary) is automatically scaled up or down if it meets the trigger conditions.
-
The new secondary instance (originally the primary) is automatically scaled down to the original specifications if it meets the scale-down conditions.
Side effects of enabling the feature
-
The instance's minor version is upgraded to the latest version if it is not already running it.
-
Enabling automatic scale-up grants the AliyunServiceRoleForDAS service-linked role to DAS, so DAS can access ApsaraDB resources.
Billing
Cloud disk instances (General-purpose and Dedicated)
After a scale-up, charges are based on the new instance type. Fees vary by region and the new specifications. For details, see the buy page.
Premium local disk instances (General-purpose)
Charged on a pay-as-you-go basis, billed by the hour.
Formula: Fee per CPU core × Number of CPU cores added × Scale-up duration (hours)
Example: An instance in China (Hangzhou) has 4 CPU cores. After a scale-up, it has 8 cores. The scale-up lasts 30 minutes. The unit price is USD 0.083 per core-hour.USD 0.083 per core-hour0.083 (unit price) × 4 (number of added cores) × 0.5 (hours) = USD 0.166
Fee = 0.083 × 4 × 0.5 = USD 0.166
Unit price by region (USD per core-hour)
| Region | Unit price |
|---|---|
| China (Zhangjiakou), China (Ulanqab) | 0.063 |
| China (Hong Kong), South Korea (Seoul) | 0.134 |
| Japan (Tokyo) | 0.100 |
| Malaysia (Kuala Lumpur) | 0.102 |
| Singapore, Indonesia (Jakarta) | 0.155 |
| Germany (Frankfurt), UK (London) | 0.078 |
| US (Virginia), US (Silicon Valley) | 0.129 |
| UAE (Dubai) | 0.091 |
| Other regions | 0.083 |
Enable automatic performance scaling
Cloud disk instances
-
Go to the RDS Instances page. In the upper-left corner, select the region where your instance is located, then click the instance ID.
-
In the Configuration Information section, click Settings next to Automatic Performance Scaling.
-
In the dialog box, configure the following parameters and click OK.
| Parameter | Description |
|---|---|
| Automatic Performance Scaling | Turn on the switch to enable the feature. |
| Observation Window | The period during which the system checks CPU utilization. The Scale-down Observation Window equals this value plus 10 minutes. For example, if you set this to 30 minutes, the scale-down observation period is 40 minutes. |
| CPU Trigger Threshold | The average CPU utilization that triggers an automatic scale-up. When CPU utilization reaches or exceeds this value, a scale-up is triggered. |
| Maximum Specifications | The upper limit for automatic scale-up. Must be greater than the current instance specifications. The current specifications are shown in the setting. |
| Cool-down Period | The minimum interval between two consecutive scale-up or scale-down operations. DAS continues monitoring during the cool-down period but does not trigger scaling. If the cool-down period and the observation window end at the same time and CPU utilization reaches the threshold, DAS triggers scaling when both periods end. |
| Whether to retract automatically | When enabled, the system scales down the instance in steps to the specifications before the scale-up, once the instance exits the Cool-down Period and CPU utilization stays below 30% for more than 99% of the time during the Scale-down Observation Window. |
The automatic scale-down feature is guaranteed to run stably only on the new architecture (kindcode=18) version. Run DescribeDBInstanceAttribute to check the instance architecture version.
Premium local disk instances
-
Go to the RDS Instances page. In the upper-left corner, select the region where your instance is located, then click the instance ID.
-
In the dialog box, configure the following parameters and click OK.
| Parameter | Description |
|---|---|
| Automatic Performance Scaling | Turn on the switch to enable the feature. |
| Scale-up Observation Window | The period during which the system checks CPU utilization to determine whether to trigger a scale-up. |
| CPU Trigger Threshold | The average CPU utilization that triggers an automatic scale-up. When CPU utilization reaches or exceeds this value, a scale-up is triggered. |
| Scale-down Observation Window | The period during which the system checks CPU utilization to determine whether to trigger a scale-down. If CPU utilization stays below 30% for more than 99% of this period, a scale-down is triggered. |
FAQ
What if the instance has reached the upper limit of its series?
Purchase an instance from a series with higher specifications. Then migrate the data to the new instance using DTS.
Is the instance monitored continuously during a scale-up?
Yes. For example, if the Observation Window is 5 minutes and the scale-up takes 10 minutes, the total elapsed time is 15 minutes. During the scale-up, the system monitors the instance but does not trigger another scale-up until the current one completes. After the scale-up finishes, if CPU utilization within the Observation Window still meets the threshold, another scale-up is triggered. This repeats until the instance reaches the Maximum Specifications.
What's next
-
If automatic scaling does not meet your needs, scale the instance manually: Change instance specifications.
-
If your traffic peaks occur at predictable times, use scheduled auto scaling to scale out at preset times and restore the original instance type automatically when the peak ends.