Aurora MySQL vs RDS MySQL: The Definitive 2026 Comparison

Last quarter, a Series B SaaS startup came to JusDB with a concrete question: their 2TB MySQL database was outgrowing a single RDS instance, and their infrastructure lead had put two proposals on the table — stay on RDS Multi-AZ at roughly $6,000/month, or migrate to Aurora MySQL at roughly $14,000/month. The $8,000 gap had the engineering team split: the backend lead argued Aurora's automatic storage scaling and sub-30-second failover justified the premium for their 99.95% SLA commitment; the CTO wanted hard numbers before signing off. The right answer depended entirely on their I/O pattern — and that detail changed everything.

Aurora MySQL and RDS MySQL share the same engine but diverge at the storage layer in ways that produce very different cost and performance profiles depending on your workload. This guide breaks down exactly where they differ, what each one costs at realistic workload volumes in us-east-1, and how to make the decision without guessing.

The Core Architecture Difference

The performance and cost characteristics of Aurora vs RDS trace back to a single architectural decision: how storage is implemented.

Aurora: Distributed Storage Cluster

Aurora separates compute from storage entirely. When you write to Aurora MySQL, the database engine sends redo log records (not full data pages) to a fleet of six storage nodes spread across three Availability Zones. Those storage nodes apply the redo logs, maintain their own copies of the data, and replicate among themselves. The compute instance — the one running MySQL — never writes data pages to local disk. It offloads that work to the storage layer.

The practical consequences of this design are significant:

• Storage auto-grows in 10GB increments automatically, up to 128TB — you never provision storage capacity or deal with "storage full" incidents.
• Aurora Replicas (up to 15) share the same underlying storage cluster. There is no replication lag for reads; all replicas read the same storage tier.
• Failover to a replica takes approximately 30 seconds because no data needs to be replicated — the new primary simply takes over the existing storage cluster.
• Each write generates I/O against the storage fleet, and Aurora charges $0.20 per million I/O requests. This is the cost model that surprises most teams.

RDS: EBS-Backed Traditional Architecture

RDS MySQL runs the MySQL engine on EC2 with an attached EBS volume. In Multi-AZ mode, AWS maintains a synchronous standby in a second AZ — full block-level replication, not just redo logs. The standby has its own separate EBS volume that stays current through synchronous mirroring.

Key characteristics of this model:

• Storage must be pre-provisioned. gp3 volumes let you allocate up to 64TB, but you pay for allocated capacity whether you use it or not, and scaling requires a multi-hour storage modification.
• Read replicas require traditional MySQL binlog replication, introducing replication lag (typically 50–500ms, but can spike to minutes under heavy write load).
• Multi-AZ failover requires the standby to be promoted, DNS to propagate, and connections to reconnect — typically 60–120 seconds.
• I/O is included in the storage pricing for gp3. There are no per-request I/O charges.

Performance Comparison

Write Throughput

Aurora MySQL 3.x (MySQL 8.0 compatible) achieves up to 5x higher write throughput than RDS MySQL 8.0 on equivalent instance sizes in AWS benchmarks. This stems from the redo-log-only write path: Aurora avoids the double-write buffer, reduces fsync pressure on the compute instance, and parallelizes writes across the storage fleet. In practice, real-world write throughput gains are closer to 1.5–3x for typical OLTP workloads — meaningful but not transformative for most teams.

Read Scaling

Aurora's shared-storage architecture produces a critical read scaling advantage: Aurora Replicas have zero replication lag for committed data. All replicas read from the same 6-node storage cluster. When your primary writes a row, that row is immediately available to all replicas.

RDS read replicas use MySQL binlog replication. Under sustained write load, replication lag builds — it is not uncommon to see 500ms to several seconds of lag during peak hours. For applications that write and immediately read from a replica, this produces stale reads that require careful application-layer handling.

Failover Speed

This is where the architectures diverge most sharply in operational terms:

• Aurora: ~30 seconds. The replica already has access to all storage data. Promotion is primarily a DNS update and connection reset.
• RDS Multi-AZ: 60–120 seconds. The standby must be promoted, the CNAME for the endpoint must update, and application connection pools must reconnect. In practice, teams see 90–120 seconds for most failures.

For teams with SLAs requiring 99.95% uptime, the 60-second difference in failover time is meaningful: two unexpected failovers per month could consume your entire monthly downtime budget on RDS.

Cost Comparison: The Real Numbers

All pricing below is us-east-1, on-demand, as of early 2025. Reserved instance pricing reduces both platforms by 30–40%; relative differences remain similar.

Instance Costs

Aurora instances cost approximately 20% more than equivalent RDS instances for the same vCPU and RAM. A concrete example using the db.r6g.2xlarge (8 vCPU, 64GB RAM), a common choice for medium-scale production MySQL:

Storage Costs

Aurora storage is slightly cheaper per GB than RDS gp3, but the Aurora billing model charges for both storage and I/O separately:

I/O Costs: The Hidden Cost Driver

Aurora's $0.20/million I/O requests charge accumulates invisibly until your first bill. Every read from the buffer pool that misses and hits storage, every write, and every background flush counts. A moderately busy 8-vCPU Aurora instance running a write-intensive workload can easily generate 500 million to 2 billion I/O requests per month.

Feature Comparison

When to Choose Aurora MySQL

High Availability is Non-Negotiable

If your SLA requires 99.95% or better uptime and you run MySQL in Multi-AZ, Aurora's 30-second failover versus RDS's 90-second failover is a concrete, measurable difference. For applications that cannot tolerate multi-minute outages — fintech transaction processors, e-commerce checkout flows, healthcare scheduling systems — Aurora's storage-level failover architecture is worth the instance cost premium.

Global Applications

Aurora Global Database replicates across regions with a typical recovery point objective (RPO) under 1 second and a recovery time objective (RTO) under 1 minute. RDS does not have an equivalent feature. If you are running MySQL for a globally distributed application with cross-region DR requirements, Aurora Global Database is the only managed MySQL option that meets sub-minute RTO without custom engineering.

Variable Workloads with Aurora Serverless v2

Aurora Serverless v2 scales compute capacity in 0.5 ACU increments (1 ACU ≈ 2GB RAM, ~0.5 vCPU equivalent) with sub-second scaling response. For workloads with significant daily or weekly traffic variation — SaaS products with business-hours usage patterns, reporting databases with nightly batch jobs — Serverless v2 eliminates the choice between over-provisioning for peak and under-provisioning for off-peak.

A practical example: a Serverless v2 cluster configured for 0.5–16 ACU handles a 32x workload swing automatically. The equivalent RDS setup requires either a large instance sitting idle most of the day or manual instance class changes.

Databases Approaching or Exceeding 5TB

RDS storage modifications on large volumes are slow and operationally fragile. Expanding a 5TB gp3 volume requires a multi-hour storage modification that holds your instance in a "modifying" state. Aurora's storage grows automatically in 10GB increments with no maintenance window, no modification downtime, and no pre-planning required. For databases growing aggressively, this operational simplicity has real value.

When to Stick with RDS MySQL

I/O-Intensive Workloads

If your workload generates more than 1–2 billion storage I/O requests per month and you are not on Aurora IO-Optimized, Aurora will cost significantly more than RDS gp3. Analytics workloads, heavy ETL pipelines, write-intensive logging systems, and high-velocity time-series inserts all fall into this category. Measure your I/O volume in CloudWatch before making an architecture decision — the numbers often surprise teams coming from EBS-backed storage.

Cost-Sensitive Early-Stage Products

RDS MySQL on a db.t3.medium runs for roughly $50–70/month with Multi-AZ. The equivalent Aurora configuration costs $120–150/month before I/O charges. For pre-revenue products, early-stage startups, and internal tools, RDS is the right default. Aurora's operational advantages do not pay for themselves at low scale.

Specific Engine Version Requirements

Aurora 3.x is MySQL 8.0 compatible — that is the only option. If your application requires MySQL 5.7 (still common in enterprise environments with specific plugin or stored procedure dependencies), Aurora 2.x reached end-of-life in October 2024. RDS MySQL supports 5.7 with extended support through 2025 and offers MySQL 8.4 for teams ready to move to the LTS release track.

Simple Single-Region, Single-AZ Setups

For development environments, staging databases, or truly non-critical workloads that do not need Multi-AZ, RDS is simpler and cheaper. Aurora requires at minimum a writer instance, and its operational benefits are most relevant in replicated configurations. A single-AZ RDS instance on gp3 is the right choice for these workloads.

Migration: RDS MySQL to Aurora

AWS supports two primary paths for migrating a running RDS MySQL instance to Aurora with minimal downtime:

Option 1: Snapshot Restore (simplest, requires downtime window)

# 1. Take a final manual snapshot of your RDS instance
aws rds create-db-snapshot \
  --db-instance-identifier myapp-prod \
  --db-snapshot-identifier myapp-prod-premigration-snapshot

# 2. Restore the snapshot as an Aurora cluster
aws rds restore-db-cluster-from-snapshot \
  --db-cluster-identifier myapp-aurora \
  --snapshot-identifier myapp-prod-premigration-snapshot \
  --engine aurora-mysql \
  --engine-version 8.0.mysql_aurora.3.05.2

# 3. Create the writer instance in the Aurora cluster
aws rds create-db-instance \
  --db-instance-identifier myapp-aurora-writer \
  --db-cluster-identifier myapp-aurora \
  --db-instance-class db.r6g.2xlarge \
  --engine aurora-mysql

Option 2: AWS DMS Continuous Replication (near-zero downtime)

For production databases that cannot tolerate extended downtime, AWS Database Migration Service (DMS) provides continuous replication from RDS MySQL to Aurora during cutover. DMS performs a full load then switches to CDC (Change Data Capture) mode, keeping the Aurora cluster within seconds of the source RDS instance. Cutover requires only the time to update your application connection strings.

Working with JusDB on AWS Database Architecture

JusDB helps engineering teams choose between Aurora and RDS based on actual workload analysis — not marketing claims. We model your I/O patterns, project costs at scale, and handle migrations with zero downtime if you decide to switch.

Explore JusDB MySQL Services →  |  Talk to a DBA

Related reading:

• AWS RDS MySQL Cost Optimization
• MySQL Architecture Deep Dive
• ProxySQL Load Balancing Guide