Aurora Serverless v2 vs Aurora Provisioned: Which Should You Choose?

<div class="quick-answer">

**Quick Answer:** Serverless v2 wins for variable/unpredictable workloads and dev environments. Provisioned wins for predictable sustained throughput where per-ACU pricing exceeds instance pricing.

</div>

Aurora Serverless v2 is marketed as a "pay-for-what-you-use" database that eliminates capacity planning. That framing is partially true — but making the right architecture decision requires understanding ACU pricing, minimum costs, how in-place scaling works, and the specific workload patterns where serverless actually saves money compared to provisioned instances.

This comparison is for architects and engineering managers evaluating Aurora for production workloads, not for understanding the marketing message.

## v1 vs v2: Architectural Differences

Aurora Serverless v1 and v2 are different enough that comparing "Aurora Serverless" to "Aurora Provisioned" without specifying the version produces misleading conclusions.

| Characteristic                   | Aurora Serverless v1                 | Aurora Serverless v2 |
| -------------------------------- | ------------------------------------ | -------------------- |
| Scaling mechanism                | Instance swap (cold swap)            | In-place scaling     |
| Cold start / scaling pause       | Yes (multi-second pauses)            | No                   |
| Scale to zero                    | Yes (after configurable idle period) | No (minimum 0.5 ACU) |
| Minimum capacity                 | 1 ACU                                | 0.5 ACU              |
| Multi-AZ support                 | No                                   | Yes                  |
| Read replicas                    | Not supported                        | Supported            |
| Aurora Global Database           | Not supported                        | Supported            |
| Performance Insights             | Not supported                        | Supported            |
| Connections during scale         | Dropped                              | Maintained           |
| Production suitability           | Limited (not recommended)            | Yes                  |
| Recommendation for new workloads | No — use v2                          | Yes                  |

Aurora Serverless v1 was suitable for development databases and infrequently accessed workloads where the cold start delay was acceptable. For new workloads, v1 is not recommended. All production use cases should use v2 or provisioned.

## Cost Comparison

Aurora Serverless v2 and provisioned instances use different pricing units that make direct comparison require workload modeling.

**Aurora Serverless v2 pricing (us-east-1):**

- Compute: $0.12 per ACU-hour
- Storage: $0.10/GB-month (Aurora Standard) or $0.225/GB-month (I/O-Optimized)
- Minimum: 0.5 ACU = $0.06/hour = ~$43/month

**Aurora Provisioned pricing (us-east-1, PostgreSQL-compatible):**

| Instance       | vCPU | RAM   | $/hour (single-AZ) | $/month (single-AZ) |
| -------------- | ---- | ----- | ------------------ | ------------------- |
| db.t4g.medium  | 2    | 4 GB  | $0.073             | ~$53                |
| db.r6g.large   | 2    | 16 GB | $0.26              | ~$187               |
| db.r6g.xlarge  | 4    | 32 GB | $0.52              | ~$374               |
| db.r6g.2xlarge | 8    | 64 GB | $1.04              | ~$749               |

**Approximate Aurora Serverless v2 ACU equivalents:**

| ACU               | Approx. equivalent         | $/hour | $/month |
| ----------------- | -------------------------- | ------ | ------- |
| 0.5 ACU (minimum) | Fraction of t3.small       | $0.06  | ~$43    |
| 2 ACU             | ~db.t4g.medium equivalent  | $0.24  | ~$173   |
| 4 ACU             | ~db.r6g.large equivalent   | $0.48  | ~$346   |
| 8 ACU             | ~db.r6g.xlarge equivalent  | $0.96  | ~$691   |
| 16 ACU            | ~db.r6g.2xlarge equivalent | $1.92  | ~$1,382 |

Note: ACU-to-instance comparisons are approximate. An ACU is approximately 2 GB RAM + proportional CPU. At sustained high capacity, serverless costs are typically 30-50% higher than equivalent provisioned instances.

## Cold Start Behavior

Aurora Serverless v2 scales in-place — there is no cold start in the traditional sense. When demand increases, v2 adjusts the compute capacity of the running instance in fine-grained increments (as low as 0.5 ACU steps). This adjustment happens in seconds without dropping connections or interrupting queries.

**What this means practically:**

- A query submitted during a scale-out event is not delayed by the scaling operation
- Applications do not need cold start retry logic
- TCP connections to Aurora v2 are maintained during scaling events
- Multi-AZ Aurora Serverless v2 maintains identical behavior — scaling does not trigger failover

This is the most operationally significant difference from v1. For production web applications, API backends, and workloads requiring high availability, v2's in-place scaling makes it viable where v1 was not.

## Scaling Behavior Comparison

| Scaling Aspect       | Aurora Serverless v2            | Aurora Provisioned                  |
| -------------------- | ------------------------------- | ----------------------------------- |
| Scale-up speed       | Seconds (in-place)              | Minutes (instance resize)           |
| Scale-down speed     | Gradual, automatic              | Manual or schedule-based            |
| Scale to zero        | No (min 0.5 ACU)                | No (instance always running)        |
| Scaling granularity  | 0.5 ACU increments              | Instance size tiers                 |
| Scaling interruption | None                            | Brief maintenance window for resize |
| Maximum capacity     | 256 ACU                         | Largest available instance class    |
| Predictability       | Variable (cost fluctuates)      | Stable (fixed cost)                 |
| Read replica scaling | Independent serverless replicas | Independent provisioned instances   |

Aurora Provisioned is the right model when capacity requirements are well-understood and stable. You provision the right instance size and cost is predictable. Provisioned instances do not automatically scale up under load — if you undersize, you hit performance ceilings. Scaling a provisioned instance requires a resize operation with a brief interruption.

## Production Readiness

Aurora Serverless v2 is fully production-ready as of its general availability release. AWS Aurora production workloads in regulated industries (financial services, healthcare) run on Aurora Serverless v2 with Multi-AZ configurations.

**Aurora Serverless v2 production capabilities:**

- Multi-AZ deployments with automatic failover
- Aurora Replicas for read scaling (serverless replicas share the same storage)
- Performance Insights and Enhanced Monitoring
- Aurora Global Database for cross-region replication
- Compatible with RDS Proxy for connection pooling
- Point-in-time recovery and automated backups
- IAM database authentication and encryption at rest/in-transit

The primary production consideration is cost predictability. With provisioned instances, your database compute cost is a fixed monthly line item. With Serverless v2, cost varies with ACU consumption — a traffic spike doubles your ACU usage and your compute cost for that period. For organizations with strict budget controls, provisioned may be operationally simpler to forecast.

## When Serverless v2 Wins

Aurora Serverless v2 delivers genuine cost and operational advantages in specific patterns:

**Development and testing databases:** Dev databases are idle most of the day. A serverless dev database costs ~$43/month minimum versus ~$53-187/month for even a small provisioned instance — and scales down to near-minimum overnight. For teams running separate dev databases per engineer, the savings compound.

**Unpredictable traffic spikes:** If your application has viral or event-driven traffic where usage can spike 10x suddenly, serverless handles this without pre-provisioning for peak. A provisioned instance sized for peak sits idle (and costs the same) during off-peak periods.

**Variable multi-tenant SaaS:** SaaS platforms where each tenant has its own Aurora cluster (or where clusters serve variable tenant cohorts) benefit from serverless — quiet tenants scale down automatically.

**Workloads idle more than 50% of the time:** Any workload where the database is lightly used for more than half the day will typically have a lower average ACU cost than the equivalent provisioned instance.

## When Provisioned Wins

**Sustained, predictable workloads:** If your database runs at 70%+ CPU for most of the day, serverless costs more than the equivalent provisioned instance. The provisioned instance's capacity is included in the hourly price; serverless charges per ACU consumed.

**Cost predictability requirements:** Finance teams and customers with strict budgets often prefer provisioned's fixed monthly cost over serverless variability.

**Maximum performance for critical workloads:** For databases supporting high-frequency transactional systems, provisioned instances with reserved capacity deliver more consistent performance than serverless, which can briefly lag during scale-out events.

**Workloads approaching serverless maximums:** At 128+ ACU sustained, dedicated provisioned instances in larger families are typically more cost-effective.

## Migration Between Modes

Switching between Aurora Serverless v2 and Provisioned is relatively straightforward — both use the same underlying Aurora storage. You can modify a cluster's instance class from provisioned to serverless (and back) through the AWS console, CLI, or Terraform with a brief modification window. No data migration is required.

For teams uncertain whether serverless or provisioned is right, starting with Serverless v2 and monitoring average ACU consumption over 30-60 days provides the data needed to decide whether provisioned at a specific instance size would be cheaper for your workload pattern.

## Related Comparisons

Explore other technical comparisons:

- [AWS RDS vs Aurora](/compare/aws-rds-vs-aurora)
- [DynamoDB vs RDS](/compare/dynamodb-vs-rds)

## Why Work With FactualMinds

FactualMinds is an **AWS Select Tier Consulting Partner** — a verified AWS designation earned through demonstrated technical expertise and customer success. Our architects have run production workloads for companies from seed-stage startups to enterprises.

- **AWS Select Tier Partner** — verified by AWS Partner Network
- **Architecture-first approach** — we evaluate your specific workload before recommending a solution
- **No lock-in consulting** — we document everything so your team can operate independently
- [AWS Marketplace Seller](https://aws.amazon.com/marketplace/seller-profile?id=seller-m753gfqftla7y)

---