Once your ApsaraDB RDS for SQL Server instance is running and connected, use the features below to address storage costs, backup strategy, data security, read scalability, configuration management, serverless scaling, and host-level access.
Feature overview
| Category | Feature | When to use it |
|---|---|---|
| Cost optimization | Hot and cold data separation | Large datasets with infrequent access patterns |
| Backup and recovery | Snapshot backup | Faster restores with minimal instance impact |
| Security | Transparent Data Encryption (TDE) | Protecting sensitive data at rest |
| Scalability | Read-only instances and read/write splitting | Offloading read traffic from the primary instance |
| Operations | Instance parameter management | Tuning instance parameters without downtime |
| Serverless | RCU auto scaling | Controlling scaling behavior for time-sensitive workloads |
| Host access | Webshell-based host logon | Accessing the host OS to use SQL Server Reporting Services |
Hot and cold data separation
Archive infrequently accessed data to Object Storage Service (OSS) buckets while keeping hot data on cloud disks. This reduces storage costs and improves the cost-effectiveness and efficiency of data management.
Suitable for large data volumes, cost-sensitive workloads, and tiered storage requirements.
Related feature: See Use the data archiving feature.
Best practices: Hot and cold data separation best practices
Snapshot backup
Snapshot backups restore faster and support larger datasets than physical backups. They run without consuming CPU or memory on your RDS instance and generate less I/O overhead than physical backups, so instance performance remains stable during the backup window.
Transparent Data Encryption (TDE)
TDE encrypts data at the storage layer, preventing attackers who bypass the database from reading sensitive files directly. After enabling TDE, you can also use the backup files generated by the instance to restore data to an on-premises device.
See: Configure TDE
Best practices: TDE best practices
Read-only instances and read/write splitting
Applies to: RDS Cluster Edition only.
When a primary instance is overwhelmed by read traffic, create one or more read-only instances to distribute the load:
Increases overall read throughput without scaling the primary instance.
If the primary instance meets fast-initialization requirements, read-only instances can be ready within minutes with no I/O impact on the primary.
How routing works: Enable the read-only routing endpoint, then add both the primary endpoint and the read-only routing endpoint to your application. Write requests go to the primary; read requests go to the routing endpoint, which distributes them across read-only instances based on their configured read weights.
See also:
Instance parameter management
Modify instance parameters directly in the ApsaraDB RDS console or via API calls. The console also displays parameter modification history, making it easier to track configuration changes and troubleshoot issues.
RCU auto scaling
Applies to: Serverless instances only.
RDS Capacity Unit (RCU) scaling normally completes in seconds. Inter-host scale-ups can take 3 to 5 minutes. For workloads with strict stability requirements during a specific window, configure scheduled tasks to pre-adjust the RCU count before load spikes occur.
See also:
Webshell-based host logon
Create a host account for your instance and use it to log in to the underlying host. Once logged in, use SQL Server Reporting Services (SSRS) to manage SQL Server databases directly on the host.
See also: