AWS Database
Aurora
MySQL/PostgreSQL-compatible database with up to 5x the throughput of standard MySQL
Amazon Aurora is a MySQL and PostgreSQL-compatible relational database built for the cloud, offering up to 5x the throughput of standard MySQL and 3x that of PostgreSQL on the same hardware. Aurora decouples compute from storage - the storage layer is a distributed, self-healing cluster of 6 copies across 3 AZs that grows automatically up to 128 TB. It is the go-to choice when you need RDS-style management but require higher performance, faster failover, or global distribution.
Aurora Storage Architecture: Why It Is Different From RDS
Unlike RDS which uses a single EBS volume per instance, Aurora uses a shared distributed storage volume called the cluster volume. All DB instances in the cluster read from and write to this shared volume. Writes go to 6 storage nodes across 3 AZs simultaneously - Aurora acknowledges a write when 4 of 6 nodes confirm it.
| Attribute | Standard RDS | Aurora |
|---|---|---|
| Storage model | EBS attached to instance | Distributed cluster volume (shared) |
| Storage growth | Manual or autoscale EBS | Automatic in 10 GB increments up to 128 TB |
| Replication | EBS mirroring + redo logs | Log-structured distributed storage |
| Failover time | 60-120 seconds | < 30 seconds (often < 10 seconds) |
| Read replicas share storage? | No - each has its own EBS | Yes - all readers share the cluster volume |
| Replica lag | Seconds (async) | Typically < 100 ms |
Because Aurora readers share the same storage as the writer, adding a read replica does not double your storage cost. This is a major advantage over RDS read replicas for read-heavy workloads.
Cluster Types: Provisioned, Serverless v1, and Serverless v2
Aurora comes in three capacity modes. Choosing the wrong one is a common mistake - Serverless v1 has cold start issues that make it unsuitable for production APIs, while Serverless v2 scales in fine-grained increments with no cold starts.
| Mode | Scaling | Min Cold Start | Use Case | Pricing |
|---|---|---|---|---|
| Provisioned | Manual instance class change | None | Steady, predictable workloads | Per instance-hour |
| Serverless v1 | Warm pool of capacity units; minutes to scale | Yes (seconds-minutes) | Infrequent/intermittent use | Per ACU-second |
| Serverless v2 | Instant in 0.5 ACU increments | No | Variable production workloads | Per ACU-second (min 0.5 ACU) |
Aurora Serverless v1 pauses after a configurable idle period. The first connection after a pause can take 25-30 seconds to resume. Never use Serverless v1 for a customer-facing API. Use Serverless v2 or provisioned instead.
One Aurora Capacity Unit (ACU) is approximately 2 GB of memory plus proportional CPU and networking. A Serverless v2 instance can scale from 0.5 ACU to 128 ACU within seconds.
Aurora Global Database for Cross-Region HA and Disaster Recovery
Aurora Global Database replicates an Aurora cluster to up to 5 secondary AWS regions with typical replication lag under 1 second. It is used for both disaster recovery (RPO < 1 second, RTO < 1 minute) and for low-latency reads in other regions.
| Attribute | Value |
|---|---|
| Replication lag | Typically < 1 second |
| Secondary regions | Up to 5 |
| Read replicas per secondary | Up to 16 |
| RPO | < 1 second |
| RTO (managed failover) | < 1 minute |
| Write forwarding | Secondary regions can optionally forward writes to primary |
Global Database failover is a managed operation - you promote a secondary region to primary. This is different from Multi-AZ failover which is automatic. You still need tooling (Route 53 health checks, Lambda) to automate Global Database failover.
Key Aurora Features: Fast Clone, Backtrack, Parallel Query
Aurora has several features that have no equivalent in standard RDS. These come up frequently in architecture and migration interviews.
| Feature | What It Does | Common Use Case |
|---|---|---|
| Fast Clone | Creates a copy-on-write snapshot of the cluster in minutes regardless of size | Dev/test environments from production |
| Backtrack | Rewinds the database to a point in time in-place without restoring from backup (MySQL only) | Quick recovery from accidental deletes/drops |
| Parallel Query | Pushes analytical query processing down to the storage layer | Mixed OLTP + light analytics on same cluster |
| Machine Learning integration | Native SQL functions calling SageMaker or Comprehend | Inference at query time |
| Zero-ETL with Redshift | Near-real-time replication of Aurora data into Redshift | Analytics without managing DMS pipelines |
Backtrack is not a replacement for backups - it has a maximum backtrack window (up to 72 hours) and rewinding affects the entire cluster including all readers. It also incurs storage charges for the change log. Enable it on dev/staging, evaluate carefully for production.
Aurora vs RDS: When to Choose Which
Aurora costs roughly 20% more per instance-hour than equivalent RDS. The premium is justified in specific scenarios.
| Factor | Choose RDS | Choose Aurora |
|---|---|---|
| Engine requirement | Oracle, SQL Server, MariaDB | MySQL or PostgreSQL only |
| Cost sensitivity | Budget is the primary constraint | Performance/availability justify premium |
| Failover time | 60-120 seconds acceptable | Must be < 30 seconds |
| Read scaling | 5 replicas sufficient | Need up to 15 read replicas |
| Storage size | Under 64 TB | Up to 128 TB needed |
| Cross-region HA | Cross-region read replica (manual failover) | Global Database (< 1 min RTO) |
| Variable load | Predictable load | Spiky load - use Serverless v2 |
Aurora CLI Operations
# Create an Aurora Serverless v2 cluster (PostgreSQL)
aws rds create-db-cluster \
--db-cluster-identifier my-aurora-cluster \
--engine aurora-postgresql \
--engine-version 15.4 \
--master-username admin \
--master-user-password SecurePass123 \
--serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16 \
--db-subnet-group-name my-subnet-group \
--vpc-security-group-ids sg-12345
# Add a Serverless v2 instance to the cluster
aws rds create-db-instance \
--db-instance-identifier my-aurora-instance \
--db-cluster-identifier my-aurora-cluster \
--db-instance-class db.serverless \
--engine aurora-postgresql
# Create a fast clone
aws rds restore-db-cluster-to-point-in-time \
--db-cluster-identifier my-aurora-clone \
--source-db-cluster-identifier my-aurora-cluster \
--restore-type copy-on-write \
--use-latest-restorable-time
# Initiate a failover
aws rds failover-db-cluster \
--db-cluster-identifier my-aurora-clusterInterview Focus Points
- 1How is Aurora storage different from standard RDS? What are the implications for read replicas?
- 2What is Aurora Serverless v2 and how does it differ from v1? What are the cold start characteristics?
- 3Explain Aurora Global Database. What are the RPO and RTO, and how do you trigger a failover?
- 4A team wants to provision a dev database from their 2 TB production Aurora cluster. What is the fastest way?
- 5When would you choose Aurora over RDS? What does the price-to-performance trade-off look like?
- 6What is Aurora Backtrack and when would you use it instead of Point-in-Time Recovery?
- 7How does Aurora Zero-ETL work with Redshift? What problem does it solve?
- 8How many read replicas can Aurora support, and why is the replica lag so much lower than RDS?
- 9What happens to an Aurora cluster when the writer instance fails? Walk through the failover sequence.