Amazon Aurora Pricing: The I/O-Optimized Crossover and the Serverless v2 ACU Trap

Amazon Aurora is AWS’s flagship cloud-native relational database, available in MySQL and PostgreSQL flavors with several deployment shapes (provisioned, Serverless v2, Global Database, Limitless, DSQL). The pricing reflects that breadth — instance hours, two storage models, optional features each with their own line items, and replication multipliers for multi-region. The right shape for a workload depends on traffic pattern, I/O intensity, and consistency requirements; the wrong shape can land the bill 2–5× higher than necessary.

This post is the bill story. For the broader Aurora-vs-RDS architectural decision, the Aurora Serverless v2 vs provisioned comparison covers the choice within Aurora; the RDS vs Aurora comparison covers when Aurora is the right primitive vs standard RDS.

The Eight Aurora Billing Dimensions

I/O-Optimized vs Standard: The 25% Crossover

Standard Aurora storage bills $0.10/GB-month plus $0.20 per million I/O operations. I/O-Optimized bills $0.225/GB-month with no per-I/O charge — a 125% premium on storage in exchange for unlimited I/O.

The crossover: when I/O costs exceed roughly 25% of your Aurora bill, I/O-Optimized is cheaper.

The audit pattern: check CloudWatch VolumeReadIOPs and VolumeWriteIOPs for your Aurora clusters over the last month, sum to get monthly I/O, multiply by $0.20/M to get the Standard-tier I/O bill, compare against the premium of I/O-Optimized. The decision is per-cluster.

Serverless v2 vs Provisioned: The 4-ACU Break-Even

Serverless v2 bills $0.12 per ACU-hour where 1 ACU represents approximately 2 GB of memory and corresponding CPU/network. The pricing scales linearly: 2 ACU = $0.24/hour, 4 ACU = $0.48/hour, 16 ACU = $1.92/hour.

The break-even with provisioned db.r6g.large at $0.29/hour: roughly 2.4 ACU. Above that, Serverless v2 costs more per hour than provisioned for equivalent capacity.

Global Database: Each Region Is Full Cost

Aurora Global Database replicates a primary cluster to secondary regions with sub-second replication lag. Each secondary region runs its own Aurora cluster — full instance cost, full storage cost. The primary also pays for replicated writes ($0.20 per million writes replicated) and the inter-region data transfer ($0.02/GB).

A 2-region Global Database with db.r6g.xlarge instances effectively doubles the database tier cost — from $423/month to $850+/month for the instances alone. A 3-region setup roughly triples it.

The right use cases:

• Active-active multi-region writes: applications where users in different regions write locally and replicate globally. (For pure active-active write workloads, evaluate Aurora DSQL which is the newer primitive.)
• Sub-second cross-region read locality: serving users in multiple regions with local-latency reads.
• Low-RPO disaster recovery: cross-region failover with under-1-minute RPO.

The wrong use case: standard DR with relaxed RPO. A single-region cluster with cross-region automated snapshots achieves multi-hour RPO at dramatically lower cost.

Backtrack: The Quiet Per-Change-Record Line

Aurora Backtrack (MySQL only) lets you rewind the cluster to a point within the configured retention window (1–72 hours) without restoring from a backup. The cost: $0.012 per million change records stored.

For low-write databases, this is essentially free. For high-write OLTP databases generating hundreds of millions of change records per day, the line item becomes material — a database with 500M change records/day at 72-hour retention bills ~$13/day, ~$390/month for Backtrack alone.

The mitigations:

• Match retention to operational need. 24-hour retention covers “rewind that bad deploy from this morning”; 72-hour retention is rarely operationally useful.
• Evaluate vs PITR. Point-in-Time Recovery from automated backups is free but slower (full restore from snapshot + log replay). For low-frequency rewind use cases, PITR may suffice.

When to Use Each Aurora Shape

A 30-Day Aurora Bill Cleanup Plan

Week 1 — I/O-Optimized evaluation. For each Aurora cluster, calculate the actual I/O volume (CloudWatch VolumeReadIOPs + VolumeWriteIOPs × 30 days). Compare the Standard vs I/O-Optimized cost. Migrate clusters where I/O-Optimized saves money.

Week 2 — Serverless v2 fit audit. Identify clusters on Serverless v2 with sustained ACU consumption above the break-even. Migrate to provisioned. Identify clusters on provisioned with low average utilization — evaluate migration to Serverless v2.

Week 3 — Global Database scope. Review Global Database setups against actual cross-region usage. Where the secondary region is purely DR with relaxed RPO, evaluate replacement with cross-region snapshots.

Week 4 — Backtrack and dev-environment scale-to-zero. Audit Backtrack retention on high-write databases. Configure scale-to-zero on Serverless v2 dev environments to eliminate idle-time cost.

What This Post Doesn’t Cover

• Aurora DSQL pricing in depth — newer serverless distributed SQL primitive with its own pricing model; covered in our database modernization content.
• Aurora performance tuning — relevant to bill (reducing I/O reduces Standard tier cost) but covered in our database operations content.
• Migration from RDS to Aurora — operational migration patterns covered in database migration content.
• Aurora compatibility-mode specifics (MySQL vs PostgreSQL feature differences affecting cost) — covered separately.

If You Only Do One Thing This Week

Calculate I/O volume for your largest Aurora cluster and decide whether I/O-Optimized would be cheaper. Run a CloudWatch query: sum VolumeReadIOPs + VolumeWriteIOPs over 30 days, multiply by $0.20/M. If the result exceeds 25% of your current Aurora bill for that cluster, migrate to I/O-Optimized. The migration is a one-time storage configuration change; the bill drops on day one and the saving compounds indefinitely.

For the broader RDS-vs-Aurora architectural decision, the RDS vs Aurora comparison covers when Aurora’s premium is worth it.