Aurora pricing (what to include): compute, storage, I/O, and backups
Aurora estimates go wrong when teams model only compute. A realistic model includes at least four lines: compute, storage, backups/retention, and a “high-usage” scenario for I/O-heavy or bursty workloads. This page is a practical checklist you can use for a budget, a migration plan, or a “why did our bill spike?” review.
1) Choose the compute model (provisioned vs serverless)
- Provisioned: estimate monthly instance-hours (including writer + readers).
- Serverless: estimate ACU-hours as a baseline plus a peak scenario.
If you use serverless, treat capacity as time-series usage, not a single average. See Aurora Serverless v2 pricing.
2) Add storage GB-month (and model growth)
Storage is usually a steady cost that grows over time. For a first pass, estimate an average GB-month for the month you care about. For planning, build a simple forecast:
- Current size (GB)
- Growth per day/week (GB)
- Retention window (how far back you keep data, if applicable)
Tool: DB storage growth calculator
3) Model backups and retention separately
Backups can become a “quiet baseline” cost, especially with long retention and high churn (frequent updates and large write volumes). Treat backup storage as its own GB-month line item and validate how retention is configured.
Next: estimate backup GB-month and backups and snapshots checklist.
4) Add a high-usage scenario for workload-driven costs
Even when you can’t price every internal detail up front, a second scenario prevents under-budgeting. Use it when you expect one or more of the patterns below.
- Batch jobs that rewrite large tables or run heavy analytical queries
- Hot partitions or skewed keys that cause bursts
- Retry storms from upstream timeouts (incidents multiply usage)
- Large backfills, migrations, or index rebuilds
5) Don’t forget the “around the database” line items
- Read scaling: reader instances (provisioned) or reader capacity (serverless) increases compute.
- Data transfer: cross-AZ traffic and internet egress can show up when apps aren’t co-located.
- Logging/metrics: verbose SQL/audit logs and high-cardinality metrics can be a separate bill.
Helpful context: network transfer costs and reduce logging costs.
Worked estimate template (copy/paste)
- Compute = (writer instances × hours) + (reader instances × hours) or ACU-hours scenarios
- Storage = average GB-month (include forecast if storage is growing)
- Backups = backup GB-month (retention + churn)
- High-usage scenario = peak compute/capacity hours + any known usage multipliers
If you want a single “close enough” number, keep compute as the variable and treat storage/backups as stable baselines.
Common pitfalls
- Modeling only “DB size” and ignoring retention (backup GB-month).
- Using one average for serverless and missing frequent short peaks.
- Assuming storage won’t grow (or forgetting growth from indexes and history tables).
- Ignoring incident windows where retries multiply query volume.
- Missing the “surrounding” bills: load balancers, NAT/egress, logs, and metrics.
How to validate the estimate
- In Cost Explorer / CUR, group by usage type and confirm your compute, storage, and backup lines exist as separate drivers.
- Compare your “high-usage” scenario to real peak windows (deploys, batch jobs, incidents).
- If you’re migrating, run a short parallel period and compare the shape of usage (steady baseline vs peaks), not only a single month total.