Amazon Aurora: What It Is and When to Use It

Definition

Amazon Aurora is a fully managed relational database engine built by AWS for the cloud, wire-compatible with MySQL and PostgreSQL. It combines the simplicity and cost-effectiveness of open-source databases with the performance and availability of high-end commercial databases, delivering up to 5× the throughput of standard MySQL and up to 3× the throughput of standard PostgreSQL on equivalent hardware.

How It Works

Aurora decouples compute and storage in a way that standard RDS engines do not:

• Compute tier — one or more DB instances in an Aurora cluster. Exactly one writer; up to 15 reader replicas.
• Storage tier — a purpose-built, distributed, log-structured storage service shared by all instances in the cluster. Each 10 GB "segment" of your data is replicated six ways across three Availability Zones, with writes acknowledged on a quorum of four.

Replicas share the same storage volume as the writer, so replica lag is typically well under 100 ms and replicas don't consume extra storage. When the writer fails, Aurora can promote a replica to writer in seconds; when a storage node fails, Aurora transparently reroutes I/O to the remaining replicas.

An Aurora cluster exposes two endpoints by default:

• Cluster endpoint — always points to the current writer.
• Reader endpoint — load-balances across replicas for read traffic.

You can create custom endpoints for more targeted routing, and instance endpoints to hit a specific replica (useful for analytics).

Key Features and Limits

Engine compatibility

• Aurora MySQL-Compatible Edition — compatible with MySQL 5.7 and 8.0.
• Aurora PostgreSQL-Compatible Edition — compatible with many PostgreSQL versions; includes extensions like pgvector for vector similarity search.

Storage and scaling

• Shared storage volume: automatically grows in 10 GB increments up to 128 TiB. Billed per GB-month actually used, not provisioned.
• Up to 15 read replicas per Region per cluster, each with sub-10-ms replica lag.
• Aurora Auto Scaling dynamically adds or removes replicas based on CPU or connection count.

High availability and disaster recovery

• Six-way replication across three AZs by default — the cluster tolerates the loss of up to two copies for writes and up to three copies for reads without losing durability.
• Automated backups to S3 with 1–35-day retention and point-in-time restore.
• Aurora Backtrack (MySQL only) rewinds the database to a prior state in seconds without restoring from a snapshot, up to 72 hours.
• Aurora Global Database — up to five secondary Regions with typical sub-1-second cross-Region replication using dedicated storage-layer replication. Secondary Regions can be promoted to primary in under a minute for cross-Region failover.

Serverless options

• Aurora Serverless v2 — fine-grained auto scaling in 0.5 ACU (~1 GiB RAM / 2 vCPU) increments with sub-second transitions. Supports Multi-AZ, replicas, Global Database, and both engines. Pay per ACU-second.
• Aurora Serverless v1 is deprecated in favor of v2.

Newer capabilities

• Aurora I/O-Optimized — alternative pricing tier with no per-I/O charges; beneficial for I/O-heavy workloads where I/O cost exceeds 25% of the total.
• Aurora Zero-ETL integrations with Redshift — stream OLTP data to your warehouse with no ETL pipeline to build.
• Parallel Query (MySQL) — pushes the filtering and scan work down into the storage layer for analytical queries on large tables.
• Aurora Machine Learning — call SageMaker or Amazon Comprehend from SQL.
• RDS Data API — HTTP API for running queries from Lambda, App Runner, or other services without a persistent TCP connection.

Common Use Cases

1. Modernized MySQL / PostgreSQL workloads — existing apps move to Aurora for better performance and HA without code changes.
2. SaaS and multi-tenant apps — many writable Regions with Aurora Global Database, read replicas for tenants.
3. Event-driven and serverless backends — Aurora Serverless v2 + RDS Data API for unpredictable workloads with scale-to-zero economics (scale to 0 ACU supported on v2).
4. Financial and regulated workloads — strong consistency, quorum writes, encrypted storage, PITR, Global Database DR.
5. Analytics offload — Zero-ETL to Redshift keeps OLTP in Aurora and OLAP in the warehouse in near real time.
6. AI/ML features — pgvector on Aurora PostgreSQL as the vector store for RAG applications grounded in relational data.

Pricing Model

Aurora bills you on four axes:

1. Instance hours — per DB instance, based on instance class, engine, and whether the cluster is Aurora Standard or Aurora I/O-Optimized pricing.
2. Storage — per GB-month actually consumed (not provisioned). Aurora Standard also charges per million I/O requests; Aurora I/O-Optimized bundles I/O into the instance price.
3. Backup storage — free up to the size of your data; beyond that, per GB-month.
4. Data transfer — standard AWS rates.

Aurora Serverless v2 replaces instance hours with Aurora Capacity Unit-hours (ACU-h). Global Database incurs extra cross-Region replication charges.

Reserved Instances and Compute Savings Plans apply to Aurora, discounting on-demand instance hours by up to ~60%.

Pros and Cons

Pros

• 3–5× performance on the same hardware compared to stock MySQL/PostgreSQL.
• Six-copy, three-AZ storage gives industry-leading durability for relational data.
• Fast failover (seconds), up to 15 replicas, and fast replica lag (sub-10 ms).
• Serverless v2 with scale-to-zero is a compelling fit for intermittent workloads.
• Global Database offers enterprise cross-Region DR with sub-second replication.

Cons

• More expensive than vanilla RDS for small, low-traffic databases.
• Limited to MySQL and PostgreSQL compatibility — not available for Oracle, SQL Server, MariaDB, or Db2.
• Aurora-specific features (Backtrack, Global Database, Zero-ETL) create lock-in; migrating off Aurora means leaving those behind.
• Standard pricing can surprise I/O-heavy workloads; I/O-Optimized is usually the right choice above ~25% I/O cost share.

Comparison with Alternatives

| | Aurora | RDS MySQL / Postgres | DynamoDB | | --- | --- | --- | --- | | Engine | MySQL / Postgres-compatible | Stock MySQL / Postgres | NoSQL | | Max replicas | 15 | Typically 5 | N/A (Global Tables for multi-Region) | | Replica lag | <10 ms typical | Seconds to milliseconds | N/A | | Storage | Shared, auto-scaling, 128 TiB | EBS attached per instance | Managed internally | | Cross-Region replication | Aurora Global Database (sub-second) | Cross-Region Read Replica | Global Tables (multi-active) | | Serverless mode | Aurora Serverless v2 | None (except via Aurora) | On-Demand native | | Best for | MySQL/Postgres workloads needing performance + HA | Engines Aurora doesn't support, cost-sensitive small DBs | Key-value workloads |

Exam Relevance

• Solutions Architect Associate (SAA-C03) — Aurora cluster architecture, Multi-AZ, replicas, Global Database for cross-Region DR, when to pick Aurora over RDS.
• Developer Associate (DVA-C02) — Aurora Serverless, RDS Data API, connection strategies (RDS Proxy), IAM authentication.
• Database Specialty (DBS-C01) — Backtrack, cloning, Zero-ETL to Redshift, Parallel Query, storage-tier pricing comparisons, advanced HA/DR scenarios.

High-frequency exam trap: Aurora's "6 copies across 3 AZs" durability model is specific to Aurora, not standard RDS. Expect this to appear in durability and resilience questions.

Frequently Asked Questions

Q: How is Aurora different from standard RDS MySQL or PostgreSQL?

A: Aurora replaces the engine's storage layer with AWS's distributed, log-structured storage that replicates six ways across three Availability Zones. This enables up to 15 low-lag read replicas, 128 TiB auto-growing storage, fast failover, serverless scaling, and Global Database for cross-Region DR. The trade-off is slightly higher instance cost and Aurora-only features that don't exist on stock MySQL/PostgreSQL.

Q: When should I choose Aurora Serverless v2?

A: Choose Serverless v2 when traffic is intermittent, unpredictable, or has long idle periods — for example, multi-tenant SaaS apps, dev/test environments, analytical sandboxes, and workloads where Lambda or Step Functions drive the database usage. Serverless v2 scales in 0.5 ACU increments in sub-second time and can scale to 0 ACU during idle, which eliminates the fixed cost of a running instance. For steady, predictable traffic, provisioned Aurora + Reserved Instances is usually cheaper.

Q: Should I pick Aurora Standard or Aurora I/O-Optimized pricing?

A: Aurora Standard charges per I/O operation on top of instance and storage costs — best for low-to-moderate I/O workloads. Aurora I/O-Optimized bundles I/O into a higher instance price and charges more for storage, with no per-I/O fee. Switch to I/O-Optimized when I/O charges exceed roughly 25% of your Aurora bill; most write-heavy OLTP and analytics-leaning workloads benefit. You can switch between the two modes once every 30 days.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official Amazon Aurora documentation before making production decisions.