Convert a serverless instance to a pay-as-you-go instance - ApsaraDB RDS

You can change the billing method of an ApsaraDB RDS for SQL Server instance from serverless to pay-as-you-go. The change involves a data migration at the underlying layer, which causes a brief disconnection of less than 20 minutes.

Prerequisites

Before you begin, make sure that you have:

An RDS for SQL Server instance in the High-availability Edition
The instance billing method set to Serverless
The instance in the Running state

Limitations

Limitation	Details
Destination instance type	Only shared instance types (displayed as General-purpose Instance Types in the console) are supported. To use a different instance type, first complete this change, then change the instance type separately.
CPU core requirement	The number of CPU cores in the destination pay-as-you-go instance type must be equal to or greater than the RCU upper limit of the current serverless instance.
Frequency	One billing method change from serverless to pay-as-you-go every 24 hours.

Billing

The billing method change itself is free of charge. After the change, pay-as-you-go billing applies. For details, see Billing overview.

How the migration works

The billing method change is implemented through data migration at the underlying layer:

Create a new pay-as-you-go instance.
Perform a full backup of the source instance (conditional).
Restore the full backup to the new instance.
Back up and apply incremental transaction logs.
Switch network connections to the new instance.

This process causes a temporary disconnection of less than 20 minutes. Configure your application to automatically reconnect to the instance.

Estimated duration

The following table lists the estimated duration of each step. Backup and restore speeds are based on the size of uncompressed data.

Step	Required	Estimated duration	Notes
Create and configure the new instance	Yes	10-15 minutes	Duration varies by edition and instance type.
Full backup	Conditional	200 GB/hour	Runs only if no full backup has been performed in the last 36 hours. To reduce total time, back up your instance before starting the change, or initiate the change within 36 hours of the last system-initiated full backup. Backup speed may vary by region and time period. To obtain more accurate backup and restoration performance metrics, refer to the data volume and time of the last full backup.
Restore full backup to the new instance	Yes	200 GB/hour	-
Incremental transaction log backup	Yes	200 GB/hour	An additional 2 minutes may be needed before and after for backup preparation, finalization, and resource allocation.
Apply incremental transaction logs	Yes	200 GB/hour	An additional 2 minutes may be needed before and after for backup consistency verification.
Bring the database online	Yes	Typically within 2 minutes	For low-specification instances (for example, 2 CPU cores and 4 GB of memory), the recovery speed may be reduced due to a large number of transaction logs. Instances running SQL Server 2019 or later support Accelerated Database Recovery, which may reduce this time. For details, see the official Microsoft documentation.
Network switchover	Yes	10 minutes	-

Connection changes after the switch

The virtual IP address (VIP) of your instance changes during the billing method change. To avoid connection failures:

Use endpoints, not IP addresses. Connect your application using the internal or public endpoint of the RDS instance. Endpoints are dynamic domain names that automatically route to the current backend IP address.
Flush cached DNS records. After the change, immediately clear the DNS cache on your database client so that subsequent connections resolve to the new VIP.

DNS TTL configuration for JVM-based applications

Set the DNS time-to-live (TTL) to 60 seconds or less so that your application picks up the new VIP promptly.

Global JVM setting: Set the networkaddress.cache.ttl parameter to 60 in $JAVA_HOME/jre/lib/security/java.security.
Application-level setting: Add the following code to your application initialization, before the first call to InetAddress.getByName():
```
  java.security.Security.setProperty("networkaddress.cache.ttl", "60");
```

Change the billing method

Go to the Instances page. In the top navigation bar, select the region of the instance. Then, click the instance ID.
On the Basic Information page, in the Configuration Information section, click Change to Pay-As-You-Go.
On the RDS buy page, configure the Instance Type and Switching Time parameters.
Click Confirm Order. In the dialog box that appears, confirm the instance configurations before and after the change, and then click OK to complete the payment.
Note
During the change, the instance state changes to Changing Configuration. After the change is complete, the instance state returns to Running.

API reference

Call ModifyDBInstanceSpec to change the billing method from serverless to pay-as-you-go.

Parameter	Value	Description
`PayType`	`Postpaid`	Specifies pay-as-you-go billing.
`DBInstanceClass`	Target instance type	The destination instance type. For available types, see Instance types for primary ApsaraDB RDS for SQL Server instances.
Other parameters	Keep original values or leave blank	Storage capacity and other parameters cannot be modified during this change.

Note

Make sure that the current billing method of the instance is Serverless before calling this operation.

FAQ

After I change the billing method from serverless to pay-as-you-go, why does the order type show as "New Purchase" on the Orders page in the Expenses and Costs console?

The billing method change is implemented by creating a new pay-as-you-go instance and switching your workloads to it. Because a new instance is provisioned during this process, the order is recorded as a new purchase.