Databases
Amazon Aurora
Amazon Aurora is AWS's cloud-native relational database, compatible with MySQL and PostgreSQL. It separates compute from a distributed storage layer, giving higher performance and availability than standard RDS engines. On the exam, Aurora is often the answer for demanding relational workloads.
Architecture
- Storage is shared by all instances in a cluster and replicated six ways across three AZs.
- Tolerates the loss of two copies for writes and three for reads; storage self-heals.
- Storage grows automatically in 10 GB increments up to very large sizes (128 TiB, higher on newer versions).
- Compute: one writer instance plus up to 15 Aurora Replicas (readers) sharing the same storage — replica lag is typically very low.
Endpoints
| Endpoint | Points to |
|---|---|
| Cluster (writer) endpoint | The current primary — use for writes |
| Reader endpoint | Load-balances connections across replicas |
| Custom endpoints | A chosen subset of instances (e.g. larger instances for analytics) |
| Instance endpoints | A specific instance |
Availability and failover
- If the writer fails, Aurora promotes a replica (priority tiers decide which), typically in well under a minute; the cluster endpoint follows automatically.
- No replica? Aurora creates a new writer (slower).
Aurora Global Database
- One primary Region plus secondary Regions with read-only clusters.
- Storage-level replication with typical lag under one second.
- Promote a secondary for disaster recovery in about a minute (RTO) with very small data loss (RPO measured in seconds).
- Low-latency reads for users around the world.
Key idea
"Relational database, cross-Region DR with RPO of seconds and RTO of about a minute" → Aurora Global Database.
Aurora Serverless v2
- Capacity scales automatically in fine-grained increments (Aurora Capacity Units) based on load, within the min/max you set.
- Ideal for variable, unpredictable or intermittent workloads, new apps, dev/test, and multi-tenant SaaS.
- Can mix serverless and provisioned instances in one cluster.
Other features
| Feature | What it does |
|---|---|
| Backtrack (MySQL-compatible) | Rewind the database to a point in time without restoring from backup |
| Fast database cloning | Copy-on-write clones for testing, in minutes |
| Aurora I/O-Optimized | Pricing option with no per-I/O charges for I/O-heavy workloads |
| Parallel query (MySQL) | Push analytical query processing to the storage layer |
| Zero-ETL integration with Redshift | Replicate data for analytics without pipelines |
| Machine learning integration | Call SageMaker/Comprehend from SQL |
RDS vs Aurora
| Choose Aurora when… | Choose RDS (MySQL/PostgreSQL) when… |
|---|---|
| High performance and availability are priorities | Smaller, simpler or cost-sensitive workloads |
| You need many low-lag read replicas | A few replicas are enough |
| Cross-Region DR with second-level RPO | Standard backups / cross-Region replicas suffice |
| Variable workloads (Serverless v2) | Steady, small workloads |
| Storage should scale without planning | Predictable storage needs |
Exam patterns
- "MySQL-compatible database that scales reads with up to 15 low-latency replicas" → Aurora.
- "Unpredictable traffic with idle periods, minimise cost and management" → Aurora Serverless v2.
- "Global users need low-latency reads; DR with RPO < 1 second" → Aurora Global Database.
- "Developers need a full copy of production data quickly for testing" → Aurora cloning.
Written by Bipin Singh
Work with meSenior Full-Stack Engineer · AI & AWS. I design and run production systems on AWS — serverless, data and AI.