Amazon Aurora
AWS-built MySQL- and PostgreSQL-compatible relational database with self-healing storage spread across three AZs.
Verified against AWS documentation · 2026-09-09
Key facts
- 01An engine choice inside RDS — same console, backups, and patching, with AWS's own storage layer underneath
- 02Shared cluster volume: 6 copies across 3 AZs, auto-grows to 256 TiB, no disk to provision
- 03One writer, up to 15 readers; failover promotes a reader in under 60s — with no reader, expect ~10 minutes
- 04Serverless bills per second in ACUs (~2 GiB each, 0–256) and pauses at 0 when idle; Global Database adds up to 10 read-only Regions
Exam triggers
Phrases and scenarios that point here.
- "MySQL or PostgreSQL" + "highest availability" or "best performance" → Aurora, not RDS
- Must survive an AZ outage with no failover code written by the customer → Aurora cluster with readers in other AZs
- Global users need local read latency, or recovery from a Region-wide outage → Aurora Global Database
- Spiky, unpredictable, or idle-most-of-the-day database → Aurora Serverless
Not this service
- Oracle, SQL Server, MariaDB, or the cheapest managed SQL → RDS
- Key-value or document data, single-digit ms at any scale → DynamoDB
- Dashboards and analytics over billions of rows → Redshift
Use cases
- 01Production SaaS backend that must ride out an AZ failure — the cluster endpoint follows the new writer, the app just reconnects
- 02Read-heavy catalogs and internal dashboards — add readers and point them at the reader endpoint instead of buying a bigger writer
- 03Moving a self-managed MySQL or PostgreSQL app off EC2 with no driver or schema changes, purely to stop hand-managing replication and backups
- 04Dev, test, and internal tools that sit idle overnight — Serverless drops to 0 ACUs and wakes on the first connection in roughly 15 seconds
- 05Global apps writing in one Region while other Regions serve sub-second-stale local reads and double as a warm DR standby
How it's charged
- 01Compute: provisioned instance-hours (On-Demand or Reserved) or Serverless ACU-seconds — every reader is billed like its own instance
- 02Storage: per GB-month of space actually used; the volume grows and shrinks on its own, and you pay for one copy despite the six
- 03Two cluster configurations — Aurora Standard adds a per-million-I/O charge, Aurora I/O-Optimized drops I/O charges for higher instance and storage rates; AWS's own rule is to switch once I/O passes ~25% of Aurora spend
- 04Backups are free up to 100% of your cluster volume size; snapshots kept past the 1–35 day retention window are billed per GB-month
- 05Global Database bills replicated write I/Os to every secondary Region on top of the instances and storage running there — a second Region roughly doubles the bill, it doesn't nudge it
