Aurora Serverless Sizing

TL;DR: Instead of picking a fixed instance size, Aurora Serverless sets a capacity range in ACUs (Aurora Capacity Units ≈ 2 GB memory + compute) and auto-scales within it. v2 scales smoothly in 0.5-ACU steps in seconds without pausing connections and has full feature parity (read replicas, Multi-AZ, global databases). When activity hits zero it can pause to zero compute (you pay only storage), waking in ~25 seconds. Idle, bursty, and multi-tenant databases save up to 80–90%; steady 24/7 high-CPU workloads stay cheaper on provisioned.

The numbers

• v2 pricing: ~$0.12 per ACU-hour (us-east-1). A day at 4 ACUs × 10h + 1 ACU × 6h + paused × 8h = 46 ACU-hours ≈ $5.52, versus $10–15 for an always-on instance.
• Paused = storage only, zero compute — the whole economic edge for intermittent workloads.
• v1 vs v2: v1 scales in 30–50s with a brief connection pause (single-AZ, no read replicas); v2 scales seamlessly in seconds with full features — start new projects on v2.
• Field examples: a db.r5.large staging instance ($210/mo) used only weekday business hours dropped to **$86/mo** on v2 with auto-pause ($124 saved, ×5 dev DBs ≈ $600+/mo); a morning-spike reporting db.r5.xlarge ($420/mo) halved to ~$205/mo.

Do this

1. Start new clusters on v2 unless you have a specific v1 reason.
2. Set the minimum low (0.5 ACUs in v2) and the maximum high enough for peak — low min captures idle savings, high max prevents throttling under load.
3. Enable auto-pause for dev/test and infrequently-used apps — nights and weekends at zero compute is where the 80–90% cuts come from.
4. Run one Serverless per tenant for multi-tenant SaaS — each database scales (or pauses) independently, so heavy customers get 10–16 ACUs while dormant ones sit at 0.5 or pause.
5. Cap max ACUs and wire CloudWatch/budget alarms on ACU usage — the guardrail against runaway scaling; test with realistic workloads first.

Gotchas

• Auto-pause wake is ~25 seconds — fine for dev/test; for user-facing apps set a minimum ACU above zero so it never pauses.
• v1's 30–50s scaling pause resets connections — apps need retry logic; another reason to prefer v2.
• Max connections scale with ACUs — a connection-heavy app can hit limits at a low min-ACU; size the minimum with that in mind (or front it with RDS Proxy).
• Constant high ACUs cost more than a fixed instance — do the math before migrating steady workloads.

Skip this if

• The database runs 24/7 at constant high CPU — provisioned Aurora (especially with reserved capacity) is cheaper; the elasticity is a premium you won't use.
• You need absolute maximum performance every second with zero scaling behavior to reason about — a fixed instance is simpler. For the I/O-charge angle on a provisioned cluster, see Aurora I/O-Optimized; for more database levers, RDS Instance Stop/Start and DynamoDB On-Demand.