Amazon Relational Database Service (RDS) runs relational databases for you: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server and Db2, plus Amazon Aurora as a related engine family. AWS handles the server, OS patching, backups and failover. You still own the schema, queries, indexes and instance size. This note covers the RDS features people mix up most: backups vs snapshots, and Multi-AZ vs read replicas. For what a transaction guarantees, see ACID.
What RDS manages for you#
RDS runs the database engine on a managed instance with EBS storage. You connect to it through an endpoint, a DNS name such as orders-db.abc123xyz.us-east-1.rds.amazonaws.com. You do not get SSH access to the host, so the split of duties looks like this.
| AWS handles | You handle |
|---|---|
| Hardware, OS and engine installs | Schema, indexes and queries |
| Engine patches (in a maintenance window you choose) | Choosing instance class and storage |
| Automated backups and restore tooling | Retention period and testing restores |
| Failover in Multi-AZ setups | Making the app reconnect and retry |
| Storage scaling (if you turn on autoscaling) | Security groups and who can connect |
Put the database in private subnets and allow its port only from the app tier's security group. See Security Groups, ENIs and Elastic IPs.
Automated backups#
Backups are the first duty in that table that you share with AWS, and RDS gives you two kinds. Automated backups are on by default. They let you restore the database to any second within a retention period that you set.
- RDS takes a daily snapshot of the storage during a backup window you choose.
- It also saves the database's transaction logs throughout the day.
- To restore to a point in time, RDS loads the nearest snapshot and replays the logs up to that moment. This is point-in-time recovery (PITR).
- Backup storage up to the size of your provisioned database storage in a Region costs nothing extra. Beyond that you pay per GB.
- On a Single-AZ instance, I/O can pause briefly when the snapshot starts, so pick a quiet window. On a Multi-AZ instance, RDS usually takes the backup from the standby.
- When you delete the instance, automated backups are deleted by default. You can choose to retain them, and you can take a final snapshot.
Manual snapshots#
The second kind fills the gaps automated backups leave, such as keeping a copy after the instance is gone. A DB snapshot is a backup you take yourself, whenever you want.
- It is not deleted automatically. It stays until you delete it, even after the source instance is gone.
- Take one before a risky change, such as a major version upgrade or a large migration.
- You can copy snapshots to another Region and share them with other accounts.
- A snapshot restores to the moment it was taken. It has no point-in-time replay.
| Automated backups | Manual snapshots | |
|---|---|---|
| Created by | RDS, daily, plus logs | You |
| Restore to | Any second in the retention period | The moment of the snapshot |
| Kept until | Retention period ends | You delete it |
| After instance deletion | Deleted unless you retain them | Kept |
Restoring creates a new instance#
Both kinds of backup share one surprise when you use them. Every restore, from automated backups or a snapshot, creates a new DB instance with a new endpoint. RDS does not overwrite the existing database.
- Start the restore and choose the time or snapshot.
- Wait for the new instance to become available.
- Check the data.
- Point the application at the new endpoint, or rename instances so the new one takes the old endpoint name.
Plan for step 4 before you need it. Keep the endpoint in configuration, or behind a DNS name you control, so a restore does not need a code change.
Encryption#
Backups and snapshots hold the same data as the database, so they need the same protection. RDS encryption at rest uses keys from AWS KMS. On an encrypted instance, the storage, automated backups, snapshots and read replicas are all encrypted.
- Turn encryption on when you create the instance. You cannot encrypt an existing unencrypted instance in place. Instead, take a snapshot, copy it with encryption on, and restore from the copy.
- For data in transit, connect with TLS (SSL). You can make the server reject unencrypted connections, for example with the
rds.force_sslparameter on PostgreSQL.
Multi-AZ: high availability#
Backups help you recover from lost or bad data. They don't keep the database running when a server or zone fails. For that, a Multi-AZ deployment keeps a standby copy of the database in a different Availability Zone. Its purpose is availability, not speed.
- RDS replicates every write synchronously to the standby. A write is confirmed only after both copies have it, so a failover loses no committed data.
- If the primary fails (host failure, storage failure, AZ outage), RDS fails over automatically. It promotes the standby and points the same endpoint at it by updating DNS.
- Failover usually takes a minute or two. Open connections drop, so the application must reconnect and retry.
- In the classic Multi-AZ instance deployment, the standby serves no traffic. You cannot read from it.
- Multi-AZ also helps maintenance. RDS can patch the standby first, then fail over, which shortens downtime.
RDS also offers a Multi-AZ DB cluster deployment for MySQL and PostgreSQL. It has two standbys that can serve reads. Check the documentation for how it differs.
Read replicas: read scaling#
A classic Multi-AZ standby sits idle. A read replica is a copy you can read from. It is read-only, and its purpose is to take read traffic off the primary.
- Replication is asynchronous. The primary does not wait for the replica, so a replica can lag behind by seconds or more.
- Each replica has its own endpoint. The application sends reads to replicas and writes to the primary. RDS does not split traffic for you.
- You can create several replicas, in the same Region or other Regions. Cross-Region replicas put reads closer to distant users and help with disaster recovery.
- You can promote a replica to a standalone, writable database. Promotion is manual and breaks replication.
- A replica can itself be Multi-AZ.
Because replicas lag, a user who writes and then reads from a replica may not see their own change. Scaling Reads covers this read-after-write problem and its fixes.
Multi-AZ vs read replicas#
Both features add a second copy of the database, so they sound similar. Each solves a different problem.
| Multi-AZ (instance) | Read replicas | |
|---|---|---|
| Purpose | High availability | Read scaling |
| Replication | Synchronous | Asynchronous |
| Serves reads | No (standby is idle) | Yes |
| Failover | Automatic, same endpoint | Manual promotion, new endpoint |
| Location | Another AZ, same Region | Same or another Region |
| Data loss on failure | None for committed writes | Writes not yet replicated can be lost |
Production databases often use both: Multi-AZ to survive failures, and read replicas to handle read load.
Key takeaways#
- RDS runs the engine, backups, patching and failover. You still own the schema, queries, sizing and security groups.
- Automated backups give point-in-time recovery within the retention period. Manual snapshots stay until you delete them.
- Every restore creates a new instance with a new endpoint. Plan how the app will switch to it.
- Turn on encryption at creation. It covers storage, backups, snapshots and replicas.
- Multi-AZ is for availability: synchronous standby, automatic failover, same endpoint, no reads.
- Read replicas are for read scaling: asynchronous, readable, can lag, promoted by hand.