RDS vs Aurora in AWS

What Aurora actually is

Standard RDS runs a conventional database engine (MySQL, PostgreSQL, MariaDB, Oracle, or SQL Server) on EC2 instances with EBS storage. Multi-AZ RDS maintains a synchronous standby replica in a second AZ — if the primary fails, RDS promotes the standby. This typically takes 60–120 seconds.

Aurora is different. AWS rebuilt the storage layer as a distributed, fault-tolerant system that spans 6 copies of your data across 3 Availability Zones automatically. The compute layer (the database engine) is separated from the storage layer. What this means:

• Faster failover — when the primary fails, Aurora promotes a read replica to primary in ~30 seconds. There’s no data loss because storage is shared across all instances.
• More read replicas — up to 15 read replicas vs 5 for RDS, all using the same shared storage (no replication lag between storage copies).
• No storage provisioning — Aurora storage grows automatically in 10GB increments up to 128TB. You don’t provision storage upfront and run out.
• Faster writes — Aurora’s storage layer processes writes more efficiently, particularly for I/O-heavy workloads.

Aurora is wire-compatible with MySQL and PostgreSQL — your application connects to it with the same driver and the same SQL. You don’t rewrite code to use Aurora.

RDS Multi-AZ vs Aurora comparison

When standard RDS is the right choice

Development, staging, and test environments. Aurora’s premium isn’t worth it for non-production databases. An RDS db.t3.micro or db.t3.small is perfectly fine for development. Aurora doesn’t have micro instances — the minimum Aurora configuration costs more than a comparable RDS instance.

Budget-sensitive production workloads with relaxed availability requirements. If a 60–120 second failover is acceptable — for an internal application, a staging environment used by a small team, or a low-criticality service — RDS Multi-AZ provides adequate availability at a lower cost.

Engines Aurora doesn’t support. Aurora is only available for MySQL and PostgreSQL compatibility. If you need Oracle, SQL Server, MariaDB, or a specific MySQL/PostgreSQL major version that Aurora doesn’t yet support, RDS is your option.

Simple workloads where Aurora’s architecture provides no benefit. A small write-light application with a single writer and no read replicas gets minimal benefit from Aurora’s distributed storage layer. The 20% premium doesn’t pay for itself.

When Aurora is worth the premium

Production databases with high availability requirements. If a database outage lasting 60–120 seconds is unacceptable for your application — e-commerce, financial services, customer-facing APIs — Aurora’s ~30 second failover and automatic replica promotion is meaningful. The difference between 1 minute and 2 minutes of downtime during a failover may matter to your SLA.

Read-heavy workloads that need to scale reads. Aurora’s 15 read replicas (vs RDS’s 5) and near-zero replication lag make it significantly better for read scaling. A reporting application, a product catalog, or a read-heavy API that needs to distribute load across multiple replicas benefits from Aurora’s replica model.

Aurora Serverless for unpredictable traffic. Aurora Serverless v2 scales compute up and down in fine-grained increments (0.5 ACU increments) based on actual database load. For workloads with highly variable traffic — batch processing windows, overnight jobs, development databases that are idle most of the time — Aurora Serverless can significantly reduce costs compared to a fixed-size RDS instance running 24/7.

Multi-region architectures. Aurora Global Database replicates to up to 5 secondary regions with typically under 1 second replication lag, with the ability to promote a secondary region to primary in under a minute during a regional outage. RDS cross-region replicas have higher lag and are read-only. For genuinely global applications requiring regional failover, Aurora Global Database is the right solution.

High write throughput. Aurora’s storage layer handles I/O more efficiently than standard RDS EBS-backed storage, particularly for write-heavy workloads. If your database is consistently I/O-bound on RDS, migrating to Aurora often improves throughput without changing instance size.

Aurora Serverless: the special case

Aurora Serverless v2 is worth understanding separately. It’s Aurora with automatic compute scaling — you configure a minimum and maximum capacity (in Aurora Capacity Units), and Aurora scales between them based on load. You pay per ACU per second while running.

This makes Aurora Serverless compelling for:

• Development databases — scale to zero (or near zero) when not in use, avoiding 24/7 instance costs
• Workloads with daily traffic patterns — a database that’s busy from 9am to 5pm and nearly idle overnight can scale down at night and save significantly
• Unpredictable spikes — Aurora Serverless scales up within seconds when traffic spikes, without manual intervention

Aurora Serverless v2 has no minimum instance equivalent — it can scale as low as 0.5 ACU. The practical minimum cost is much lower than a standard Aurora instance.

Note that Aurora Serverless v2 does not scale to complete zero — it maintains at least 0.5 ACU (approximately $0.06/hour). For true zero-cost idle periods, you need to pause the cluster (available in some configurations).