All cheat sheets
Databasescheat sheet

Aurora I/O-Optimized

Aurora bills a sneaky third bucket — I/O operations at ~$0.20/million — that can dwarf compute and storage on I/O-heavy workloads. I/O-Optimized zeroes it out for a ~30–40% higher instance rate. A break-even calc, not a default.

Last reviewed: July 14, 2026

Prefer step by step? Take the guided Aurora I/O-Optimized walkthrough — free, anonymous, interactive.Have an AI assistant? Jump to the copy-paste audit prompt at the bottom of this sheet.

TL;DR: Aurora pricing has three buckets, not two: instances, storage, and I/O operations (~$0.20 per million 8 KB page ops). On write-heavy OLTP or scan-heavy analytics, I/O can exceed compute and storage combined. I/O-Optimized (May 2023) makes I/O free in exchange for a ~30–40% higher instance rate. It's pricing insurance — a 50–80% cut on I/O-heavy clusters and a ~20–30% increase on light ones. The break-even math is the whole decision.

The numbers

  • Standard Aurora, heavy-I/O example: instance ~$210 + storage ~$200 + I/O ~$3,000 = ~$3,410/mo (I/O is 88%).
  • Same workload, I/O-Optimized: instance ~$294 (+40%) + storage $200 + I/O $0 = ~$494/mo — an 85% cut.
  • The flip side: a small CRUD app with $12/mo of I/O pays ~$48 more under I/O-Optimized, because the instance markup exceeds the I/O it eliminates.
  • Break-even rule of thumb: I/O > ~30–40% of instance cost → likely a win; under ~15% → it costs more.
  • Field examples: a fintech payment log went $10,200 → ~$2,180/mo (78% off, I/O was 83%); a B2B analytics platform went $5,350 → $1,490/mo (72%).

Do this

  1. Measure the I/O ratio first — Cost Explorer filtered to Aurora, "Database I/O" line ÷ instance cost.
  2. Project both totals: current instance × 1.4 + storage, versus current (instance + storage + I/O). Pick the smaller number.
  3. Corroborate with CloudWatch VolumeReadIOPs / VolumeWriteIOPs — high and consistent means a strong candidate.
  4. Test on a clone — restore a snapshot to a fresh cluster, flip that to I/O-Optimized, compare bills for a week.
  5. Switch in a maintenance window (the mode flip can trigger a brief failover) and wire up Cost Anomaly Detection so a future I/O spike pages you before the bill closes.

Gotchas

  • The switch has a cooldown — a minimum window before you can revert to Standard; don't flip-flop, plan the test.
  • It's cluster-wide — you can't run the writer on I/O-Optimized and replicas on Standard; the whole cluster moves together.
  • Serverless v1 didn't support it (v2 has since late 2023 — verify your version against current AWS docs).
  • Only the runtime I/O meter changes — snapshot storage and backup retention bill the same.
  • Re-measure periodically — the right mode shifts as the workload evolves.

Skip this if

  • Your I/O is under ~15% of instance cost (small CRUD apps, lightly-queried read replicas) — Standard on a right-sized, reserved instance is cheaper.
  • Your goal is scaling compute down between bursts rather than capping I/O — look at Aurora Serverless Sizing.
  • You want to shave the always-on baseline instead — reserved DB instance capacity targets the compute line, and stacks with either storage mode.

Run this audit with your AI assistant

Paste this into Claude, ChatGPT, or any agent that can run the AWS CLI with read-only credentials. It audits your account for exactly the waste this sheet describes — and changes nothing.

You are auditing an AWS account's Aurora clusters to decide between
Standard and I/O-Optimized storage configurations. Use the AWS CLI with
READ-ONLY credentials. Do not create, modify, or delete anything —
report findings and recommended (unapplied) fixes only.

1. Inventory: aws rds describe-db-clusters — capture each cluster's
   StorageType (aurora vs aurora-iopt1), engine/version, instance
   classes, and instance count.
2. Cost decomposition: from Cost Explorer (or CUR) split each cluster's
   spend into instance, storage, and "Database I/O" lines. Compute the
   I/O share = I/O$ / (instance$ + storage$ + I/O$).
3. Break-even rule: if I/O charges exceed ~30-40% of instance cost,
   I/O-Optimized (instance × ~1.4, I/O = $0) likely wins; under ~15% it
   COSTS more. Show projected I/O-Optimized total vs current total per
   cluster.
4. Corroborate with CloudWatch VolumeReadIOPs / VolumeWriteIOPs (high +
   consistent = strong candidate). Note Serverless v1 lacks support and
   the mode-switch cooldown.

Report a table: cluster | instance$/mo | storage$/mo | I/O$/mo | I/O
share % | recommended mode | est. $/mo delta. Recommend testing on a
restored snapshot clone before switching. Change nothing.
Works with any assistant that can run shell commands.

Want the guided version?

The Aurora I/O-Optimized walkthrough covers this topic interactively — it asks about your setup, branches to what’s relevant, and quizzes you on the tricky parts. Free and anonymous.

Start the walkthrough

More Databases cheat sheets

Amazon RDS Proxy

Connection count, not CPU, is often what forces an RDS upsize. RDS Proxy pools thousands of client connections (especially from Lambda) onto ~10–30 real ones, so a small instance stays small — the proxy fee typically covers 10–25% of the avoided upsize.

Athena Partition Projection

Instead of asking S3 which partitions exist before every query, Partition Projection lets Athena calculate the paths from a pattern you declare — near-instant query startup on tables with thousands of partitions, zero LIST metadata calls.

Athena Query Result Reuse

Athena caches identical query results in S3, so a repeated dashboard refresh or scheduled report returns instantly with zero bytes scanned. A workgroup checkbox that routinely cuts thousands off a scan-heavy bill.

Aurora Serverless Sizing

Aurora Serverless replaces a fixed instance size with an ACU capacity range that auto-scales — and in v2 pauses to zero compute when idle. Dev/test, bursty, and multi-tenant databases save up to 80%; steady 24/7 high-CPU workloads are cheaper provisioned.