10 — RDS: Managed Relational Databases, Without the DBA Chores

RDS was "managed MySQL" to me, and that label hid the actual deal. The value proposition that settled it: RDS takes a relational database I would otherwise run myself — MySQL, Postgres, MariaDB, Oracle, SQL Server, or the AWS-built Aurora — and removes the operational chores: OS patching, engine patching, automated backups, multi-AZ replication, storage scaling, point-in-time recovery [1]. What's left for me to own is the schema, the data model, the queries, and the instance size. That split — AWS runs the engine, I run the database — is the whole service.

What "managed" actually buys

The chores RDS removes are the ones that eat a DBA's week:

• Patching. The OS and the database engine are patched on a schedule I control (a maintenance window). I no longer SSH in to run apt upgrade.
• Backups. Automated daily snapshots plus continuous transaction logs give point-in-time recovery — typically down to within five minutes [5].
• High availability. A Multi-AZ deployment keeps a synchronous standby in a second AZ; if the primary fails, RDS fails over to the standby automatically.
• Scaling. Storage can grow on demand without downtime; compute is a resize operation (brief interruption, scheduled in a window).

The thing RDS does not remove: schema design, query tuning, indexing. A slow query is still my slow query, no matter who runs the engine.

DB instances and engines

The unit of RDS is a DB instance — an isolated database environment in the cloud [3]. One instance can host multiple databases; I pick the engine (MySQL, Postgres, etc.), the instance size, and the storage at creation.

Aurora deserves a callout: it's AWS's purpose-built cloud-native engine, MySQL- and Postgres-compatible at the wire level, but with a separated storage layer that replicates six ways across three AZs by default [1]. Faster failover, more durable, and often cheaper at scale than the equivalent stock-engine Multi-AZ setup. When the workload fits, Aurora is usually the better answer than plain MySQL/Postgres on RDS.

Storage: three flavors tuned to the workload

RDS storage is EBS under the hood, and the choice is the same price/performance dial EC2 faces [2][4][6]:

• General Purpose SSD (gp2/gp3) — the default, balanced. Good for most workloads; gp3 lets me provision IOPS (I/O operations per second — how fast the disk reads and writes) independently of size.
• Provisioned IOPS (io1/io2) — for I/O-intensive workloads where predictable, high IOPS matter. I pay for the IOPS I reserve, whether I use them or not. The right pick for a busy OLTP database (one handling a stream of live transactions) whose latency budget is tight.
• Magnetic — the legacy, spinning-disk tier. Cheapest per GB, worst performance. Almost never the right answer today; it exists for old workloads pinned to it.

The mental rule I use: start on General Purpose, watch the queue depth and IOPS consumption in CloudWatch, and move to Provisioned IOPS only when General Purpose is the binding constraint. Provisioned IOPS is a scalpel, not a default.

Backup and restore

The backup story has two layers worth separating [5]:

• Automated backups — daily snapshot plus continuous transaction logs. Enable point-in-time recovery to any second within the retention window (1–35 days). This is the "I dropped a table at 2:03pm, put it back" tool.
• Manual snapshots — I take them, they persist until I delete them, and they're how I keep long-term retention beyond the 35-day automated window.

Restoring always creates a new DB instance — I do not overwrite the original. Point-in-time restore spins up a fresh instance at the requested moment; the source keeps running untouched, which matters when the "incident" is a bad migration I want to compare against.

How I use this

RDS is my default the moment a workload needs a real relational schema and I'd rather not run my own Postgres. The standing setup: Multi-AZ on for anything production (the synchronous standby is the single biggest availability lever), automated backups with a 7–35 day retention depending on the data, storage on gp3 with IOPS provisioned to match, and Aurora where the workload is large enough that its storage architecture pays off. The part I never outsource is the schema and the queries — RDS will happily run a missing-index query at full speed into a timeout, and no managed feature rescues a bad data model. The service removes the chores; it does not remove the engineering.

References

[1] Amazon Web Services, "What is Amazon RDS?," 2024. [Online]. Available: https://aws.amazon.com/rds/

[2] Amazon Web Services, "Amazon EBS volume types," EBS User Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html

[3] Amazon Web Services, "DB instances," RDS User Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.html

[4] Amazon Web Services, "Provisioned IOPS SSD volumes," EBS User Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/ebs/latest/userguide/provisioned-iops.html

[5] Amazon Web Services, "Backing up and restoring an Amazon RDS DB instance," RDS User Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_CommonTasks.BackupRestore.html

[6] Amazon Web Services, "Amazon RDS storage types," 2024. [Online]. Available: https://aws.amazon.com/rds/instance-types/