This chapter provides a detailed comparison of Amazon Aurora Serverless v2 vs. Provisioned clusters from a cost optimization perspective, a key topic in the SAA-C03 exam's Cost Optimized domain (Objective 4.4). You will learn the internal mechanisms of both configurations, their pricing models, and how to choose the right one based on workload patterns. Approximately 10-15% of exam questions touch on Aurora cost optimization, often in the context of architecting cost-effective solutions.
Jump to a section
Imagine a transportation company that needs to move employees between offices. In the Provisioned model, the company buys a fixed fleet of 20 cars that are always parked in the garage, ready to go. They pay for all 20 cars every month regardless of usage—even on weekends when no one is traveling. This is like Aurora Provisioned: you pay for a fixed number of ACUs (Aurora Capacity Units) every hour, even if the database is idle. In the Serverless v2 model, the company uses a taxi service. When an employee needs a ride, they call a dispatch center that sends a taxi from a pool shared with other companies. The company only pays for the miles driven and time spent on each trip. If demand spikes—say 50 employees suddenly need rides—the dispatch instantly sends 50 taxis. If demand drops, taxis are released. This is like Aurora Serverless v2: it scales from 0.5 to 128 ACUs per hour based on load, and you pay only for the ACUs consumed per second. However, there's a catch: the taxi service has a minimum charge per trip (the minimum ACU setting) and may have a brief delay (cold start) if no taxis are nearby. The Provisioned fleet has no delay—cars are always ready—but you pay for idle capacity. The exam tests when each model is cost-optimal: steady workloads favor Provisioned; variable or unpredictable workloads favor Serverless v2.
What is Amazon Aurora?
Amazon Aurora is a MySQL- and PostgreSQL-compatible relational database built for the cloud. It offers the performance and availability of commercial-grade databases at one-tenth the cost. Aurora separates compute and storage: the storage layer is distributed, self-healing, and auto-scaling (up to 128 TiB). The compute layer can be provisioned (fixed capacity) or serverless (elastic capacity).
Provisioned Aurora: The Traditional Model
In Provisioned Aurora, you choose an instance class (e.g., db.r6g.large, db.r6g.16xlarge) and the number of replicas. You pay per hour for each running instance, regardless of actual database load. This model is ideal for steady-state workloads where CPU and memory utilization are predictable and constant. For example, a production OLTP system handling 10,000 transactions per second consistently would benefit from Provisioned instances because you avoid scaling overhead and can optimize instance selection for the exact workload.
Aurora Serverless v2: The Elastic Model
Aurora Serverless v2 (launched in 2022) is a pay-per-second, auto-scaling compute capacity model. It automatically adjusts the number of ACUs (Aurora Capacity Units) based on your application's demand. Each ACU provides approximately 2 GiB of memory and corresponding CPU. Minimum capacity is 0.5 ACU, maximum is 128 ACUs per instance. You can set a minimum and maximum ACU range. The database scales up and down seamlessly, with no interruption to connections. You pay only for the ACUs consumed per second, with a minimum charge of 1 ACU per hour per instance (even if below 1 ACU).
Internal Mechanism: How Serverless v2 Scales
Serverless v2 uses a shared pool of compute resources managed by the Aurora fleet. When your workload increases, the monitoring service detects higher CPU or connection usage and allocates additional ACUs from the pool. This allocation happens within seconds—typically 2-5 seconds—without requiring a failover or restart. The scaling is achieved by adding more compute capacity to the existing writer or reader instance. The storage layer is always shared and decoupled, so scaling compute does not affect storage. Scaling down releases capacity back to the pool. The minimum ACU setting ensures you always have baseline capacity; setting it too low may cause cold-start latency when scaling from near-zero, though Serverless v2 has a warm pool mechanism to reduce this.
Key Components and Defaults
ACU (Aurora Capacity Unit): 1 ACU ≈ 2 GiB memory, corresponding CPU. I/O operations are billed separately.
Minimum ACU: 0.5 (default). You can set as low as 0.5 ACU. Lower minimum reduces cost but may increase latency on burst.
Maximum ACU: Up to 128 ACU per instance. Higher maximum handles spikes but increases potential cost.
Pricing: Serverless v2: $0.12 per ACU-hour (approx) vs. Provisioned: varies by instance (e.g., db.r6g.large ~$0.25/hr). I/O costs are identical.
Scaling unit: Serverless v2 scales in increments of 0.5 ACU.
Scaling speed: Typically 2-5 seconds to add capacity; up to 30 seconds for large jumps (e.g., 10x).
Connection pooling: Serverless v2 supports up to 1,000 connections per ACU (same as Provisioned).
Failover: Serverless v2 supports Multi-AZ with automatic failover; failover time is similar to Provisioned.
Configuration and Verification
To create a Serverless v2 cluster, you specify the engine mode as provisioned but set the scaling configuration. Example using AWS CLI:
aws rds create-db-cluster \
--db-cluster-identifier my-serverless-v2-cluster \
--engine aurora-mysql \
--engine-version 8.0.mysql_aurora.3.02.0 \
--serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=8To verify scaling activity, use CloudWatch metrics: ServerlessDatabaseCapacity shows current ACU. The AuroraServerlessV2Scaling event in AWS Health can alert on scaling issues.
Interaction with Related Technologies
Aurora Auto Scaling is separate from Serverless v2; it automatically adds/removes Provisioned replicas based on load. Serverless v2 handles compute scaling internally, so you typically don't need Auto Scaling for compute.
RDS Proxy is often used with Serverless v2 to manage connection bursts, as scaling compute does not increase connection limits proportionally. RDS Proxy pools connections and reduces database load.
Backtrack works with both models, but Serverless v2 has a one-day backtrack window limit.
Global Database supports Serverless v2 as a secondary region (but not primary).
Cost Comparison: When Each Wins
Provisioned wins when workload is steady and predictable (e.g., 24/7 OLTP). Over a month, a db.r6g.large (2 ACU equivalent) costs ~$180 vs. Serverless v2 at 2 ACU average would be ~$172, but with Provisioned you get consistent performance and no scaling risk.
Serverless v2 wins when workload is variable, intermittent (e.g., dev/test, SaaS with many tenants), or unpredictable (e.g., event-driven). A dev database used 8 hours/day at 1 ACU average would cost ~$29/month with Serverless v2 vs. $180 Provisioned.
Serverless v2 also wins for applications with infrequent spikes (e.g., monthly reporting). You pay low baseline and absorb spikes at higher cost but only for minutes.
Trap Patterns on the Exam
Candidates often confuse Serverless v1 (now deprecated) with Serverless v2. Serverless v1 had a cold-start issue (up to 30 seconds) and was not suitable for production. Serverless v2 eliminates cold starts for most use cases. Another trap: assuming Serverless v2 is always cheaper—it is not for steady high-utilization workloads. Also, some think Serverless v2 scales storage automatically—it does, but so does Provisioned. The key differentiator is compute scaling.
Assess workload pattern
Determine if the database workload is steady, variable, or unpredictable. For steady workloads (e.g., 10,000 TPS constant over 24 hours), Provisioned is typically cheaper. For variable (e.g., 1,000 TPS during day, 100 at night) or unpredictable (e.g., event-driven spikes), Serverless v2 offers cost savings. Use CloudWatch metrics from existing databases or estimate from application logs. This step is critical for the exam: they often present a scenario with a specific usage pattern.
Evaluate minimum capacity requirement
Set the minimum ACU to the baseline capacity needed for idle or low-load periods. For example, a development database that is used rarely might set MinCapacity=0.5. However, if the database must handle sudden spikes without latency, a higher minimum (e.g., 2 ACU) reduces cold-start delay. The exam tests that lower minimum saves cost but may cause scaling delays. The default minimum is 0.5 ACU, but you can set it as low as 0.5.
Set maximum capacity ceiling
Set the maximum ACU to the peak capacity your workload might need. This prevents runaway costs. For example, a SaaS app might set MaxCapacity=16 to handle Black Friday traffic. The maximum can be up to 128 ACU per instance. The exam emphasizes that setting the max too high increases potential cost, but scaling up is fast. If the max is too low, performance suffers during spikes.
Enable RDS Proxy for connection management
Serverless v2 scales compute but the number of connections is not directly scaled—each ACU supports up to 1,000 connections. To handle sudden connection bursts (e.g., from 100 to 10,000 connections), use RDS Proxy. The proxy pools connections and reduces the number of database connections needed, preventing 'too many connections' errors. This is a common exam recommendation.
Monitor and adjust scaling configuration
After deployment, monitor CloudWatch metrics like `ServerlessDatabaseCapacity` and `CPUUtilization`. If you see frequent scaling events (scale up then down quickly), consider raising the minimum ACU to avoid thrashing. Also, check `AuroraServerlessV2Scaling` events for any failures. Adjust min/max as needed. The exam tests that you must monitor and adjust—it's not a 'set and forget' configuration.
Scenario 1: SaaS Multi-Tenant Application
A SaaS company provides a CRM tool to 500 small businesses. Each tenant has its own database schema (or separate database). Usage is unpredictable: some tenants are active during business hours, others at night, and some only on weekends. Total aggregate load varies from 50 TPS at night to 5,000 TPS during peak hours. Using Provisioned instances would require over-provisioning for peak, costing ~$5,000/month for 10 db.r6g.large instances. With Serverless v2, they set MinCapacity=0.5, MaxCapacity=4 per tenant database. The average ACU consumption is 1 ACU per database. Monthly cost: 500 databases * 1 ACU * 0.12 * 730 hours = $43,800? That would be worse. Actually, they can consolidate: use a single Serverless v2 cluster with one writer and multiple reader instances. By sharding tenants across databases in the same cluster, they reduce overhead. The key lesson: Serverless v2 is cost-effective per database only if the database is lightly loaded. For many small databases, consider using one database per tenant but with Serverless v2 if each tenant's load is low and variable.
Scenario 2: Event-Driven Reporting System
A financial analytics company runs hourly batch jobs that generate reports. The database is idle 55 minutes per hour, then spikes to 100% CPU for 5 minutes. With Provisioned (db.r6g.xlarge, 4 ACU), they pay $0.50/hour * 730 = $365/month. With Serverless v2, they set MinCapacity=0.5, MaxCapacity=8. During idle, they pay 0.5 ACU * $0.12 * 730 = $43.80. During the 5-minute spike, they scale to 8 ACU for 5 minutes per hour: 8 * 0.12 * (5/60) * 730 = $58.40. Total ~$102/month. Savings: 72%. This is a classic exam scenario: variable workload with predictable spikes.
Scenario 3: Production OLTP with Steady Load
An e-commerce platform handles 20,000 transactions per second 24/7. They need consistent low-latency and high IOPS. Using Provisioned db.r6g.8xlarge (32 ACU equivalent) costs $4.00/hour = $2,920/month. Serverless v2 at 32 ACU would be 32 * 0.12 = $3.84/hour = $2,803/month, slightly cheaper. However, Serverless v2 introduces scaling risk: if a traffic spike exceeds the max, performance degrades. Also, Provisioned instances offer reserved capacity discounts (up to 60% off with 3-year commitment). So for steady high-utilization workloads, Provisioned with reserved instances is cheaper and more reliable. The exam expects you to recommend Provisioned for steady-state production workloads.
What the SAA-C03 Tests
- Objective 4.4: Cost optimization for database services. The exam presents scenarios with workload descriptions (steady, variable, unpredictable) and asks you to choose between Provisioned and Serverless v2. - Specific codes: SAA-C03 Domain 4 (Cost Optimized) includes 'Select appropriate database services' and 'Choose cost-effective database configurations'. - Common wrong answers: 1. 'Always use Serverless v2 because it's cheaper.' This is false for steady workloads. 2. 'Serverless v2 cannot be used for production.' This is false—it is production-ready. 3. 'Serverless v2 scales storage automatically but Provisioned does not.' Both scale storage. 4. 'Serverless v2 has a cold start of 30 seconds.' This applies to Serverless v1, not v2. - Key numbers to memorize: Minimum ACU=0.5, Maximum ACU=128, scaling speed ~2-5 seconds, pay per second with 1 ACU minimum per hour. - Edge cases: - If the workload has frequent spikes (every few seconds), Serverless v2 may thrash—use Provisioned. - If you need Global Database primary, you cannot use Serverless v2 (only secondary). - If you need Backtrack beyond 1 day, use Provisioned. - Elimination strategy: Identify workload pattern first. Then check if the scenario mentions 'steady', 'predictable', 'high utilization' → Provisioned. If 'variable', 'unpredictable', 'intermittent', 'dev/test' → Serverless v2. Also look for cost-conscious phrases like 'minimize cost' or 'pay only for what you use'.
Aurora Serverless v2 scales compute from 0.5 to 128 ACU per instance; pay per second with 1 ACU minimum per hour.
Provisioned Aurora is cost-optimal for steady, high-utilization workloads, especially with reserved instances.
Serverless v2 is cost-optimal for variable, low-utilization, or unpredictable workloads (e.g., dev/test, event-driven).
Serverless v2 supports Multi-AZ, RDS Proxy, and Global Database (secondary), but not as a Global primary.
Minimum ACU setting affects baseline cost and cold-start latency; set according to workload.
Serverless v2 does not auto-scale connections; use RDS Proxy to handle connection bursts.
Exam trap: Serverless v2 is not always cheaper—evaluate workload pattern first.
Serverless v1 is deprecated; do not use in new architectures.
These come up on the exam all the time. Here's how to tell them apart.
Aurora Provisioned
Fixed instance size (e.g., db.r6g.large).
Pay per hour per instance regardless of usage.
Ideal for steady, predictable workloads with constant utilization.
Can purchase reserved instances for up to 60% discount.
No scaling latency—always at full capacity.
Aurora Serverless v2
Elastic ACU from 0.5 to 128 per instance.
Pay per second for ACUs consumed (min 1 ACU per hour).
Ideal for variable, intermittent, or unpredictable workloads.
No reserved instances available; pay-as-you-go only.
Scales in 2-5 seconds; may have slight latency on large jumps.
Mistake
Aurora Serverless v2 is always cheaper than Provisioned.
Correct
For steady, high-utilization workloads, Provisioned with reserved instances can be cheaper. Serverless v2 is cost-effective for variable, low-utilization, or unpredictable workloads.
Mistake
Serverless v2 has significant cold start latency like Serverless v1.
Correct
Serverless v2 scales in 2-5 seconds and has a warm pool mechanism, minimizing cold starts. Serverless v1 had up to 30-second cold starts and is deprecated.
Mistake
Serverless v2 automatically scales storage.
Correct
Both Provisioned and Serverless v2 auto-scale storage up to 128 TiB. The difference is compute scaling only.
Mistake
You cannot use Multi-AZ with Serverless v2.
Correct
Serverless v2 supports Multi-AZ with automatic failover, just like Provisioned.
Mistake
Serverless v2 is not suitable for production workloads.
Correct
Serverless v2 is production-ready and used by many enterprises. It supports up to 128 ACU, Global Database (as secondary), and RDS Proxy.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Serverless v1 is deprecated and had cold starts of up to 30 seconds, limited to 16 ACU, and no support for Multi-AZ or Global Database. Serverless v2 scales in seconds, supports up to 128 ACU, Multi-AZ, and Global Database (as secondary). v2 is production-ready and recommended for new deployments.
Assess workload pattern: steady and predictable → Provisioned (especially with reserved instances). Variable or unpredictable → Serverless v2. Also consider if you need Global Database primary (must be Provisioned) or Backtrack beyond 1 day (Provisioned). For cost-sensitive scenarios, calculate total cost of ownership including I/O.
Yes, Serverless v2 supports up to 15 read replicas, each with its own scaling configuration (min/max ACU). Replicas scale independently.
The database will throttle performance—queries may slow down or time out. Set the maximum high enough to handle expected peaks, or use Auto Scaling for Provisioned replicas if using Provisioned.
No, you cannot directly convert. You must create a new Serverless v2 cluster and migrate data using snapshot restore, database cloning, or AWS DMS.
I/O costs are identical for both models—$0.20 per million I/O requests. The difference is only in compute pricing.
Yes, you are billed for at least 1 ACU per hour per instance, even if the actual consumption is below 1 ACU (e.g., 0.5 ACU). So an idle database costs 1 ACU per hour.
You've just covered Aurora Serverless v2 Cost vs Provisioned — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?