Committed serverless
Committed serverless adds serverless elastic scaling to an existing fixed-specification ApsaraDB RDS for MySQL instance that uses cloud disks. The instance keeps its original specifications as baseline resources and automatically scales CPU and memory within the configured RCU upper limit (ScaleMaxRcu) to handle short-term traffic spikes.
The committed serverless feature for ApsaraDB RDS for MySQL is available only by submitting a ticket.
Feature overview
Committed serverless adds or releases elastic resources on top of the fixed specifications, and scale-up and scale-down are preferentially completed within the same resource pool. It is designed for workloads that are stable most of the time but experience short-term traffic spikes. You do not need to purchase peak specifications long-term. The system automatically uses elastic resources when the load increases and releases them after the load drops, which improves instance stability and optimizes resource costs.
-
The fixed specifications provide baseline compute capacity. During off-peak hours, the instance still runs on the fixed specifications.
-
Elastic resources are configured and scaled in RCU units. One RCU is approximately equivalent to one CPU core and 2 GB of memory.
-
After the feature is enabled, the instance can add elastic resources on top of the fixed specifications. The configurable range of ScaleMaxRcu (the upper limit for elastic scale-up) is subject to the console.
-
Elastic scaling is fully automatic. You do not need to manually change the instance specifications.
The following table compares committed serverless with fixed-specification instances and serverless instances.
| Item | Fixed-specification instances | Serverless instances | Committed serverless |
|---|---|---|---|
| Resource model | Fixed CPU and memory. | The entire instance runs in serverless mode. | Fixed specifications plus elastic RCUs. |
| Scenarios | Long-term stable workloads. | Significantly fluctuating workloads that require overall elasticity. | Stable daily workloads with short-term traffic spikes. |
| Scaling method | Manual specification changes are required. | The system automatically scales resources. | The system automatically adds or releases elastic resources on top of the fixed specifications. |
| Cross-host elastic scaling | Not involved. | In rare cases, RCU scaling may take longer because of cross-host elastic scale-out or cross-host migration. | Daily scale-up and scale-down do not involve cross-host elastic scale-out. |
| Resource lower limit | Fixed specifications. | Serverless lower limit. | Fixed specifications. |
| Resource upper limit | Fixed specifications. | Serverless upper limit. | Fixed specifications plus ScaleMaxRcu. |
| Billing composition | Fees for the fixed specifications. | Serverless fees. | Fees for the fixed specifications plus fees for elastic RCUs. |
How it works
RCU
Committed serverless uses the RDS Capacity Unit (RCU) as the measurement unit for elastic compute resources. One RCU is approximately equivalent to one CPU core and 2 GB of memory. Elastic resources are configured and scaled in RCU units.
Elastic scaling mechanism
After committed serverless is enabled, the system continuously monitors the instance load and automatically triggers scale-up or scale-down based on metrics such as CPU usage and elastic memory usage.
-
Scale-up: When the CPU usage or elastic memory usage stays above the thresholds of the system policy, the system scales up and adds elastic resources within the configured ScaleMaxRcu range. Scale-up does not exceed the ScaleMaxRcu value that you configure in the console.
-
Scale-down: When both the CPU usage and elastic memory usage stay below the thresholds of the system policy and internal stability checks pass, the system scales down and releases the elastic resources in use. After the workload drops, elastic resources are released automatically.
-
The minimum scaling step is 0.5 RCUs. The system dynamically calculates the actual step based on the current load and the target watermark.
-
The daily elastic scaling of committed serverless adds or releases elastic resources on top of the fixed specifications and does not involve the cross-host elastic scale-out that may occur on serverless instances.
Committed serverless for ApsaraDB RDS for MySQL does not allow you to customize the scale-up and scale-down thresholds for CPU and memory. The system uses the default elastic policy.
Prerequisites
The instance must meet all of the following requirements:
| Item | Requirement |
|---|---|
| Database engine | ApsaraDB RDS for MySQL. MySQL 5.7, 8.0, and 8.4 are supported. |
| Instance architecture | Instances that use cloud disks. |
| Instance series | Primary instances of the Basic Edition or High-availability Edition. |
| Instance family | General-purpose or dedicated instance family. |
| Billing method | Subscription or pay-as-you-go. |
| Storage type | ESSD PL1 disks, or general ESSDs that meet the requirements. |
| Read-only instances | No read-only instances exist before you enable the feature. |
Billing
The fees for committed serverless consist of the following two parts:
-
Fees for the fixed specifications: The instance continues to be billed based on its original billing method.
-
Fees for elastic RCUs: The elastic RCUs are billed based on the billing rules for serverless elastic resources.
Discounts or special billing rules, if any, are subject to the information displayed in the console, your commercial contract, or the promotion terms.
Limits
The current version has the following limits:
-
Only instances that use cloud disks are supported.
-
Only specifications with a memory-to-CPU ratio of 1:2 or 1:4 are supported. The available specifications are subject to the console.
-
Primary instances that have read-only instances cannot enable committed serverless.
-
Read-only instances cannot enable committed serverless.
-
Instances that use DuckDB or the XFS file system cannot enable committed serverless.
-
Instances that use general ESSDs with the I/O acceleration or cold data feature enabled cannot enable committed serverless.
-
Instances that use some earlier database proxy configurations cannot enable committed serverless. The result is subject to the console check.
-
Instances with committed serverless enabled cannot be directly converted into serverless instances.
-
Instances with committed serverless enabled do not support the instance stop operation.
Enable committed serverless
You can enable committed serverless in the console. Before you start, make sure that the instance meets the Prerequisites and Limits.
-
Go to the Instances page. In the top navigation bar, select the region where the instance resides.
-
Find the ApsaraDB RDS for MySQL instance that you want to manage and click the instance ID to go to the instance details page.
-
On the Basic Information page, find the section and click Settings.
-
In the Committed Serverless Settings dialog box, click Enable Committed Serverless and set the Elastic Resource Upper Limit and Effective Policy.
ScaleMaxRcu limits the maximum number of additional elastic RCUs that the instance can use on top of the fixed specifications. The supported ScaleMaxRcu values may vary based on the instance family. The actual available range may be affected by the regional inventory, instance specifications, and sales policies. The values displayed in the console prevail.
Instance family Default limits General-purpose By default, ScaleMaxRcu cannot exceed the number of CPU cores of the fixed specifications. By default, the total CPU of the fixed specifications plus the elastic upper limit cannot exceed 16 cores, and the total memory cannot exceed 80 GB. Dedicated By default, the CPU of the fixed specifications cannot exceed 32 cores. The memory-to-CPU ratio of the fixed specifications must be 1:2 or 1:4. By default, ScaleMaxRcu cannot exceed 50% of the number of CPU cores of the fixed specifications. By default, the total CPU of the fixed specifications plus the elastic upper limit cannot exceed 48 cores, and the total memory cannot exceed 160 GB. -
Click OK.
During the enabling process, the system may perform a specification change and a high-availability (HA) switchover, which causes a transient connection interruption of about 10 seconds. Perform this operation during off-peak hours or a maintenance window, and make sure that your application supports automatic reconnection.
Disable committed serverless
After you disable committed serverless, the instance returns to a standard fixed-specification instance and no longer uses elastic RCUs.
On the Basic Information page, find the section and click Disable Committed Serverless.
Before you disable committed serverless, the current elastic resource usage must drop to 0 RCUs. If the instance is still using elastic resources, the system may reject the request and report that the instance is using elastic resources.
The disabling process may trigger a specification change and an HA switchover. Perform this operation during off-peak hours or a maintenance window, and make sure that your application supports automatic reconnection.
Adjust ScaleMaxRcu
For an instance with committed serverless enabled, go to the Basic Information page, find the section, click Settings, and adjust the Elastic Resource Upper Limit in the Committed Serverless Settings dialog box. The adjustment must still meet the instance family limits. For more information, see the ScaleMaxRcu parameter description in the Enable committed serverless section.
Adjusting the upper limit for elastic scale-up may trigger a specification change. Perform this operation during off-peak hours, and confirm in advance that the target upper limit meets your peak business demand.
Monitor resource usage
After committed serverless is enabled, you can view metrics such as CPU, memory, and RCU on the page of the console.
-
The RCU metric indicates the usage of the elastic resource portion only. It is not equivalent to the full CPU or memory of the fixed specifications.
-
When elastic resources change, the monitoring curves in the console may show RCU increases or decreases.
-
Before you disable committed serverless, confirm that the current RCU usage has dropped to 0.
FAQ
-
Q1: Do the fixed specifications change after I enable committed serverless?
No. Committed serverless adds elastic resources on top of the fixed specifications. The fixed specifications remain as baseline resources.
-
Q2: Why does disabling committed serverless fail?
The most common cause is that the instance is still using elastic resources. Wait until the workload drops, confirm that the current RCU usage has dropped to 0, and then try again.
-
Q3: Can I scale only CPU or only memory?
No. Committed serverless for ApsaraDB RDS for MySQL configures elastic resources in RCU units. One RCU is approximately equivalent to one CPU core and 2 GB of memory. You cannot set a separate elastic upper limit for CPU or memory.
-
Q4: Can I customize the scale-up and scale-down thresholds?
No. Committed serverless for ApsaraDB RDS for MySQL uses the default elastic policy of the system.
-
Q5: Can an instance with committed serverless enabled be directly converted into a serverless instance?
No. An instance with committed serverless enabled cannot be directly converted into a serverless instance. To use a serverless instance, disable committed serverless to return the instance to a standard fixed-specification instance, and then perform the conversion by using the paths supported in the console.
-
Q6: Can I stop an instance after I enable committed serverless?
No. Instances with committed serverless enabled do not support the instance stop operation. To stop the instance, first evaluate whether to disable committed serverless.