Amazon Aurora is a relational database built from scratch for the cloud, fully compatible with MySQL and PostgreSQL. It runs on a distributed storage architecture that replicates data six ways across three Availability Zones by default -- even with a single database instance. AWS claims up to 5x the throughput of standard MySQL and 3x that of standard PostgreSQL on equivalent hardware.
Previewed at AWS re:Invent 2014 and generally available since July 2015, Aurora has become one of the most widely used managed databases on AWS. It sits within the RDS family but runs on fundamentally different internals than standard RDS MySQL or PostgreSQL.
Architecture
Aurora separates compute from storage in a way that standard databases don't. Three layers work together:
Distributed Storage: Data lives in a cluster volume backed by SSDs, spread across three Availability Zones with six copies total. The system tolerates losing two copies without affecting writes and three copies without affecting reads. Storage scales automatically -- up to 256 TiB per cluster as of mid-2025 -- and you only pay for what you use.
Log-Based Replication: Instead of writing full data pages to storage (the traditional approach), Aurora sends only redo log records. This eliminates double-write buffers, reduces write amplification, and pushes more work to the storage layer. The result is higher write throughput and lower latency.
Shared Storage for Replicas: Aurora Replicas read from the same underlying storage as the primary instance. No data copying, no replication lag in the traditional sense -- new data is typically visible to replicas within 10-20 milliseconds. Up to 15 read replicas per cluster.
Aurora vs. Standard RDS
The obvious question: why Aurora over a standard RDS MySQL or PostgreSQL instance?
Performance: Aurora's log-based writes and distributed storage deliver better throughput, especially for write-heavy workloads. Read performance from cache is similar, but disk reads are faster thanks to the distributed storage layer.
Replication: Standard RDS uses logical replication with lag that can stretch to seconds or minutes under heavy writes. Aurora replicas share the storage layer, keeping lag in the low milliseconds.
Replicas: 15 for Aurora vs. 5 for standard RDS.
Failover: Aurora promotes a replica faster because there's no transaction replay needed -- the shared storage is already current.
Cost: Aurora instances run roughly 20-30% more per hour than equivalent RDS instances. But the performance gains often mean you can run smaller instances for the same workload, and the operational simplicity of the shared storage model reduces hidden costs.
Engine coverage: Aurora only supports MySQL and PostgreSQL. Need MariaDB, Oracle, SQL Server, or Db2? Standard RDS is the path.
Key Features
Aurora Serverless v2
Auto-scaling compute that adjusts in fine-grained increments (0.5 ACU steps) based on actual load. No capacity planning, no idle instances burning money during off-peak hours. Scales from 0.5 ACU up to 256 ACU. Supports the full Aurora feature set including Global Database, Multi-AZ, and read replicas. As of mid-2025, Serverless v2 runs up to 30% faster on the latest platform version.
Global Database
Write in one region, read from up to ten secondary regions worldwide. Cross-region replication happens at the storage layer with lag typically under one second. Write forwarding lets secondary clusters route writes to the primary. Disaster recovery failover completes in under a minute.
Backtrack
Rewind a MySQL-compatible Aurora database to any point within the last 72 hours -- in seconds, regardless of database size. No restore from backup, no waiting for a new cluster to spin up. Made a bad schema migration? Backtrack undoes it almost instantly. PostgreSQL doesn't support this feature; you'd need to restore from a snapshot instead.
Cloning
Copy-on-write cloning creates a full copy of a multi-terabyte cluster in minutes. The clone shares the original's storage initially and only allocates new space as data diverges. Spinning up a production-sized test environment costs almost nothing until you start making changes.
Parallel Query
Pushes analytical query processing down to the storage layer, offloading work from the compute instance. Analytical queries can run up to 100x faster without degrading transactional workload performance.
Zero-ETL Integration with Redshift
Transactional data in Aurora becomes available in Amazon Redshift within seconds -- no ETL pipelines to build or maintain. Useful when you need to run heavy analytics against operational data without impacting the production database.
Aurora I/O-Optimized
Standard Aurora charges per million I/O requests on top of instance and storage costs. For I/O-heavy workloads, those charges can dominate the bill.
Aurora I/O-Optimized eliminates I/O charges entirely. Instance and storage prices are higher, but if I/O spend exceeds 25% of your total Aurora cost, switching saves up to 40%. For PostgreSQL workloads, it also includes tiered caching that stores evicted buffer pool data on local storage, cutting query latency by up to 8x for read-heavy patterns.
Aurora DSQL
Aurora DSQL is a serverless, distributed SQL database with PostgreSQL compatibility, designed for active-active multi-region deployments with strong consistency. It went generally available in May 2025.
Reads and writes scale independently without sharding or instance management. Single-region deployments get a 99.99% availability SLA; multi-region gets 99.999%. Pricing is based on Distributed Processing Units (DPUs) -- roughly $8 per million DPUs in us-east-1 -- and scales to zero when idle.
The tradeoff: DSQL uses optimistic concurrency control, so applications need to handle transaction retries. Its PostgreSQL compatibility surface is narrower than full Aurora PostgreSQL.
Aurora Limitless Database
For workloads that outgrow a single writer instance, Limitless Database adds serverless horizontal scaling (sharding) to Aurora PostgreSQL. A routing layer accepts connections and coordinates queries across multiple shards that each store a subset of data. Tables can be sharded by a key, replicated across all shards as reference tables, or left unsharded. Each shard supports up to 128 TiB. Requires Aurora I/O-Optimized.
Pricing
Aurora pricing depends on the configuration:
- Standard: Instance hours (per-second billing, 10-minute minimum) + storage per GB-month + I/O per million requests + backup storage + data transfer.
- I/O-Optimized: Higher instance and storage rates, zero I/O charges.
- Serverless v2: ACU-hours instead of instance hours. Roughly $0.12 per ACU-hour depending on region.
- Reserved Instances: 1-year or 3-year commitments with significant discounts over On-Demand.
Common Use Cases
- SaaS Applications: Multi-tenant backends that need to handle 10x traffic swings between peak and off-peak without manual intervention. Serverless v2 fits this pattern well.
- Web and Mobile at Scale: Internet-scale applications requiring multi-region reads, sub-second replication lag, and automatic failover.
- Gaming: High-throughput writes for leaderboards, player state, and real-time multiplayer. Aurora DSQL addresses globally consistent state across regions.
- Financial Services: Mission-critical workloads where Global Database provides cross-region disaster recovery with sub-minute failover.
- Enterprise Migration: Replacing on-premises MySQL or PostgreSQL deployments with a managed service that offers better performance and availability without application rewrites.
Limitations
Aurora only speaks MySQL and PostgreSQL -- no MariaDB, Oracle, or SQL Server. It's deeply tied to AWS infrastructure, making multi-cloud or on-premises portability difficult. Standard Aurora clusters have a single-writer architecture; write throughput hits a ceiling around 20,000 QPS unless you move to Limitless Database or DSQL. Storage grows automatically but doesn't shrink. I/O costs on the Standard tier can surprise teams that don't monitor them. And while Backtrack is powerful, it's MySQL-only.
Aurora in the Broader Data Stack
Aurora handles transactional workloads well, but most organizations run it alongside other data systems. Analytical queries that scan billions of rows belong in a columnar engine like ClickHouse. Full-text search and log analytics run on Elasticsearch or OpenSearch. Real-time event processing flows through Kafka or Flink. The challenge is building reliable, low-latency data pipelines between Aurora and these specialized systems -- getting change data capture right, managing schema evolution, and keeping costs predictable as data volumes grow.