Aurora Serverless v2

Scale Aurora capacity automatically based on workload demand to avoid paying for idle compute during low-traffic periods.

Why it matters

Aurora Serverless v2 automatically scales database capacity up or down based on demand, measured in Aurora Capacity Units (ACUs). You pay only for the ACUs consumed per second, so workloads with variable traffic—spiky usage, development environments, infrequent batch jobs—can avoid paying for idle provisioned instances.1

Important: Serverless v2 requires thorough cost modeling and testing. For steady, predictable traffic, it’s stupidly more expensive than provisioned instances with Reserved Instance pricing. Only consider serverless if your workload truly has variable demand; otherwise, provisioned capacity will be cheaper.

When it helps

Aurora Serverless v2 is most likely to be a good fit when:

  • Traffic is highly variable or bursty – APIs or multi-tenant clusters where load swings dramatically and you would otherwise spend most of the day at low utilization.
  • Environments are not 24×7 critical – Dev, staging, demo, or sandbox clusters that see sporadic use but still need to be “on” without manual resizing.
  • Infrequent batch or event-driven workloads – Jobs that run periodically (for example, once a day or week) and are mostly idle otherwise, where modeling ACU usage is simpler than scheduling stop/start.

If your workload has a clear, stable baseline and runs all the time, treat Serverless v2 as the exception—not the default.

Limitations

  • Minimum capacity cost – Even at 0.5 ACU minimum, you’re paying for that baseline 24×7 unless you delete the cluster.
  • No instance family choice – You can’t select specific instance families (e.g., r7g, t4g) like with provisioned RDS; ACUs are a fixed compute abstraction.
  • No Savings Plans or Reserved Instances – Serverless v2 capacity isn’t eligible for RDS Reserved Instances or Savings Plans, so you miss out on commitment-based discounts available with provisioned instances.
  • Scaling granularity – ACU increments are fixed; you can’t fine-tune capacity as precisely as choosing a specific instance size.

Scaling

It scales instantly… right?

From AWS documentation:

The scaling rate for an Aurora Serverless v2 DB instance depends on its current capacity. The higher the current capacity, the faster it can scale up. If you need the DB instance to quickly scale up to a very high capacity, consider setting the minimum capacity to a value where the scaling rate meets your requirement.

This means that for really spiky connection patterns you may need to overprovision slightly so Serverless v2 has enough headroom to scale in time. How much to overprovision depends on your workload—you’ll need to run load tests for your specific traffic profile and use those results to pick safe minimums.

Practical approach

  1. Start from an existing workload – Don’t design Serverless v2 in a vacuum; pick a candidate cluster and look at its historical CPU, connections, and throughput patterns to confirm that demand is truly variable.
  2. Roughly model ACU needs – Use Aurora documentation and your current instance sizes to estimate a sensible ACU range, then compare modeled Serverless v2 costs against provisioned instances with appropriate RIs.
  3. Pilot in non-production – Enable Serverless v2 on a lower-risk environment first, validate scaling behavior and query latency under load, and watch the cost line in Cost Explorer over a few billing cycles.
  4. Decide explicitly – After the pilot, either promote the pattern (and document when to use it) or revert to provisioned capacity; avoid leaving “accidental” Serverless v2 clusters running long term.
  • Stop instances when not in use – For non-Aurora workloads with predictable off-hours, stopping instances can be simpler and cheaper than serverless pricing.
  • Reserved Instances – For predictable 24×7 Aurora workloads, provisioned instances with RIs will typically be much cheaper than Serverless v2.

Resources

Footnotes

  1. Amazon Aurora Serverless v2 ↩