Database Autonomy Service (DAS) lets you schedule automatic scale-up and scale-back operations for database instances. Define a time window and DAS scales the instance up at the start, then scales it back to the original specifications when the window closes — no manual intervention needed.
For example, if your business peaks on the first day of every month at 02:00 (UTC+8) and tapers off by the third day at 02:00 (UTC+8), configure a monthly recurrence so instances scale up before the rush and scale back automatically afterward. This pattern suits flash sales, payroll processing, end-of-month reporting, and any other predictable load spike.
Prerequisites
Before you begin, ensure that you have:
A supported database instance:
ApsaraDB RDS for MySQL: Standard Edition instances in the x86 architecture, or General-purpose High-availability Edition instances using standard SSDs or Enterprise SSDs (ESSDs)
NoteScheduled auto scaling is not available for read-only ApsaraDB RDS for MySQL instances.
PolarDB for MySQL: General-purpose or Dedicated Cluster Edition clusters
Tair (Redis OSS-compatible): cloud-native (cloud disk-based) Redis Open-Source Edition instances in the standard architecture, or cloud-native (cloud disk-based) Tair (Enterprise Edition) instances in the standard architecture
A service-linked role created for DAS. For more information, see AliyunServiceRoleForDAS role.
Sufficient account balance to cover the cost of scaled-up resources.
Billing
Scheduled auto scaling triggers configuration changes on the underlying instance, which are billed accordingly:
ApsaraDB RDS for MySQL: Configuration changes
PolarDB for MySQL: Configuration change fees
Tair (Redis OSS-compatible): Configuration changes
Usage notes
To scale up a database instance on a regular basis, you must configure a scheduled auto scaling policy for the database instance.
All time parameters use UTC+8. Convert your local time to UTC+8 before configuring. For example, US Eastern Time (UTC-5) 09:00 corresponds to UTC+8 22:00.
Each database instance supports one auto scaling policy per mode.
If a policy fails to run, DAS does not retry it.
Modifying Duration or Scale-back Time after an instance has already scaled up changes the scale-back time to the new value.
When scale-back does not occur
The instance is not scaled back even if a Duration or Scale-back Time is set in these situations:
The instance specifications were changed again after the scheduled policy ran, and the current specifications differ from the policy's original target.
Scaling back would breach a resource threshold. For example, if memory was scaled from 1 GB to 4 GB and 1 GB is already in use, scaling back to 1 GB would push memory utilization to 100%, so DAS skips the operation to protect stability.
The instance is in a state that does not allow specification changes, such as Changing Specifications or Migrating.
Create a scheduled auto scaling policy
The DAS console provides two entry points. Use the Auto Scaling Settings page (recommended) to manage policies centrally across multiple instances, or configure from an individual instance's detail page.
From the Auto Scaling Settings page (recommended)
Log on to the DAS console.
In the left navigation pane, choose Resources > Auto Scaling Settings.
On the Auto Scaling Policies page, click Add Policy.
In the Add Policy panel, configure the parameters described in the Parameters section.
In the policy list, find the policy you created and click Apply in the Actions column.
In the Apply Policies dialog box, select the target database instances, click the
icon, then click Confirm.
From an instance's detail page
Log on to the DAS console.
In the left navigation pane, choose Intelligent O&M Center > Instance Monitoring.
Find the target instance and click its instance ID.
On the instance detail page, click Autonomy Service Settings in the upper-right corner.
On the Autonomous Function Settings tab of the Autonomous Function Management panel, click the Auto Scaling tab.
In the Applied Policies section, click Add Policy and configure the parameters described in the Parameters section.
In the Recommended Policies section, find the policy you created and click Apply in the Actions column.
Click OK.
In the Alert Configuration section, configure an alert template and subscribe to alert notifications. DAS recommends an alert template and adds the required alert rules automatically. If you already have a template for this instance, add the alert rules to the existing template as prompted. For details, see Configure alert templates and Configure alert rules.
In the Select Contact Group section, select an alert contact group. For details, see Manage alert contacts.
Click Add Contact to add a contact.
Click Create Contact Group to create a new group.
Click Edit or Remove in the Actions column to update or remove a contact.
Click Submit Configuration and confirm in the dialog box.
To modify or remove an applied policy:
Modify: Click Modify in the Actions column, then update settings in the Update Policy panel.
Remove: In the Applied Policy section, click Cancel in the Actions column.
Parameters
| Parameter | Description |
|---|---|
| Policy name | The name of the policy. |
| Mode | Select Scheduled Auto Scaling. |
| Engine type | The database engine type. |
| Specifications | The target specifications for the selected engine. |
| Operation | The operation to perform. For ApsaraDB RDS for MySQL and Tair (Redis OSS-compatible) instances, only Adjust Instance Specifications is available. For PolarDB for MySQL clusters, both Adjust Instance Specifications and Increase Number of Read-only Nodes are available. |
| Valid from | The effective date range of the policy. Start time is required and must be today or a future date. End time is optional — see Recurrence for how it interacts with each recurrence mode. |
| Recurrence | How often the scaling operation runs. Valid values: N/A(Execute Only Once), Daily, Weekly, Monthly. See the table below for parameter details per recurrence mode. |
Recurrence-specific parameters:
| Recurrence | Parameter | Required | Details |
|---|---|---|---|
| N/A(Execute Only Once) | Scaling start time | Yes | The exact date and time to scale up. |
| Duration | No | How long to keep the scaled-up specifications, in hours (positive integer). Leave blank to skip automatic scale-back. | |
| Daily | Scaling start time | Yes | The time of day to scale up, applied daily. |
| Scale-back time | Yes | The time of day to scale back. Must be at least 1 hour after the scaling start time. If scale-back time is earlier in the day than the scaling start time, scale-back occurs the next day. | |
| Weekly | Scaling start time | Yes | The day of the week and time to scale up. |
| Scale-back time | Yes | The day of the week and time to scale back. Must be at least 1 hour after the scaling start time. If scale-back falls on an earlier day of the week than the scaling start, scale-back occurs in the following week. | |
| Monthly | Scaling start time | Yes | The day of the month and time to scale up. |
| Scale-back time | Yes | The day of the month and time to scale back. Must be at least 1 hour after the scaling start time. If scale-back falls on an earlier day of the month than the scaling start, scale-back occurs in the following month. |
Constraints for Daily, Weekly, and Monthly recurrence:
The scaling start time of each execution must be at least 1 hour after the scale-back time of the previous execution.
If the End time falls between the scaling start time and scale-back time of what would be the last execution, that execution is skipped entirely.
View scaling results
In the left navigation pane, choose Intelligent O&M Center > Instance Monitoring.
Find the instance and click its instance ID.
In the left pane of the instance detail page, click Autonomy Center.
On the Autonomy Center page, select a time range to filter auto scaling events.
In the Auto-Scaling Events section, click Details to view the full event log.
FAQ
What if my instance has reached its maximum specifications?
Purchase a higher-specification instance and migrate your data. For ApsaraDB RDS for MySQL, the Dedicated High-availability Edition supports up to 104 vCPUs and 768 GB of memory. See the following resources for specifications and migration guides:
ApsaraDB RDS for MySQL: Specifications and Migrate data between ApsaraDB RDS for MySQL instances
PolarDB for MySQL: Compute node specifications and Migrate data between PolarDB for MySQL clusters
Tair (Redis OSS-compatible): Instance specifications and Migrate data between Tair (Redis OSS-compatible) instances
What's next
To manually change instance specifications outside of a scheduled policy, see:
ApsaraDB RDS for MySQL: Change instance specifications
PolarDB for MySQL: Manually change the specifications of a cluster
Tair (Redis OSS-compatible): Change the configurations of an instance