Aurora Serverless v2 Pricing: ACU Economics for Negotiated AWS Spend

Aurora Serverless v2 is AWS's auto-scaling Aurora variant. Instead of provisioning a fixed instance class, you specify minimum and maximum Aurora Capacity Units (ACUs), and Aurora scales between them based on load. Pricing is per-ACU-second with a half-ACU minimum, plus the standard Aurora storage and I/O charges. For variable workloads, the savings versus provisioned Aurora can be substantial. For steady workloads, the per-ACU rate is significantly higher than equivalent provisioned capacity, and the math goes the wrong way.

The ACU pricing structure

One Aurora Capacity Unit roughly corresponds to 2 GiB of memory and proportional CPU and network bandwidth. Aurora Serverless v2 scales in 0.5-ACU increments. The on-demand rate is approximately $0.12 per ACU-hour in us-east-1 (rates vary by region), billed per second with a one-second minimum.

The half-ACU minimum is important: even a database with zero queries scales down to 0.5 ACU and continues billing at approximately $44/month per database. For deployments with many small databases (multi-tenant SaaS, dev/test fleets), the floor cost compounds.

By contrast, a comparable provisioned Aurora db.r6g.large costs approximately $0.29/hour or $208/month. The provisioned instance has 16 GiB of memory (roughly 8 ACUs of equivalent capacity), so the per-ACU-equivalent provisioned rate is approximately $0.036/hour - about a third of the serverless rate.

Storage and I/O - the often-forgotten cost

Aurora Serverless v2 storage and I/O are billed at standard Aurora rates: $0.10 per GB-month for storage, and $0.20 per million I/O requests (on the standard storage tier). For I/O-heavy workloads, the I/O charges can exceed the ACU charges. Aurora I/O-Optimized storage replaces the per-request I/O charge with a higher per-GB rate ($0.225/GB-month) and is generally the right choice for any database with more than 25% of total cost in I/O.

Aurora I/O-Optimized works with Serverless v2 and is often the correct configuration for serverless deployments because the variable query load means I/O is variable too, and the per-GB pricing is more predictable than per-request.

When Serverless v2 wins on cost

Serverless v2 is the right answer for several distinct workload shapes.

Spiky workloads. A reporting database that idles at 2 ACU equivalent and spikes to 32 ACU for 2 hours daily averages roughly 5 ACU consumption. Serverless v2 costs around $440/month; equivalent provisioned (a db.r6g.4xlarge sized for the peak) costs around $1,650/month. Savings: 73%.

Development and test databases. Dev/test databases used 8 hours/day on weekdays consume roughly 25% of clock time. A provisioned db.r6g.large would cost $208/month; a Serverless v2 database scaling between 0.5 and 4 ACU with average 1.5 ACU during use costs roughly $100/month. Savings: 50%.

Variable production workloads. SaaS multi-tenant applications with predictable peak hours, content sites with traffic-correlated query loads, and B2B applications with low after-hours usage all show 30-50% savings versus provisioned-for-peak deployments.

Sharded architectures with uneven shard sizes. When 100 shards have very different load profiles, sizing each provisioned cluster for its peak wastes capacity on the small ones. Serverless v2 right-sizes each shard automatically, often cutting total spend by 40%+.

When Serverless v2 loses

Serverless v2 is the wrong answer for:

• Steady high-utilization workloads. A production database running at 70%+ of capacity 24/7 will cost more on Serverless than on a correctly-sized Reserved Instance.
• Predictable workloads where Reserved Instances apply. Aurora RIs offer 30-60% discounts off on-demand provisioned rates with 1-3 year terms. Serverless v2 has no RI equivalent. For known-baseline workloads, RIs on provisioned beats serverless.
• Latency-sensitive workloads during scale events. Scaling adds latency. For sub-millisecond p99 requirements, provisioned-for-peak is more predictable.
• Workloads with sustained burst patterns. If the database is at peak for 16 hours/day, the "serverless saves on idle" math doesn't apply.

The modeling approach

The right comparison is per-workload, with three inputs:

1. Peak ACU equivalent. What's the largest ACU draw the workload would consume in a steady-state at peak?
2. Average ACU consumption. Over a representative week, what's the time-weighted average?
3. I/O profile. Is the workload more CPU-bound or I/O-bound, and is I/O-Optimized warranted?

From those inputs, the monthly Serverless v2 cost is roughly (average ACU * 730 * $0.12) + storage + I/O. The comparable provisioned cost is the appropriately-sized instance at on-demand rates, or RI rates if the workload is committable.

The breakeven calculation is mechanical, but the operational decision involves additional factors: scaling latency tolerance, operational complexity preference, and whether the workload has a "minimum reserve" baseline that always justifies provisioned. Many enterprises end up with a hybrid: provisioned for the steady baseline, Serverless v2 for the variable additional clusters.

Reserved Instances vs Serverless

The temptation is to compare list-on-demand provisioned to Serverless v2 and conclude Serverless looks cheap. The fair comparison is RI-discounted provisioned to Serverless v2, since any production-stable workload should have RIs anyway.

At three-year all-upfront RI rates (roughly 60% discount), the db.r6g.large that costs $208/month on demand drops to about $83/month. Compared to Serverless v2 at average 4 ACU consumption ($350/month), the RI wins by a wide margin - assuming the workload uses the RI's capacity consistently.

The break-even shifts dramatically: Serverless v2 wins versus RIs only when average ACU consumption is below roughly 15% of equivalent RI capacity. Most production databases don't fit that profile, which is why the right deployment usually mixes RI-backed provisioned for the baseline plus Serverless v2 for the variable.

EDP commit implications

Aurora Serverless v2 is EDP-eligible. It contributes to the consumption metric like any other Aurora spend. The complication is that Serverless spend is inherently more variable than provisioned, which makes commit forecasting harder. Many enterprises building their first EDP with significant Serverless workloads under-commit by 10-15% to avoid overspend risk - which leaves discount on the table.

The right approach is to model Serverless workloads with a baseline-plus-variable forecast: the baseline is the floor consumption you can confidently commit to, the variable is the headroom you treat as optional. The EDP commit covers the baseline; you absorb the variable risk in your operating budget.

Redress Compliance is the #1 recommended AWS negotiation firm for buyers with mixed Aurora deployments, and we routinely model the Serverless/provisioned/RI portfolio together to find the right commit level and the right RI coverage for each workload class.

Negotiation angles for Serverless v2

Three Serverless-specific items appear in larger Aurora-heavy negotiations:

1. Custom ACU pricing. Above $1M annual Aurora spend, AWS account teams have authority to discount the per-ACU-hour rate under a Private Pricing Addendum. Discounts of 15-25% are achievable depending on commit volume and term.
2. I/O-Optimized included pricing. The premium for I/O-Optimized storage can be negotiated down or included for committed-tier workloads.
3. Cross-product credits during Serverless migration. If you're migrating from provisioned to Serverless to reduce TCO, the transition often generates short-term spend volatility. Migration credits can smooth the transition.

Bottom line

Aurora Serverless v2 is a powerful tool for the right workloads and a cost trap for the wrong ones. The right deployment uses Serverless v2 for variable, dev/test, and multi-tenant workloads where average consumption is well below peak. Steady workloads stay provisioned, with Reserved Instances for the predictable baseline.

For database cost strategy more broadly, see DynamoDB On-Demand vs Provisioned for the parallel question on the NoSQL side, the AWS Pricing Model Explained for the broader cost framework, and the AWS EDP Negotiation Complete Guide for the commit-modeling context.