ApsaraDB for RDS

RDS is a managed database: backups, failover, version upgrades and patching are Alibaba Cloud’s responsibility, leaving you with SQL and indexes. For cross-border workloads the real value is not convenience but the multi-availability-zone deployment and cross-region replication it provides — reaching the same result with a self-managed MySQL costs far more in operations. This page breaks down the decisions that actually drive cost and reliability: instance type, spec and storage sizing, backup policy, how high availability and read-only instances combine, and region plus connectivity choices for overseas scenarios.

Specs & pricing

What RDS is, and what it takes off your plate

RDS (ApsaraDB for RDS) covers MySQL, PostgreSQL, SQL Server and other engines on the international site, with specs selected per engine and version. It handles automatic full backups and log backups, on-demand point-in-time recovery targets, failover within or across availability zones, and controlled parameter and kernel upgrades. What it does not handle is index tuning, SQL optimisation, capacity planning and permission design — those remain developer work. Managed does not mean maintenance-free.

What an RDS bill is made of

• Spec plus storage: the instance is billed hourly, storage is billed on occupied capacity, and both scale online without data migration
• Instance type: single-node, high-availability primary/standby and cluster edition move the bill more than any other choice — pick the tier here first
• Read-only instances and the proxy: added on demand, with read-only instances priced below the primary, which suits read-heavy applications
• Backups: full backups have a retention period and policy, log backups serve point-in-time recovery, and both count against storage quota
• Public connectivity: a public endpoint and the private network endpoint from ECS are billed differently, so decide early whether to expose it publicly
• All of the above describes the billing structure, not prices. Final cost is set by spec, region, instance type and discount, and follows the official live quote

Region choice: keep the database with the ECS in one AZ

The database and the application it serves belong in the same region and the same availability zone: crossing zones adds latency, and crossing regions affects both writes and failover. Cross-region capability should come from a read-only replica or disaster-recovery instance, not from putting the primary far away. When picking a region, data residency and compliance still come first, then where your application servers are.

International vs China site: versions, regions and cross-border connectivity

On both sites an RDS instance must be created and billed separately, with no shared accounts or resources. Connectivity is what cross-border teams really need to plan: there is no private-network path between an international-site database and application servers in mainland China, so the usual approach is to deploy the application in the same overseas region and reach the database over the private network, with no public endpoint exposed at all. If database administration from China is genuinely required, a VPN or dedicated line works, but evaluate it as a link with a running cost.

Choosing between the four instance types

One recommendation that directly affects availability

How to get RDS provisioned and connected through us

1. Send the requirement: engine and version, expected data volume and growth, read/write mix, peak QPS, and any compliance residency rules
2. We help complete account provisioning and payment verification on the international site — no personal credit card binding, no personal identity documents
3. Once live, create the instance yourself in the console: engine, version, instance type, spec and storage, with the region matching your ECS
4. Create the database account and restrict the whitelist to your application servers’ private IPs, without opening a public endpoint; administer through a whitelisted jump host
5. Set the full-backup retention period and log backups, confirm point-in-time recovery works, then connect the application. Once you confirm the resource list we settle payment on your behalf

Six checks before the database goes live

• Leaving parameters at defaults: connection limits, character set, time zone and SQL mode should all be set for the workload
• Full backups only: without log backups you cannot do point-in-time recovery, and an incident costs you up to a day of data
• Overly broad whitelist: allow the application servers’ private IPs, not any source
• Never exercising failover: you paid for high availability without knowing whether the application survives a switch
• Connecting over the public endpoint: it costs extra and adds exposure
• No billing alerts: storage and read-only instances grow with the business, and without alerts you will not notice in time