Aurora

Amazon Aurora is a relational database that suits applications requiring ACID compliance, high performance, and scalability. Aurora is designed for OLTP workloads and can handle both read-intensive and write-intensive workloads at a lower cost than traditional databases. It is built on top of the same Amazon RDS management plane, so most RDS operational features (Multi-AZ, snapshots, IAM authentication, Performance Insights, and so on) apply to Aurora clusters as well.

High Performance

Aurora is described by AWS as delivering up to five times the throughput of standard MySQL and up to three times the throughput of standard PostgreSQL. This performance is achieved by:

using a distributed architecture that scales up to millions of transactions per second;
tightly integrating the database engine with an SSD-based virtualized storage layer purpose-built for database workloads;
reducing writes to the storage system;
minimizing lock contention;
eliminating delays created by database process threads;
offering an intelligent caching layer that improves query performance; and
Parallel Query, which pushes down and distributes the computational load of a single query across thousands of CPUs in Aurora's storage layer, speeding up analytical queries by up to two orders of magnitude.

Compatibility

Aurora is compatible with both MySQL and PostgreSQL, which makes it straightforward to migrate existing MySQL or PostgreSQL databases to Aurora using standard import/export tools or snapshots. Aurora MySQL-Compatible Edition offers MySQL 8.4 LTS as a selectable engine version for new or upgraded clusters, alongside other actively supported MySQL versions. See Deployment and Migration for migration tooling such as AWS DMS and AWS SCT.

Availability and Durability

Amazon Aurora automatically divides a database volume into 10 GB segments spread across many disks. Each 10 GB segment is replicated six ways across three Availability Zones, so there is no single point of failure; Aurora automatically attempts to recover the database in a healthy AZ with no data loss. Aurora storage is self-healing: data blocks and disks are continuously scanned for errors and repaired automatically.

If data is unavailable within Aurora storage, it is possible to restore from a DB Snapshot or perform a point-in-time restore to a new instance; the latest restorable time for a point-in-time restore can be up to five minutes in the past. Automated continuous backups to S3 are always enabled on Aurora DB instances, and backups and snapshots do not impact database performance.

Aurora Global Database uses physical replication over dedicated infrastructure, keeping databases available across the globe to serve an application, and can replicate to up to five secondary regions with typical latency under a second. A secondary region can be manually promoted (there is no automatic failover to a secondary region) to take full read/write workloads in under a minute. Up to 15 Aurora Replicas can be added on each cross-region cluster; one cross-region replica acts as the primary on the cluster, and the other Aurora Replicas typically lag behind the primary by tens of milliseconds. A promotion priority tier can be assigned to each instance on a cluster: when the primary instance fails, RDS promotes the replica with the highest priority; if two or more replicas share the same priority, RDS promotes the one largest in size; if two or more share the same priority and size, RDS promotes an arbitrary replica in that promotion tier.

Because Aurora Replicas share the same data volume as the primary instance in the same AWS Region, there is virtually no replication lag — typically observed in the tens of milliseconds. For cross-region replication, binlog-based logical replication lag can grow indefinitely based on the change/apply rate and network delays, though under typical conditions replication lag is under a minute. Cross-region replicas using Aurora Global Database's physical replication typically lag under a second. See also MySQL's own Replication mechanisms for comparison.

Unlike other databases, after a crash Aurora does not need to replay the redo log from the last database checkpoint (typically a five-minute operation) and confirm that all changes have been applied before making the database available. This reduces database restart times to less than 60 seconds in most cases. Aurora moves the buffer cache out of the database process, making it available immediately at restart time and avoiding the need to throttle access until the cache repopulates.

A final DB Snapshot can be created when deleting a DB instance and used to restore the deleted instance at a later date; Aurora retains this final snapshot along with other manually created snapshots after the instance is deleted. Only DB Snapshots are retained after deletion (automated backups created for point-in-time restore are not kept). Shared Aurora snapshots are only accessible by accounts in the same region as the account that shared them; encrypted Aurora snapshots can also be shared.

Scalability

Aurora scales both vertically and horizontally. Vertical scaling increases the performance of a single Aurora instance; horizontal scaling adds more Aurora instances to handle increased workload. Minimum storage is 10 GB; based on usage, Aurora storage automatically grows up to 128 TiB in 10 GB increments with no impact on database performance.

Backtrack

Backtrack lets you quickly undo unwanted changes to an Aurora database, up to a certain point in time, without needing a full point-in-time restore to a new instance.

Multi-master

Aurora allows up to 15 read/write instances in a cluster, providing high availability and scalability. Any instance in the cluster can accept writes, making it easier to scale write-heavy workloads.

Serverless

Aurora Serverless is a deployment option that runs an Aurora database in a serverless configuration, automatically scaling the database instance up or down based on demand without managing the underlying infrastructure.

# Create an Aurora MySQL-Compatible cluster with a primary instance
aws rds create-db-cluster \
    --db-cluster-identifier mydb-aurora-cluster \
    --engine aurora-mysql \
    --master-username admin \
    --master-user-password mypassword

aws rds create-db-instance \
    --db-instance-identifier mydb-aurora-instance-1 \
    --db-cluster-identifier mydb-aurora-cluster \
    --engine aurora-mysql \
    --db-instance-class db.r6g.large

# Undo unwanted changes with Backtrack (Aurora MySQL only), rewinding the
# cluster to a specific point in time
aws rds backtrack-db-cluster \
    --db-cluster-identifier mydb-aurora-cluster \
    --backtrack-to "2026-08-16T09:00:00Z"

# Manually promote a secondary region in an Aurora Global Database to take
# full read/write workloads
aws rds failover-global-cluster \
    --global-cluster-identifier mydb-global-cluster \
    --target-db-cluster-identifier arn:aws:rds:us-west-2:123456789012:cluster:mydb-aurora-secondary

# Create an Aurora MySQL-Compatible cluster with a primary instance
aws rds create-db-cluster \
    --db-cluster-identifier mydb-aurora-cluster \
    --engine aurora-mysql \
    --master-username admin \
    --master-user-password mypassword

aws rds create-db-instance \
    --db-instance-identifier mydb-aurora-instance-1 \
    --db-cluster-identifier mydb-aurora-cluster \
    --engine aurora-mysql \
    --db-instance-class db.r6g.large

# Undo unwanted changes with Backtrack (Aurora MySQL only), rewinding the
# cluster to a specific point in time
aws rds backtrack-db-cluster \
    --db-cluster-identifier mydb-aurora-cluster \
    --backtrack-to "2026-08-16T09:00:00Z"

# Manually promote a secondary region in an Aurora Global Database to take
# full read/write workloads
aws rds failover-global-cluster \
    --global-cluster-identifier mydb-global-cluster \
    --target-db-cluster-identifier arn:aws:rds:us-west-2:123456789012:cluster:mydb-aurora-secondary

MENU