Amazon Aurora
Amazon Aurora is AWS's cloud-native relational database, MySQL- and PostgreSQL-compatible, delivered through Amazon RDS. It combines the familiarity of open-source engines with a re-architected storage layer that distributes data across three Availability Zones with six-way replication — giving higher throughput, faster recovery, and near-zero data loss.
Key Features:
- Distributed Storage: 10 GB segments replicated 6 ways across 3 AZs; storage auto-scales up to 128 TiB (Aurora MySQL/PostgreSQL) without downtime.
- Aurora Replicas: Up to 15 low-latency read replicas sharing the same storage volume; failover to a replica typically under 30 seconds.
- Aurora Serverless v2: On-demand auto-scaling capacity (measured in ACUs) that scales in seconds, ideal for variable or unpredictable workloads.
- Global Database: Single primary region with up to 5 read-only secondary regions; cross-region replication via dedicated infrastructure with sub-second lag and ~1-minute RTO on regional failure.
- Backtrack (MySQL): Rewind the database in place to a previous point in time (up to 72 hours) without restoring a backup.
- Parallel Query: Push query processing down into the distributed storage layer for large analytical scans.
- Zero-ETL to Redshift: Continuous replication of Aurora tables into Amazon Redshift for analytics without building pipelines.
- Aurora I/O-Optimized: Storage tier with no per-IO charges — flat predictable cost for I/O-heavy workloads.
Aurora vs. RDS (MySQL/Postgres):
- Performance: Aurora typically delivers 3-5x MySQL throughput and 2-3x PostgreSQL throughput on the same hardware.
- Availability: 6-way replication across 3 AZs vs. RDS's single-AZ primary + Multi-AZ standby.
- Cost: Aurora is ~20% more expensive than equivalent RDS, but the storage model often reduces total cost at scale.
- Choose RDS for plain MySQL/PostgreSQL/MariaDB/Oracle/SQL Server workloads; choose Aurora when you need Aurora-specific features (Serverless v2, Global Database, Backtrack, Parallel Query, Zero-ETL).
Common Use Cases:
- High-throughput OLTP workloads that outgrow vanilla RDS.
- SaaS applications needing multi-tenant scale with per-tenant read replicas.
- Global applications with sub-second cross-region read latency requirements.
- Variable workloads (dev/test, spiky traffic) on Aurora Serverless v2.
- Analytics on operational data via Zero-ETL to Redshift.
Service Limits & Quotas:
- Storage: 128 TiB max per cluster volume (auto-grows in 10 GB segments).
- Aurora Replicas per cluster: 15.
- Global Database secondary regions: up to 5.
- Backtrack window: up to 72 hours (Aurora MySQL only).
- Backup retention: 1-35 days for automated backups.
- Serverless v2 capacity: 0.5 to 256 ACUs per writer/reader (1 ACU ~ 2 GiB RAM + proportional CPU).
- Connections: engine-dependent; PostgreSQL default
max_connections scales with instance size.
Pricing Model:
- Instance hours: per-second by class (db.r6g, db.r7g, db.t4g, etc.); Serverless v2 billed per ACU-hour.
- Storage (Standard): $0.10/GB-month + $0.20 per million IO requests.
- Storage (I/O-Optimized): $0.225/GB-month, no per-IO charge — wins above ~25% I/O-cost ratio.
- Backups: free up to cluster size; charged per GB-month beyond.
- Global Database: additional cross-region replication and storage charges.
- Common cost surprise: Standard storage on a heavy-write workload — IO costs can equal or exceed compute. Switch to I/O-Optimized once monthly IO charges exceed ~25% of compute.
Code Example — Create a Serverless v2 Aurora PostgreSQL Cluster:
aws rds create-db-cluster \
--db-cluster-identifier prod-app \
--engine aurora-postgresql \
--engine-version 16.3 \
--serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16 \
--master-username dbadmin \
--manage-master-user-password \
--vpc-security-group-ids sg-0abc123 \
--db-subnet-group-name prod-private \
--storage-encrypted \
--kms-key-id alias/aurora \
--backup-retention-period 14 \
--deletion-protection
aws rds create-db-instance \
--db-instance-identifier prod-app-writer \
--db-cluster-identifier prod-app \
--db-instance-class db.serverless \
--engine aurora-postgresql
aws rds create-db-instance \
--db-instance-identifier prod-app-reader \
--db-cluster-identifier prod-app \
--db-instance-class db.serverless \
--engine aurora-postgresql
Connect via boto3 RDS Data API (Serverless):
import boto3
data = boto3.client("rds-data", region_name="us-west-2")
resp = data.execute_statement(
resourceArn="arn:aws:rds:us-west-2:111122223333:cluster:prod-app",
secretArn="arn:aws:secretsmanager:us-west-2:111122223333:secret:rds!cluster-xxx",
database="orders",
sql="SELECT id, total FROM orders WHERE created_at > :since",
parameters=[{"name": "since", "value": {"stringValue": "2026-04-01"}}],
)
for row in resp["records"]:
print(row)
Common Interview Questions:
How does Aurora storage differ from RDS storage?
Aurora uses a distributed log-structured storage layer shared by the writer and all readers — instances don't have their own EBS volumes. Writes propagate as redo log records to 6 storage nodes across 3 AZs and are acknowledged when 4 of 6 confirm (quorum). Readers replay log on read, eliminating replication lag in steady state.
Aurora Serverless v1 vs. v2?
v1 paused fully when idle and scaled in chunks with cold-start latency; v2 scales in fine 0.5-ACU steps in seconds without pausing, supports read replicas, and is the recommended option for production. v1 is being deprecated.
What is Backtrack and when use it?
Aurora MySQL feature that rewinds the cluster's storage volume to an earlier timestamp (up to 72 hours) in seconds, without restoring a snapshot. Used for "oops" recoveries — accidental DROP TABLE, bad migration. Not in PostgreSQL; use point-in-time restore there.
How does failover work in Aurora?
The cluster has a writer endpoint (DNS) pointing at the current writer; on writer failure, Aurora promotes one replica (priority-ordered) and re-points the writer endpoint, typically in under 30 seconds. Reader endpoints load-balance across the surviving readers.
What's Zero-ETL to Redshift?
Native managed replication from Aurora MySQL/PostgreSQL into a Redshift cluster — change data captured at the storage layer and applied to Redshift typically within seconds. Eliminates Glue/DMS pipelines for the common operational-to-analytical pattern.
When pick I/O-Optimized over Standard storage?
When I/O charges on Standard exceed ~25% of total cluster cost, or when workload IOPS are unpredictable enough that flat-rate storage simplifies budgeting. I/O-Optimized has higher per-GB price but no per-IO charges.