Aurora's 21% compute premium is a backup discount

Published October 9, 2026

Aurora charges 21% more for the same database server, and a big enough database earns that back on storage. A db.r6i.xlarge runs $0.480/hr on RDS MySQL and $0.580/hr on Aurora MySQL in us-east-1. Same four vCPUs, same 32 GiB, and $423.40 against $350.40 for a 730-hour month. RDS PostgreSQL sits at $0.500 and Aurora PostgreSQL at $0.580.

Two other line items run the other way. Aurora bills General Purpose storage at $0.100 per GB-month against $0.115 for RDS gp3, and charged backup (the backup you keep beyond a free allowance) at $0.021 against $0.095. That is a 4.5x gap. Keep charged backup at 40% of live data and the savings cover the compute premium once storage passes 1.6 TB.

Think of the premium as a membership fee. You pay an extra $73 a month, and it only pays off if you store enough to use the discount. Below that, RDS is cheaper.

Aurora costs 21% more at every r6i size

Every price below comes from data/processed/rds_pricing.csv, us-east-1, Linux, on-demand, Single-AZ, priced over 730 hours.

The r6i premium is 20.8% at every size, and the absolute gap scales with the instance: $73 a month at xlarge, $146 at 2xlarge, $292 at 4xlarge. On Graviton the premium narrows to 15.7% because Aurora’s r7g rate falls faster than RDS’s. PostgreSQL sits within 4% of MySQL on both engines; license terms move the RDS rate far more than the engine family does, as the RDS license tax works through. Aurora has no general-purpose m-family rows in the CSV because AWS does not sell an m-class Aurora instance, so the comparison has to run on memory-optimized r-series shapes.

Storage and backup are where Aurora gets cheaper

RDS bills the provisioned volume in every Availability Zone, which is why Multi-AZ gp3 is exactly twice the Single-AZ rate. Aurora bills the cluster’s logical data size once, regardless of how many copies exist underneath. The 13% headline is the polite number, because it compares Single-AZ against Single-AZ. Against an HA deployment the same row becomes a 56.5% discount.

Backup pricing has the same structure on both engines: storage up to the size of your database is free, and the charges above apply to backup retained beyond that allowance. The dataset calls these rows ChargedBackupUsage and Aurora:BackupUsage. Because both products define the allowance as one database’s worth of storage, a charged gigabyte is the same quantity on either side, and the two rates compare directly.

One gap in our data affects the $0.100 figure; see What our data doesn’t have below.

Aurora wins above about 1.6 TB, at 40% backup

Write the monthly difference as a function of live storage S and charged backup B, both in GB:

Aurora − RDS = 730 × (C_Aurora − C_RDS) + (0.100 − 0.115) × S + (0.021 − 0.095) × B
             = 730 × ΔC − 0.015 × S − 0.074 × B

Aurora wins when 0.015 × S + 0.074 × B > 730 × ΔC. At db.r6i.xlarge, 730 × 0.100 = $73.00 a month, so:

Storage only, no charged backup:  S > 73.00 / 0.015 = 4,867 GB
With charged backup at 40% of S:  S > 73.00 / (0.015 + 0.4 × 0.074) = 1,637 GB

Three footprints for a single-AZ db.r6i.xlarge, with charged backup at 40% of live storage:

At 1 TB the compute premium survives and RDS is $27 a month cheaper. At 5 TB Aurora is ahead by $150, and at 20 TB by $840. The crossover is 1.6 TB of live data at this backup ratio. Store less than that and the backup gap has to do more of the work.

Solve for the backup volume instead, holding storage fixed:

B > (73.00 − 0.015 × S) / 0.074

The per-vCPU form travels better than any single table. The r6i premium is $0.025 per vCPU-hour, or $18.25 per vCPU-month. Divide by the per-gigabyte gap:

With a standby on both sides, the crossover drops to 915 GB

Aurora has no Multi-AZ compute row in the dataset. It does not need one. The writer instance is billed once and its storage is replicated across three Availability Zones by the storage layer. RDS Multi-AZ bills the standby instance at double the Single-AZ rate, $0.960/hr for db.r6i.xlarge MySQL.

Compare like with like. An RDS Multi-AZ db.r6i.xlarge at $0.960/hr against an Aurora writer plus a reader in a second AZ at $1.160/hr, which is the Aurora construction that gives you a warm compute target to fail over to:

The compute premium is still 20.8%, since both sides doubled. The storage gap is now $0.130 per GB-month rather than $0.015, which moves the crossover from 1,637 GB down to 915 GB at the same 40% backup ratio. An HA pair of db.r6i.xlarge instances running 2 TB of data on Aurora comes out about $181 a month ahead of the RDS equivalent. The same pair at 500 GB loses by about $66. The HA configuration is where the storage and backup rates do most of the work.

I/O charges can flip the answer

Aurora’s standard configuration bills I/O per million requests. That rate is not in rds_pricing.csv, so nothing in the tables above includes it, and no percentage in this post depends on it. The dataset does carry the alternative: Aurora’s I/O-Optimized rates for both instance and storage.

Switching to I/O-Optimized pays off when the per-request charges on the standard configuration exceed the flat premium:

Standard per-request I/O spend > $127.02 + $0.125 × S   per month

At 1 TB that threshold is $255 a month. At 5 TB it is $752. At 20 TB it is $2,687, because the $0.225 storage rate is 2.25x the standard one and storage volume multiplies that penalty. I/O-Optimized is a tool for small, write-heavy databases. On a large dataset it is the most expensive option on the page.

Once you switch, the gap against RDS gp3 widens on both sides: $0.274/hr of compute ($200.02 a month) and $0.110 per GB-month of storage. The crossover with 40% backup moves to 1,433 GB of live data at db.r6i.xlarge. That figure excludes the per-request I/O charge the standard configuration would have billed, which is the whole reason someone makes the switch. Heavy I/O can still push Aurora’s standard configuration above the RDS bill at any storage size, because RDS bounds I/O spend with provisioned IOPS (our data carries gp3 additional IOPS at $0.020 per IOPS-month, Single-AZ) while Aurora’s per-request mode has no ceiling.

What the storage rate buys

These are AWS product facts, not rows in our CSV. Aurora keeps six copies of the data across three Availability Zones and needs four of six to acknowledge a write and three of six to serve a read. You are billed for the logical size, not for the six copies. That is why $0.100 per GB-month buys sixfold replication on Aurora while $0.115 on RDS buys a single volume and $0.230 buys the Multi-AZ pair. Aurora also streams changes to S3 continuously for point-in-time restore and grows storage automatically as data arrives.

On compute, Aurora supports up to 15 read replicas on shared storage, with replica lag AWS describes as typically under 100 ms, and promotes a reader on failover typically in under 30 seconds against the 60 to 120 seconds AWS documents for RDS Multi-AZ. Those figures are vendor claims, measured on AWS’s hardware, not something this dataset can confirm.

What our data doesn’t have

• An Aurora MySQL storage row for us-east-1. The CSV has no General Purpose-Aurora row there, so the $0.100 above is the Aurora PostgreSQL rate. Aurora MySQL carries the row in seven other regions, and in all seven it matches PostgreSQL to the cent (both $0.190 in sa-east-1, both $0.120 in ap-northeast-3). Whether AWS stopped publishing the Virginia row or our conversion dropped it, treat $0.100 as verified for Aurora PostgreSQL and strongly implied, not directly observed, for Aurora MySQL.
• Serverless v2. rds_pricing.csv has no ACU rows for either engine, so a choice between provisioned and Serverless v2 runs on a rate table this post cannot price.
• Reserved pricing, for either engine. A commitment cuts compute and leaves storage and backup at list. If Aurora’s reservation discount is shallower than RDS’s, the breakeven shifts toward RDS. Pull that number from your own quote before you commit.

What to do

1. Start from charged backup, not snapshot size. Pull the ChargedBackupUsage cost line for your database from Cost Explorer or CUR. The free allowance is one database’s worth of backup on both engines, so the line is already net of it.
2. Convert to per-vCPU terms. At r6i rates the Aurora compute premium is $18.25 per vCPU-month. Divide by the storage gap: 1,217 GB per vCPU with no charged backup, 409 GB at 40% backup, 205 GB at 100%.
3. If you run a single instance with no standby, RDS is cheaper below those thresholds: 1,217 GB per vCPU with no charged backup, 409 GB at 40%. A small database with large backups is the main case where Aurora still wins (at 1 TB, charged backup has to reach 779 GB, or 76% of live data).
4. If you run Multi-AZ, use the $0.130 per GB-month gap against a writer-plus-reader Aurora pair. The threshold drops to 229 GB per vCPU at 40% backup, which is small enough that most HA deployments clear it.
5. Price the I/O configuration before the engine. If per-request I/O on the standard setup would exceed $127 plus $0.125 per GB of storage monthly, I/O-Optimized changes the arithmetic by more than the engine choice does, and its $0.225 storage rate makes Aurora expensive at large storage sizes.
6. Check Graviton. The r7g premium is 15.7% against r6i’s 20.8%, which shrinks every breakeven in this post by about a quarter.

The database comparison page prices both engines side by side, and the Aurora and RDS indexes carry the full regional tables these numbers come from.