Amazon RDS
Managed relational database service — AWS runs the server, you run the schema.
Verified against AWS documentation · 2026-09-09
Key facts
- 01AWS handles provisioning, OS patching, backups, and failover — you get an endpoint, not a box. No SSH, no OS access
- 02Six engines: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2 — plus Aurora, AWS's own MySQL/PostgreSQL-compatible engine
- 03Multi-AZ = availability: synchronous standby in another AZ, automatic failover, serves zero read traffic
- 04Read replicas = scale: asynchronous, read-only, promoted manually — a different problem from Multi-AZ
- 05Limits: 35-day max automated backup retention, up to 15 read replicas per instance on most engines, encryption can only be turned on at creation, stopped instances auto-restart after 7 days
Exam triggers
Phrases and scenarios that point here.
- "Managed relational database", "minimize database admin overhead", "existing MySQL/PostgreSQL app" → RDS, not a database on EC2
- "Survive an AZ outage" → Multi-AZ. "Read-heavy" or "offload reporting" → read replicas. The exam swaps these two constantly
- "Restore to any point in the last N days" → automated backups. "Keep this copy indefinitely" → manual snapshot
- Needs OS-level access, a custom engine build, or an unsupported database → EC2, not RDS
Not this service
- Key-value or document data, serverless, single-digit-millisecond reads → DynamoDB
- MySQL/PostgreSQL-compatible but needs higher throughput or auto-scaling storage → Aurora
- Analytics and BI over billions of rows → Redshift, not a bigger read replica
Use cases
- 01Lifting a self-managed MySQL box off EC2 so nobody has to babysit patch nights, backup cron jobs, or replication setup again
- 02The transactional core of an ordinary web app — users, orders, payments — anywhere you need joins, foreign keys, and a transaction that rolls back cleanly
- 03Pointing the finance team's month-end reporting queries at a read replica so their giant SELECT doesn't slow down checkout
- 04Multi-AZ in production, Single-AZ in staging — same engine, same code, roughly half the bill where an hour of downtime is survivable
- 05Manual snapshot before a risky schema migration, so a bad ALTER TABLE at 2am is a restore instead of an incident
How it's charged
- 01Instance hours billed per second while running — instance class is the biggest line item, and Multi-AZ roughly doubles it (a Multi-AZ DB cluster runs three instances, so roughly triples it)
- 02Storage is billed on what you provision, not what you use — a 500 GB volume holding 20 GB of data still costs 500 GB
- 03Backup storage is free up to 100% of your provisioned DB size; beyond that, and for backups retained after the instance is deleted, it's billed per GB-month
- 04Stopping an instance stops instance-hour charges but not storage or backup charges — and RDS restarts it automatically after 7 days
- 05Running a major engine version past its end of standard support adds an RDS Extended Support charge per vCPU-hour; it applies to the standby too, and Reserved Instance discounts don't cover it
