Amazon Aurora
A cloud-native relational database built by AWS that delivers up to 5x the throughput of MySQL and up to 3x the throughput of PostgreSQL
Overview
Amazon Aurora is a relational database engine designed from the ground up by AWS for the cloud. It is compatible with MySQL and PostgreSQL, allowing you to use existing application code and tools with minimal changes. Storage is automatically replicated across 6 copies spanning 3 Availability Zones and auto-scales up to the cluster volume limit. As of September 2026, the AWS documentation states that this limit is either 128 TiB or 256 TiB depending on the engine version. With Aurora Serverless v2, database capacity automatically scales based on workload demand, reducing costs during idle periods. As of September 2026, the AWS quota allows up to 15 read replicas per primary, and the time a failover takes depends on the configuration and the nature of the failure. Aurora Global Database replicates data asynchronously to secondary regions, enabling cross-region failover for disaster recovery.
Compute-Storage Separation Architecture
The secret behind Aurora's high performance lies in its unique architecture that separates compute from storage. In traditional RDS, storage is directly attached to the database instance, but in Aurora, the storage layer operates as an independent distributed system. Data is divided into 10 GB segments, and each segment is stored as 6 copies across 3 AZs. A write is considered complete when 4 out of 6 copies succeed (4/6 quorum), and a read completes when 3 copies respond (3/6 quorum). This design means data remains readable even if 2 copies are simultaneously lost. The automatic repair feature detects failed segments and rebuilds them automatically. Azure SQL Database Hyperscale employs a similar compute-storage separation architecture, but a structural difference is that Aurora supports two engines (MySQL and PostgreSQL), whereas Hyperscale is limited to the SQL Server engine.
Serverless v2 and Read Replica Strategies
Aurora Serverless v2 auto-scales database capacity in fine-grained ACU (Aurora Capacity Unit) increments, making it well suited to workloads with significant traffic fluctuations such as development environments, staging, and applications with unpredictable usage patterns. The minimum and maximum capacity you can scale between varies by engine version and configuration, so check the AWS documentation for the current values. Unlike provisioned instances where you pay for fixed capacity regardless of utilization, Serverless v2 scales down during idle periods, reducing costs. For read-heavy workloads, as of September 2026 the AWS quota allows up to 15 read replicas per primary to distribute read traffic and reduce the load on the primary writer instance. Read replicas share the same storage volume as the primary, so replica lag is generally short, although the actual lag depends on the workload. A practical strategy is to combine a Serverless v2 writer for variable write workloads with provisioned read replicas for predictable read-heavy queries, or use Reader endpoints with Aurora's built-in load balancing to distribute connections automatically.
Recovery Strategies with Backtrack and Global Database
Aurora provides multiple recovery mechanisms for different failure scenarios. Backtrack (MySQL-compatible only) lets you rewind the database to any point within the retained window quickly, enabling rapid recovery from human errors such as accidental DELETE statements or bad schema migrations - without restoring from a snapshot (the length of the retained window depends on your settings and the AWS specification). This avoids creating a new cluster from a backup, which traditional point-in-time recovery requires. For regional disaster recovery, Aurora Global Database replicates data asynchronously to secondary regions. In a disaster scenario, you can promote a secondary region to become the new primary; the time the failover takes and the resulting RPO depend on the configuration and the nature of the failure, so check the AWS documentation for your configuration. On the cost side, prepaying with Reserved Instances can reduce costs compared with on-demand pricing, with the discount depending on the term and the payment option. Use Performance Insights to visualize query performance and continuously identify slow queries and optimize indexes for ongoing operational efficiency.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
If this page and the official documentation disagree, treat the official documentation as authoritative.