Aurora Serverless v2 Pricing: ACU-Hours, Minimum Capacity, Peaks, and Storage
Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.
This is the Aurora Serverless v2 capacity-shape page. Stay here when the pricing question is how ACU-hours expand across baseline and peak windows rather than how the whole Aurora bill is structured.
Go back to the database parent page if the broader database budget shape is still unclear, and go back to the Aurora bill anatomy page if the broader Aurora bill structure is still unclear.
Aurora Serverless v2 is priced primarily by ACU-hours, and the first budgeting decision is whether Aurora Serverless v2 spend is mostly a minimum-capacity baseline problem or a repeated peak-window problem. You should estimate it like a time-series bill: a baseline most hours, plus peaks that happen during batch jobs, traffic spikes, or incidents. If you budget from a single average ACU, you usually under-estimate.
Quick pricing read
Aurora Serverless v2 pricing is not just "serverless database, pay when busy." The compute bill is built from ACU-hours over time, and the real shape depends on minimum-capacity baseline exposure versus repeated peak-window expansion. Each ACU represents roughly 2 GiB of memory with associated CPU and networking, so the minimum and maximum range you configure changes both your performance posture and your billing posture. Storage and backups stay as neighboring cost surfaces even when compute is elastic.
- ACU-hours are the core compute surface: Serverless v2 charges follow actual ACU capacity over time rather than a fixed instance-hour model.
- Minimum-capacity baseline matters: the minimum ACU setting often behaves like a quiet monthly floor, and newer engine versions can allow 0 ACUs with automatic pause while many environments still effectively budget around 0.5 ACUs or higher.
- Peak windows create the second bill shape: backfills, deploy storms, analytics bursts, and incident retries can add repeated ACU-hour spikes even when the baseline looks calm.
- Storage and backups are still separate surfaces: Aurora Serverless v2 does not make storage or backup retention disappear just because compute scales elastically.
- Keep neighboring costs beside the Serverless v2 bill: broader Aurora bill anatomy, database parent budgeting, and application costs such as retry storms or external transfer should stay beside this page unless they are directly shaping ACU-hours.
This page was updated on 2026-06-18 against the current Aurora pricing page, Aurora Serverless v2 capacity-range documentation, and Aurora scaling guidance.
Inside the Serverless v2 bill vs beside the Serverless v2 bill
- Inside the Serverless v2 bill: ACU-hours, minimum-capacity baseline exposure, peak-window compute expansion, storage, and backup retention tied directly to the Aurora cluster.
- Beside the Serverless v2 bill: broader Aurora bill-structure questions, database parent budgeting decisions, logs, metrics, application costs, and transfer paths that are not directly part of ACU-hour compute shape.
- Why this matters: a team can tune ACU ranges correctly and still create a large adjacent bill through application retries, logging, or database-adjacent workflows that do not belong inside the Serverless v2 compute model.
Step 1: pick baseline and peak scenarios (don’t start with one number)
Write down two scenarios you can defend:
- Baseline: typical ACUs during steady operation (most hours).
- Peak: ACUs during known heavy windows (backfills, reports, spikes, deploy storms).
If you know your configured min/max, baseline is often close to min, and peak should be bounded by max (or your expected upper range).
Step 2: estimate ACU-hours
ACU-hours is just “capacity × time”. For a planning model:
- Baseline ACU-hours = baseline ACU × baseline hours/month
- Peak ACU-hours = peak ACU × peak hours/month
- Total = baseline ACU-hours + peak ACU-hours
Worked example: baseline 2 ACU always-on → 2 × 730 = 1,460 ACU-hours. Peak 8 ACU for 2 hours/day → 8 × 60 = 480 ACU-hours. Total ≈ 1,940 ACU-hours/month.
Step 3: add storage and backup retention as stable baselines
- Storage: average GB-month (and forecast if the database is growing).
- Backups: backup GB-month driven by retention and churn.
Tools and follow-ups: storage growth and estimate backup GB-month.
Step 4: stress-test your budget (the “what if it happens weekly?” test)
The best guardrail is to ask: what if the peak window happens every day or every week? If your estimate can’t absorb that, you’ll get surprised by routine operational events (deploys, backfills, retries).
- Backfills and migrations (data reshaping or index builds)
- Report generation and analytics queries
- Upstream incidents that cause retries and timeouts
- Seasonal traffic spikes and product launches
Common pitfalls
- Assuming serverless means “auto-pauses to zero” (v2 is not the same as older models).
- Using a short load test and extrapolating to a month without modeling peaks.
- Ignoring retention: backups can become a steady cost even if compute is perfect.
- Budgeting from max capacity only (overestimates) or average only (underestimates) instead of scenarios.
- Missing “around the DB” costs: logs, metrics, and transfer when apps aren’t co-located.
How to validate after you go live
- In CUR / Cost Explorer, identify the ACU-hours usage line and compare baseline vs peak months.
- Compare the time shape in metrics to billing: do peaks happen daily, weekly, or only during incidents?
- After tuning min/max, re-check that latency and failover behavior still meet requirements.
Related guides and calculators
Sources
- Amazon Aurora pricing (includes Serverless v2)
- Aurora Serverless v2 capacity range requirements
- Aurora Serverless v2 scaling and capacity guidance