Amazon Aurora vs Amazon RDS: Which Managed Relational Database to Pick

Definition

Amazon RDS is AWS's general-purpose managed relational database service. It runs MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Db2 on managed EC2 instances with EBS storage, offering Multi-AZ standby and Read Replicas.

Amazon Aurora is AWS's cloud-native relational engine, wire-compatible with MySQL and PostgreSQL. Aurora replaces the engine's storage layer with a purpose-built, distributed, log-structured storage service that replicates data six ways across three Availability Zones and is shared by up to 15 reader replicas in a cluster.

Aurora and RDS share the same console, parameter groups, IAM model, and Secrets Manager integration, but the architecture underneath is fundamentally different — which is what every exam question on this topic exploits.

How It Works

RDS provisions a DB instance on EC2 and attaches an EBS volume. Multi-AZ creates a second instance in another AZ with synchronous block-level replication; Read Replicas use engine-level asynchronous replication. Storage is per instance — each replica carries a full copy of the data on its own EBS volume.

Aurora decouples compute and storage. The storage tier is a shared, distributed volume that auto-grows in 10 GB segments up to 128 TiB; every 10 GB segment is replicated six ways across three AZs, with writes acknowledged on a quorum of four. The compute tier consists of one writer and up to 15 reader replicas, all reading from and writing to the same storage volume — so replicas don't need their own copy of the data, and replication lag is typically under 10 ms.

This architectural choice drives every comparison point below: durability, failover speed, replica count, replica lag, and Aurora-exclusive features.

Key Features and Limits

Storage

| | RDS | Aurora | | --- | --- | --- | | Model | EBS per instance | Shared distributed storage | | Replication | Single-AZ default; Multi-AZ = 2 copies | 6 copies across 3 AZs always | | Max size | Up to 64–128 TiB (engine-dependent) | 128 TiB auto-growing | | Billing | Provisioned (gp3/io2) | Per GB-month actually used |

Replicas and failover

| | RDS | Aurora | | --- | --- | --- | | Max read replicas | Typically 5 (15 for MySQL 8.0 via cascading) | 15 | | Replication type | Engine-level asynchronous | Storage-shared; sub-10 ms lag | | Failover target | Multi-AZ standby (not queryable) or replica | Any of the 15 replicas | | Typical failover | 60–120 seconds | Seconds to low-tens-of-seconds |

Aurora-exclusive features

• Aurora Global Database — up to five secondary Regions with sub-1-second cross-Region lag; secondary can be promoted in under a minute.
• Backtrack (Aurora MySQL) — rewind the database up to 72 hours in seconds, without restoring from a snapshot.
• Parallel Query (Aurora MySQL) — pushes scan/filter work to the storage layer for analytics queries.
• Cloning — copy-on-write clones in seconds at minimal storage cost; ideal for dev/test.
• Aurora Serverless v2 — 0.5 ACU auto-scaling, sub-second, scale-to-zero supported.
• Aurora I/O-Optimized — bundles I/O into instance cost for I/O-heavy workloads.
• Aurora Zero-ETL to Redshift and RDS Data API — near-real-time warehouse sync and HTTP query access.

Engine coverage

• RDS supports six engines (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2).
• Aurora is MySQL-compatible or PostgreSQL-compatible only. If you need Oracle, SQL Server, MariaDB, or Db2, use RDS.

Common Use Cases

Pick Aurora when…

1. You run MySQL or PostgreSQL and want 3–5× higher throughput on the same instance class.
2. You need 15 low-lag read replicas for heavy read scaling.
3. You want cross-Region DR with sub-second replication via Aurora Global Database.
4. You have intermittent or spiky workloads that benefit from Serverless v2 scale-to-zero.
5. You need rapid clones or Zero-ETL to Redshift or pgvector for AI/ML.

Pick standard RDS when…

1. You need Oracle, SQL Server, MariaDB, or Db2 (Aurora doesn't support them).
2. Cost at small scale matters more than raw performance (Aurora has higher instance minimums).
3. You must match a specific MySQL or PostgreSQL version Aurora doesn't yet support.
4. You're performing a lift-and-shift of an on-prem database that depends on engine-specific features unavailable on Aurora.

Pricing Model

• RDS — per instance-hour (doubled for Multi-AZ), per GB-month of EBS storage (gp3/io2), per provisioned IOPS, backup overages, and data transfer. Reserved Instances up to ~69% off.
• Aurora Standard — per instance-hour, per GB-month stored, plus per million I/O requests. Reserved Instances up to ~60% off.
• Aurora I/O-Optimized — no per-I/O charge; higher instance and storage rates. Choose this when I/O exceeds ~25% of your Aurora bill.
• Aurora Serverless v2 — per ACU-second, plus storage and I/O.

Aurora Global Database adds cross-Region replicated write I/O charges; cross-Region replica instances bill at standard rates.

Pros and Cons

Aurora

Pros: 3–5× performance, 6-way 3-AZ storage, 15 replicas, sub-10 ms replica lag, Global Database, Backtrack, Serverless v2, Zero-ETL, cloning, Parallel Query.

Cons: only MySQL/PostgreSQL compatible; higher per-instance minimums; Standard pricing can surprise I/O-heavy workloads.

Standard RDS

Pros: six engines including commercial databases, cheaper at small scale, simpler pricing, tight parity with upstream engine features.

Cons: EBS per instance means higher-latency replication and bigger failover windows; limited to 5 replicas on most engines; no Global Database or Backtrack.

Comparison with Alternatives

| | Aurora | RDS MySQL/PostgreSQL | RDS Oracle/SQL Server | | --- | --- | --- | --- | | Engines | MySQL-/Postgres-compatible | MySQL/PostgreSQL | Oracle, SQL Server, Db2 | | Storage | Shared 6-way across 3 AZs | EBS per instance | EBS per instance | | Max replicas | 15 | Typically 5 | Varies by engine | | Cross-Region | Global Database (sub-sec) | Cross-Region Read Replica | Engine-dependent | | Serverless | Serverless v2 | None | None | | Best for | High-performance MySQL/Postgres | Engines Aurora doesn't cover | Commercial DB workloads |

Exam Relevance

• Solutions Architect Associate (SAA-C03) — the "6 copies across 3 AZs" Aurora durability story; when Aurora beats RDS; cross-Region DR with Global Database vs Read Replica; Aurora Serverless v2 for intermittent workloads.
• Developer Associate (DVA-C02) — RDS Data API, cloning for test environments, IAM authentication, RDS Proxy with both.
• Database Specialty (DBS-C01) — deep coverage: Backtrack, Parallel Query, I/O-Optimized vs Standard pricing, Aurora Global Database failover, Blue/Green deployments, Zero-ETL to Redshift.

High-frequency exam trap: any question mentioning "six copies" or "three Availability Zones" for storage durability refers to Aurora, not RDS.

Frequently Asked Questions

Q: Is Aurora always the right answer over RDS MySQL or PostgreSQL?

A: Usually, but not always. Aurora wins when you need higher throughput, more replicas, faster failover, Global Database, Serverless v2, Backtrack, or Zero-ETL. Stick with standard RDS MySQL/PostgreSQL when cost at small scale is the priority, when you need a specific engine version Aurora doesn't yet support, when you rely on engine plugins or replication topologies Aurora doesn't expose, or when you simply don't need the distributed storage benefits.

Q: How does Aurora's failover compare to RDS Multi-AZ?

A: RDS Multi-AZ runs a synchronous standby that is not queryable; on primary failure, DNS is updated and failover typically completes in 60–120 seconds. Aurora runs up to 15 read replicas on a shared storage volume; on writer failure, one of the replicas is promoted in seconds, and because it already reads from the same storage, no catch-up or volume switch is needed. Aurora failover is usually noticeably faster and you can also use the replicas to serve read traffic during normal operation.

Q: Can I migrate from RDS MySQL or PostgreSQL to Aurora without downtime?

A: Yes, with minimal downtime. For MySQL you can create an Aurora read replica of an RDS MySQL source, wait for replication to catch up, and promote the Aurora cluster — a cutover measured in minutes. For PostgreSQL, AWS DMS is the common path, or you can use Blue/Green Deployments that build an Aurora staging environment, sync changes, and switch over in under a minute. Major migrations from Oracle or SQL Server to Aurora PostgreSQL use the Schema Conversion Tool (SCT) plus DMS.

---

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