Aurora Serverless v2 vs Provisioned: Pricing Structure and When to Use Which
After deciding on Aurora, the next question is the capacity model: provisioned, where you pick an instance size, or Serverless v2, where capacity follows the load. The conclusion up front: workloads with long idle stretches or unpredictable load (dev/test, new services, spiky traffic) go to Serverless v2; production with steady, constant load goes to provisioned plus a commitment. At sustained high load, Serverless v2’s hourly rate runs more than double the equivalent provisioned instance, so the decision rides on utilization, not on the word serverless. Whether to use Aurora at all is covered in Aurora vs RDS. Prices are for us-east-1.
Side-by-side comparison #
| Aspect | Serverless v2 | Provisioned |
|---|---|---|
| Billing unit | ACU-hour (~$0.12, standard config) | Instance-hour |
| Capacity adjustment | Automatic, per second (0.5 ACU steps) | Manual (instance class change) |
| Minimum capacity | 0 ACU (auto-pause available) | Instance always on |
| Idle cost | Approaches 0 (storage only) | Instance charges continue |
| Commitments | Database Savings Plans (up to ~35%) | RI and Database SP (up to tens of %) |
| Sustained high-load rate | 2x+ provisioned | Baseline |
| Spike response | Automatic within seconds | Manual (restart or failover involved) |
ACU billing: you pay for what is held, not what is used #
Serverless v2 bills in ACUs (Aurora Capacity Units). One ACU is roughly 2GiB of memory with matching CPU and network, at about $0.12 per ACU-hour on the standard configuration. Set a minimum and maximum on the cluster and capacity moves between them in 0.5 ACU steps, second by second.
The catch is that billing follows the ACUs currently held, not the queries actually run. A warm buffer pool can keep ACUs from dropping to the floor even when idle, which is the first reason bills come out higher than expected. A generous minimum setting is the more direct version of the same problem: a cluster floored at 8 ACUs bills about $0.96 an hour, roughly $700 a month, regardless of load. At that point Serverless v2 is a fixed-cost instance with auto-scaling attached, and the cost advantage is gone.
The 0 ACU setting is the opposite end. With the minimum at zero, the cluster auto-pauses after connections drain and a set period passes; compute drops to zero and only storage bills. Resuming on the next connection takes a dozen or so seconds. For dev/test databases that sit empty at night, this is simply the answer; for user-facing services it fits only when the first-request delay is acceptable.
Break-even: run the utilization math #
Compare like for like and the structure shows. A db.r6g.large with 16GiB (about $190 a month on-demand) against 8 ACUs held constantly (about $700 a month): Serverless v2 costs the same only if it runs at 8 ACUs about 6.5 hours a day and near zero the rest. As a rule of thumb, average utilization around 25–30% is the boundary, and commitments on the provisioned side push it lower. A database under real load more than a third of the day belongs on provisioned; an internal system busy only during office hours, or a service still small, belongs on Serverless v2.
Commitments exist on both sides. Provisioned instances take RIs; Serverless v2 takes Database Savings Plans, up to about 35% off on a 1-year commitment. A Serverless v2 cluster with a steady floor of load can commit just that floor. The general rules are in RI vs Savings Plans.
Storage and I/O bill identically under both models: about $0.10 per GB-month plus $0.20 per million I/Os on the standard configuration, with the I/O-Optimized configuration (higher compute and storage rates, no I/O charges) taking over when I/O dominates. The working rule: when the I/O line exceeds about 25% of compute on the bill, price out I/O-Optimized.
Hybrid: writer and readers on different models #
The most useful fact in practice is that one cluster can mix provisioned and Serverless v2 instances. The typical setup: a provisioned writer carrying the base load (with an RI), plus Serverless v2 readers that follow traffic. For services with predictable writes and fluctuating reads, the fixed cost is locked in cheap and only the variable part bills by ACU. In the other direction, during a migration, attaching a Serverless v2 reader first to collect a real ACU curve before committing the main model is the safe sequence.
Decision order #
- Start from the load curve: look at the daily CPU and connection-count pattern in CloudWatch. Long idle stretches point to Serverless v2; a constant plateau points to provisioned.
- Dev/test goes to 0 ACU, decided: auto-pause erases nights-and-weekends compute, and the dozen-second resume does not matter there.
- For steady load, compare against provisioned plus commitments: average ACU × $0.12 × 730 hours, next to the instance price. Above roughly 30% utilization, provisioned usually wins.
- Do not raise the ACU floor beyond need: every step up is fixed cost. If cold-buffer first-query latency is the concern, tune the floor around 1–2 ACUs and adjust from measurements.
- Solve read scaling with the hybrid: provisioned writer plus Serverless v2 readers optimizes the fixed and variable parts separately.
Summary #
- Serverless v2 bills about $0.12 per ACU-hour on held capacity. With long idle time it is dramatically cheaper; at sustained high load it costs more than double provisioned.
- Scale-to-zero auto-pause made Serverless v2 the plain answer for dev/test databases, at the price of a dozen-second resume.
- The boundary is around 25–30% average utilization: above it, provisioned plus RI; below it, Serverless v2, with Database SP as the serverless-side commitment.
- Raising the minimum ACU converts serverless into fixed cost. Set the floor from measured curves, not comfort.
- A provisioned writer with Serverless v2 readers is often the practical answer, pricing predictable writes and fluctuating reads each at their best.