Aurora — Concept
What it is
Amazon Aurora = AWS-built relational engine, compatible with MySQL and PostgreSQL. Same APIs and SQL as those engines, but 3–5× faster (MySQL) / 3× faster (Postgres), with a distributed, fault-tolerant storage layer purpose-built for the cloud.
Why it exists
Classic RDS uses single EBS volumes attached to a primary. Aurora separates compute from a distributed storage layer that auto-scales and self-heals, dramatically improving availability and read scalability.
Architecture
- Cluster = 1 writer + up to 15 Aurora Replicas, all sharing the same storage volume.
- Storage layer: 6 copies across 3 AZs, autoscaling up to 128 TiB (~256 TiB on newer versions).
- Auto-heals corrupted blocks; transparently re-replicates.
- Cluster endpoint → always points to current writer.
- Reader endpoint → DNS round-robin across replicas.
- Custom endpoints for read sharding.
- Failover < 30 s typically (often ~5–10 s).
Aurora Replicas vs RDS Read Replicas
- Aurora replicas read from the shared storage (no replication lag in the classic sense; commits are visible quickly).
- Auto-failover: any replica can be promoted in < 30 s.
- Multi-AZ by default with the shared storage layer.
Aurora Global Database
- Single primary region + up to 5 secondary regions, replication via Aurora's own storage layer.
- Latency typically < 1 s replication.
- RPO < 1 s, RTO < 1 min (region failover).
- Each secondary can have up to 16 read replicas.
Aurora Serverless v2
- Compute auto-scales in seconds, in 0.5 ACU increments.
- Pay per ACU-hour (no need to size instances).
- Great for variable / unpredictable workloads.
- v1 had cold-start; v2 is near-instant and supports Multi-AZ + Global DB.
Backtrack (MySQL only)
- Rewind the cluster up to 72 hours without restoring from a backup — for "oops I dropped the table" recovery.
Aurora ML
- Built-in integration with SageMaker and Comprehend via SQL functions (sentiment, fraud detection, etc.).
Security
- VPC SG, KMS encryption, IAM DB auth (MySQL/Postgres-compatible), Secrets Manager rotation, audit logs.
When to use vs alternatives
| Use ... | Instead of ... | When ... |
|---|---|---|
| Aurora | RDS MySQL/Postgres | You want max perf, HA, read scaling, Global DB |
| Aurora Serverless v2 | Aurora provisioned | Spiky / unpredictable workloads |
| Aurora Global DB | Cross-region read replica | DR < 1 min RTO + reads in many regions |
| DynamoDB | Aurora | Key-value, single-digit ms, massive scale, schemaless |
| RDS | Aurora | Tight cost, low traffic, Oracle / SQL Server / Db2 needed |
Common exam scenarios
- "Postgres workload needs read scaling and < 30s failover" → Aurora PostgreSQL with replicas.
- "Global app: writes in us-east-1, reads worldwide, < 1 min DR" → Aurora Global DB.
- "Dev/test DB used 3 hours a day, pay-per-use" → Aurora Serverless v2.
- "Accidentally dropped a MySQL table 1 hour ago" → Aurora Backtrack (no restore).
- "Lambda spikes overwhelm DB connections" → RDS Proxy in front of Aurora.
Exam tip
Aurora is the AWS-preferred managed relational DB in best-practice answers when MySQL/Postgres is OK. Global DB is the headline DR feature; Serverless v2 is the headline cost-flex feature.