Aurora vs RDS: The Structural Difference and When to Switch

Infrastructure AWS Cost
5 min read

The first fork in the RDS console is not MySQL versus PostgreSQL — it is standard RDS versus Aurora. Both are managed and both speak the same protocols, so it looks like a tier choice, but they are separate products with different storage architectures. The conclusion up front: small, steady workloads are cheaper on standard RDS; move to Aurora when measurements show demand for read scaling, availability, or spiky load. Instance class selection is covered in RDS Instance Classes Compared; this post is the decision that comes before it. Prices are for us-east-1.

The structure differs: a storage service, not a disk #

Standard RDS attaches an EBS volume to the instance. You size it in advance, Multi-AZ adds a second copy on the standby, and each read replica writes its own copy to its own storage.

Aurora separates compute from storage. Data lives in a shared storage layer replicated six ways across three AZs, and instances attach on top. The differences cascade from there.

  • Up to 15 read replicas read the same storage, so replication lag is measured in milliseconds. Standard RDS replicas use logical replication, where lag can stretch to seconds.
  • Failover is fast. Replicas already see the same data, so promotion usually completes within 30 seconds. Standard RDS Multi-AZ runs one to two minutes.
  • Storage grows on its own. No pre-sizing, billing by usage, with the ceiling now at 256TiB. One whole category of operational incident — “the disk filled up” — disappears.
  • Extras come out of the same storage layer: fast cloning (a writable copy of the cluster in minutes, no snapshot restore) and Backtrack on the MySQL-compatible edition (rewinding the cluster in place without a restore).

Pricing: an instance premium plus storage and I/O #

Aurora bills in three layers.

  • Instances: hourly rates around 20% above standard RDS for the same class.
  • Storage: about $0.10 per GB-month on the default configuration (Aurora Standard) — comparable to standard RDS on gp3 (about $0.115/GB-month; see the storage criteria) — but you pay only for what you use.
  • I/O: the variable. Aurora Standard charges about $0.20 per million I/O requests. On cache-friendly workloads it is negligible; on write- and scan-heavy ones it can exceed the instance charge. This line item growing on the bill is the classic way Aurora costs escape prediction.

Hence the I/O-Optimized configuration: I/O charges disappear, in exchange for instance rates about 30% higher and storage at about $0.225 per GB-month. The threshold is explicit: when I/O exceeds 25% of your total Aurora spend, I/O-Optimized is cheaper. It can be switched per cluster, so start on Standard and decide from the I/O share on the bill.

Serverless v2: the answer for spiky load #

Aurora offers Serverless v2, billed per second in capacity units (ACUs) instead of instance classes — about $0.12 per ACU-hour (about $0.156 on I/O-Optimized) — scaling up and down within seconds of load changes. Set minimum capacity to 0 and an idle cluster auto-pauses, dropping compute charges to zero. Internal tools that sleep at night, development and staging environments, and new services with unpredictable traffic are the targets.

The math still matters. At sustained load, ACU rates cost more than an equivalent provisioned instance, so services with a stable base load are cheaper on provisioned capacity plus replicas as needed. Serverless v2 saves money only under the condition “load swings hard or spends long stretches at zero.”

Where standard RDS remains the right answer #

  • Small, steady workloads: a service that runs fine on db.t4g.micro (around $12 a month) has no reason to carry an Aurora premium. The same goes for dev and staging (though 0-ACU Serverless v2 competes here).
  • Other engines: Aurora comes only in MySQL- and PostgreSQL-compatible editions. MariaDB, Oracle, and SQL Server mean standard RDS, full stop.
  • Specific version or extension requirements: Aurora is compatible, not identical. If you need a particular community minor version, certain extensions, or storage engines like MyISAM, standard RDS it is.
  • Price predictability: if a fixed configuration with no I/O metering comes first, standard RDS plus gp3 is the simple answer.

Conversely — you keep adding read replicas, failover time presses against an SLA, storage resizing has become a recurring chore, or a measured I/O bottleneck (see the buffer-pool test) will not yield to a bigger class — that is the moment to evaluate Aurora.

Migration practice: promote an Aurora read replica #

From standard RDS MySQL or PostgreSQL, the standard path is to create an Aurora read replica, let replication catch up, then promote it. The interruption is shorter than a snapshot restore, and you get to validate Aurora’s performance against replicated production load before committing. Before promoting, split the application’s connection strings into the cluster endpoint (writes) and the reader endpoint (reads) — replica scaling afterward then requires no code changes. General connection and migration practice is covered in AWS in Practice #2.

Summary #

  • Aurora is a structurally different product, not a tier. The shared six-way, three-AZ storage layer yields 15 replicas, 30-second failover, and 256TiB auto-scaling.
  • Pricing is three layers: an instance premium (around 20%) plus storage plus I/O. Switch to I/O-Optimized when I/O passes 25% of spend.
  • Serverless v2 bills per ACU-second and pauses at 0 ACUs. It saves money only on spiky or long-idle load.
  • Small steady workloads, non-MySQL/PG engines, specific version or extension needs, and price predictability all point to standard RDS.
  • Migrate by promoting an Aurora read replica, and split cluster/reader endpoints before you do.
X