Amazon RDS
AWS's managed relational database — Postgres, MySQL, and friends with backups, patching, and failover handled, so you run schemas instead of servers.
What is Amazon RDS?
Amazon RDS (Relational Database Service) runs managed relational databases — PostgreSQL, MySQL, MariaDB, SQL Server, Oracle — handling the operational toil: provisioning, patching, automated backups, read replicas, and Multi-AZ failover. You get a database endpoint and a schema to design; AWS runs the servers, the WAL archiving, and the failover machinery. It’s the default answer to “I need a SQL database in AWS without a DBA on staff.”
Multi-AZ and the durability story
RDS’s headline reliability feature is Multi-AZ: a synchronous standby in a second availability zone that takes over automatically (typically in 60–120 seconds) if the primary fails or during maintenance — the difference between a blip and an outage. It’s distinct from read replicas: Multi-AZ is for availability (the standby doesn’t serve reads in the classic setup), replicas are for read scaling; production databases usually want both. Automated backups plus transaction-log archiving give point-in-time recovery to any second in the retention window — the thing you’ll be grateful for after a bad migration.
RDS vs Aurora vs self-managed
The decision ladder. Self-managed on EC2: maximum control, maximum toil — justified only by needs RDS can’t meet (specific extensions, OS access, exotic tuning). RDS: managed standard engines — the sensible default. Aurora: AWS’s cloud-native reimplementation of MySQL/Postgres with a distributed storage layer (six-way replication across three AZs, faster failover, storage that auto-grows, up to 15 low-lag replicas) — more performance and resilience at higher cost, worth it at scale. The honest guidance: start with RDS for standard workloads, move to Aurora when its scaling/resilience earns its premium, self-manage only when forced. And the perennial cost trap: RDS instances are always on — a forgotten dev database bills 24/7, and I/O plus storage can dwarf compute for scan-heavy workloads.
What people get wrong
- No Multi-AZ in production — saving a few dollars until the single-AZ database fails and takes the app with it.
- Replicas confused with standbys: expecting a read replica to be a HA failover, or a Multi-AZ standby to serve reads.
- Ignoring idle instances — RDS bills continuously; stopped-when-unused dev/test databases are easy FinOps wins.
Primary source: Amazon RDS documentation
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.