The Challenge of Provisioning
Choosing a database instance size is a guessing game. If you provision too small, a traffic spike crashes your database. If you provision too large, you pay for idle capacity 20 hours a day. For workloads with predictable, steady traffic, this tradeoff is manageable. For workloads with unpredictable spikes — a flash sale, a viral social media post, market open for a trading platform — it's a genuine operational problem.
How Serverless v2 Works
Aurora Serverless v2 replaces the concept of a fixed instance type with a continuous scaling range. Instead of choosing db.r6g.large or db.r6g.2xlarge, you set a minimum and maximum capacity in Aurora Capacity Units (ACUs).
- ACU (Aurora Capacity Unit): The unit of compute capacity. 1 ACU provides approximately 2 GB of RAM and proportional CPU and network resources.
- Scaling Range: You configure a minimum (as low as 0.5 ACU) and a maximum (up to 256 ACUs). Aurora scales within this range automatically.
- Scaling Granularity: Serverless v2 scales in increments of 0.5 ACU, allowing fine-grained adjustments rather than doubling capacity at each step.
- Scaling Speed: Scaling happens in a fraction of a second — fast enough to respond to sudden traffic spikes without dropping connections or pausing the database. This is the critical difference from Serverless v1, which could take minutes to scale and would pause the database during the process.
Serverless v2 vs. Provisioned: When to Use Each
| Scenario | Recommendation |
|---|---|
| Steady, predictable traffic (e.g., internal CRUD app) | Provisioned — cheaper at constant load |
| Variable, unpredictable spikes (e.g., e-commerce, trading) | Serverless v2 — scales to meet demand |
| Development/test environments (idle most of the time) | Serverless v2 with low minimum ACU — pay near-zero when idle |
| Multi-tenant SaaS with many small databases | Serverless v2 — each tenant DB scales independently |
A critical nuance: Serverless v2 does not scale to zero. The minimum is 0.5 ACU. If you need true scale-to-zero (no cost when completely idle), that requires Serverless v1, which has significant limitations (connection drops during cold start, limited feature support). For most production workloads, Serverless v2's 0.5 ACU minimum is the right tradeoff.
A common interview question is: "What's the difference between Aurora Serverless v1 and v2?" The answer that impresses: v1 scales by swapping out the entire compute instance (causing connection drops and cold-start latency measured in seconds to minutes). v2 scales in-place by adjusting CPU and memory allocation without disrupting connections, making it suitable for production workloads that v1 could not handle.