This chapter covers Amazon Aurora Serverless v2, a scalable, on-demand configuration for Aurora databases that automatically adjusts capacity based on application load. For the SAA-C03 exam, understanding Aurora Serverless v2 is critical for designing cost-effective, resilient database architectures that can handle unpredictable workloads. Approximately 5-10% of exam questions touch on Aurora Serverless v2, often comparing it with Aurora Provisioned, Serverless v1, or DynamoDB, and testing your ability to choose the right configuration for a given scenario.
Jump to a section
Imagine a restaurant that normally serves 100 diners per hour. The kitchen is staffed with a fixed number of chefs and ovens. When a sudden rush of 500 diners arrives, the restaurant must either turn them away or serve them slowly. Now imagine a restaurant that uses a 'kitchen pool' that can instantly add more chefs, ovens, and prep stations when the rush hits, then remove them when the rush ends. Each chef is a 'capacity unit' that can handle a certain number of orders per minute. The restaurant pays only for the chefs and ovens actually in use during each 5-minute interval. If the rush is huge, the kitchen can scale up to 1,000 chefs within seconds. But there's a minimum of 1 chef even when empty, to keep the kitchen ready. The key is that scaling is seamless: orders are never dropped, and the head chef (the Aurora auto-scaling algorithm) monitors the queue depth (CPU/memory) and adds capacity before the line gets too long. This is exactly how Aurora Serverless v2 works: it adjusts database capacity in ACU (Aurora Capacity Units) based on load, with a minimum and maximum configured, and scales in seconds without connection drops.
What is Aurora Serverless v2 and Why It Exists
Amazon Aurora Serverless v2 is an on-demand, auto-scaling configuration for Amazon Aurora databases. It was introduced in April 2022 to address the limitations of Aurora Serverless v1, which had a cold start problem, limited scaling granularity, and a maximum capacity of 256 ACUs. Serverless v2 provides near-instant scaling (within seconds), supports all Aurora features (like Multi-AZ, Global Database, and RDS Proxy), and offers a pay-per-second billing model for capacity used. The primary use case is for applications with variable or unpredictable workloads, such as SaaS platforms, e-commerce sites, or dev/test environments, where paying for fixed capacity would be wasteful.
How It Works Internally
Aurora Serverless v2 uses a shared storage architecture (same as Aurora Provisioned) but decouples compute from storage. The database instance runs on a fleet of EC2 instances managed by AWS. When you create a Serverless v2 DB cluster, you define a minimum and maximum capacity in Aurora Capacity Units (ACUs). Each ACU provides approximately 2 GB of memory and corresponding CPU and networking resources. The auto-scaling mechanism monitors the following metrics:
CPU utilization
Memory utilization
Database connections
Read/Write IOPS
The scaling algorithm uses a proprietary predictive model to add capacity before performance degrades. Scaling events are transparent to the application: connections remain open, and there is no downtime. Capacity changes occur in increments of 0.5 ACU. The minimum capacity can be as low as 0.5 ACU, and the maximum can be up to 128 ACUs per instance (for Aurora MySQL 3.04+ and PostgreSQL 13.6+). For Multi-AZ clusters, each instance (writer and reader) scales independently.
Key Components, Values, Defaults, and Timers
Aurora Capacity Unit (ACU): The unit of compute and memory. 1 ACU = approximately 2 GB memory + corresponding CPU/network.
Min ACU: The minimum capacity the cluster will scale down to. Default is 0.5 ACU. Minimum allowed: 0.5 ACU. Maximum: 128 ACU (per instance).
Max ACU: The maximum capacity the cluster will scale up to. Default is 8 ACU (for new clusters via console). Maximum: 128 ACU.
Scaling Increment: 0.5 ACU.
Scaling Time: Typically completes within 5-30 seconds. The exam often states 'within seconds'.
Cooldown Period: After a scaling event, there is a cooldown period (not user-configurable) of about 30 seconds to prevent rapid oscillations.
Billing: Billed per second for the ACUs consumed. Minimum charge: 0.5 ACU per second even if idle.
Supported Engines: Aurora MySQL 3.04+ (compatible with MySQL 8.0) and Aurora PostgreSQL 13.6+.
Feature Support: Supports Multi-AZ, Global Database, read replicas (within the same cluster), RDS Proxy, Data API, and backtrack.
Limitations: Does not support the following at launch: Aurora Serverless v2 clusters cannot be converted from Provisioned (must be created as Serverless v2). Also, Serverless v2 does not support Aurora MySQL 2.x (MySQL 5.7 compatible) or earlier PostgreSQL versions. Custom endpoints are not supported for Serverless v2 clusters (but reader endpoints work).
Configuration and Verification
You create a Serverless v2 cluster using the AWS Console, CLI, or SDK. Example CLI command to create a Serverless v2 DB cluster:
aws rds create-db-cluster \
--db-cluster-identifier my-serverless-v2-cluster \
--engine aurora-mysql \
--engine-version 8.0.mysql_aurora.3.04.0 \
--serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=32 \
--master-username admin \
--master-user-password secret123 \
--vpc-security-group-ids sg-12345678To verify scaling, use:
aws rds describe-db-clusters --db-cluster-identifier my-serverless-v2-clusterLook for the ServerlessV2ScalingConfiguration field and Capacity in the DBClusterMembers list. The current capacity is shown per instance.
Interaction with Related Technologies
RDS Proxy: RDS Proxy is fully compatible with Aurora Serverless v2. It helps manage connection pooling and reduces the number of database connections, which can improve scaling efficiency.
Aurora Auto Scaling with Replicas: You can configure Aurora Auto Scaling to add reader instances automatically based on CPU or connections. However, Serverless v2 scales compute capacity of existing instances, not the number of instances. For read scaling, you can add Serverless v2 reader instances manually or use Auto Scaling for the number of replicas.
Data API: Serverless v2 supports the Data API, which allows you to execute SQL statements via HTTP without managing persistent connections.
Backtrack: Backtrack is a feature that allows you to 'rewind' the cluster to a specific point in time without restoring from backup. It is supported on Serverless v2.
Performance Insights: Supported, but with reduced granularity for some metrics.
Exam Trap: Serverless v1 vs v2
The exam often tests differences between Serverless v1 and v2. Key distinctions: - v1 scales in 1 ACU increments, v2 in 0.5 ACU increments. - v1 has a cold start (pause/resume) causing latency, v2 does not pause. - v1 max capacity is 256 ACU, v2 max is 128 ACU per instance (but you can have multiple instances). - v1 does not support Multi-AZ, Global Database, or read replicas; v2 supports all these. - v1 is only available for Aurora MySQL 5.6/5.7 and PostgreSQL 10; v2 requires newer engine versions.
Exam Trap: Scaling Behavior
A common wrong answer is that Serverless v2 scales by adding more instances. In reality, it scales by adjusting the capacity of existing instances. The number of instances (writer and readers) is set by you; each instance scales independently within its min/max range. To handle increased read traffic, you add more reader instances (manually or via Auto Scaling), and each reader scales its own capacity.
Configure Min and Max ACU
When creating a Serverless v2 cluster, you set the minimum and maximum capacity in ACUs. The minimum can be as low as 0.5 ACU, and the maximum up to 128 ACU per instance. This range defines the boundaries within which the cluster can automatically scale. Setting appropriate values is critical: too low a maximum may cause throttling during spikes; too high a minimum may waste cost during idle periods. The exam often tests that the default maximum in the console is 8 ACU, but you can change it.
Monitor and Trigger Scaling
Aurora continuously monitors CPU, memory, connections, and IOPS. When utilization crosses a threshold (e.g., CPU > 70% for a sustained period), the scaling algorithm initiates a capacity increase. The algorithm is predictive, meaning it can preemptively scale before performance degrades. Scaling is done in 0.5 ACU increments. The cooldown period prevents rapid fluctuations. The exam may ask what metrics trigger scaling; the answer is CPU, memory, and connections.
Scale Up Capacity
During a scale-up, the database instance allocates more memory and CPU. This is achieved by the underlying EC2 fleet providing additional resources. The process is transparent: existing connections remain open, and there is no interruption. The scaling event completes within seconds (typically 5-30 seconds). The new capacity is applied to the instance, and the cluster continues serving requests. The exam may test that scaling is 'within seconds' and 'without downtime'.
Scale Down Capacity
When load decreases, the algorithm scales down by reducing capacity, again in 0.5 ACU increments. The minimum capacity is honored. Scaling down is also seamless. However, the database never pauses or stops; it always runs at the configured minimum capacity (even if idle). This is a key difference from Serverless v1, which could pause and resume. The exam may ask: 'Does Aurora Serverless v2 pause when idle?' Answer: No.
Billing and Metering
Billing is per second for the ACUs consumed. For example, if a cluster runs at 2 ACU for 10 seconds, then scales to 4 ACU for 5 seconds, you are billed for (2*10 + 4*5) = 40 ACU-seconds. Storage and I/O are billed separately (per GB-month and per I/O request). There is no additional charge for scaling events. The exam may test that billing is per second, and that you pay for the minimum capacity even when idle.
Scenario 1: SaaS E-Commerce Platform
A SaaS company runs an e-commerce platform with thousands of tenants. Traffic varies wildly: Black Friday spikes can be 100x normal load, while overnight traffic is near zero. Using Aurora Provisioned would require over-provisioning for peak, wasting cost. They migrate to Aurora Serverless v2 with min=2 ACU, max=128 ACU. During Black Friday, the cluster scales up to 128 ACU within seconds, handling the surge without any configuration changes. The application uses RDS Proxy to manage connections, and read replicas (also Serverless v2) are added via Auto Scaling to handle read-heavy catalog queries. Cost savings: 60% compared to Provisioned. The challenge: they had to upgrade their MySQL 5.7 database to Aurora MySQL 3 (compatible with MySQL 8.0), which required application testing. Misconfiguration: initially they set max ACU too low (16 ACU), causing throttling; after adjustment, scaling worked perfectly.
Scenario 2: Dev/Test Environments
A financial services firm uses Aurora for development and testing. Databases are used heavily during business hours but idle at night and weekends. With Provisioned, they pay 24/7. They switch to Serverless v2 with min=0.5 ACU, max=8 ACU. The database scales up during testing and down to minimum when idle. Cost reduction: 75%. One pitfall: they forgot to set a minimum, but the default is 0.5 ACU, so it still worked. However, if the database is accessed very infrequently, the minimum cost is still incurred. For truly intermittent use, Serverless v1 (with pause) might be cheaper, but v2 offers better features.
Scenario 3: Global Database with Serverless v2
A gaming company uses Aurora Global Database for disaster recovery across regions. They use Serverless v2 for the primary and secondary clusters. The secondary cluster in the DR region is set to min=0.5 ACU to minimize cost during normal operation, but can scale up if failover occurs. The failover is automatic and the secondary cluster scales up within seconds. This provides cost-effective DR. Misconfiguration: they initially set the secondary cluster's max ACU too low (8 ACU), and after failover, the database could not handle production load. They increased max ACU to 64 ACU. The exam may test that Global Database supports Serverless v2 clusters in both primary and secondary regions.
What the SAA-C03 Tests
The SAA-C03 exam tests your ability to choose the right database solution for a given scenario. For Aurora Serverless v2, expect questions that compare it with Aurora Provisioned, Aurora Serverless v1, and DynamoDB. The key objective codes are:
Domain 2: Resilient Architectures, Objective 2.3: Select an appropriate database service.
Domain 3: High-Performing Architectures, Objective 3.2: Select appropriate database solutions.
Common Wrong Answers and Why
'Aurora Serverless v2 pauses when idle.' This is wrong because Serverless v2 does not pause; it always runs at the minimum capacity. Serverless v1 pauses. Candidates confuse the two versions.
'Serverless v2 scales by adding more instances.' Wrong. It scales the capacity of existing instances. Adding instances is done manually or via Auto Scaling for replicas.
'Serverless v2 supports all Aurora MySQL engine versions.' Wrong. It requires Aurora MySQL 3.04+ (MySQL 8.0 compatible) or PostgreSQL 13.6+. Older versions are not supported.
'Serverless v2 is cheaper than Provisioned for steady workloads.' Wrong. For steady, predictable workloads, Provisioned reserved instances are cheaper. Serverless v2 is designed for variable workloads; its per-second billing can be more expensive for constant high usage.
Specific Numbers and Terms
ACU = Aurora Capacity Unit (2 GB memory)
Min ACU = 0.5
Max ACU = 128 per instance
Scaling increment = 0.5 ACU
Scaling time = seconds (5-30 seconds)
Billing = per second
Supported engines: Aurora MySQL 3.04+ and PostgreSQL 13.6+
Features supported: Multi-AZ, Global Database, read replicas, RDS Proxy, Data API, backtrack
Features not supported: Custom endpoints, conversion from Provisioned
Edge Cases
Serverless v2 with Multi-AZ: Both writer and reader instances scale independently. If the writer fails, the reader becomes the new writer and continues with its own scaling configuration.
Serverless v2 with Global Database: The secondary cluster can be Serverless v2. During failover, it scales up from its minimum capacity.
Maximum storage: Serverless v2 uses the same storage as Aurora Provisioned, up to 128 TiB.
How to Eliminate Wrong Answers
If the question mentions 'pausing' or 'cold start', eliminate Serverless v2 and consider v1.
If the question requires consistent performance for a steady workload, choose Provisioned with reserved instances.
If the question requires very high capacity (over 128 ACU per instance), consider Provisioned or multiple instances.
If the question mentions 'connection pooling' or 'reducing database connections', think of RDS Proxy, which works with Serverless v2.
Always check the engine version: if the database is MySQL 5.7, Serverless v2 is not supported.
Aurora Serverless v2 scales in increments of 0.5 ACU, from 0.5 to 128 ACU per instance.
Scaling completes within seconds and is transparent to applications (no downtime).
Serverless v2 does not pause; it always runs at minimum capacity.
Billing is per second for ACUs used, plus separate storage and I/O charges.
Supported engines: Aurora MySQL 3.04+ and Aurora PostgreSQL 13.6+.
Serverless v2 supports Multi-AZ, Global Database, read replicas, RDS Proxy, Data API, and backtrack.
Cannot convert an existing Provisioned cluster to Serverless v2; must create new cluster.
For steady workloads, Provisioned with reserved instances is more cost-effective.
Serverless v2 is ideal for variable workloads, dev/test, and SaaS applications.
The exam distinguishes v2 from v1: v2 has no pause, finer scaling, and more features.
These come up on the exam all the time. Here's how to tell them apart.
Aurora Serverless v2
Auto-scales capacity within seconds based on load.
Billed per second for ACUs consumed.
Ideal for variable or unpredictable workloads.
Minimum capacity of 0.5 ACU always running.
Supports Multi-AZ, Global Database, read replicas.
Aurora Provisioned
Fixed capacity; must manually scale or use Auto Scaling for replicas.
Billed per hour for provisioned instances.
Best for steady, predictable workloads.
Can be stopped to save costs (but not auto-pause).
Supports all features including custom endpoints.
Mistake
Aurora Serverless v2 pauses when there is no activity.
Correct
Serverless v2 does not pause; it scales down to the minimum capacity (as low as 0.5 ACU) but continues running. Only Serverless v1 has a pause/resume feature.
Mistake
Serverless v2 scales by adding more database instances.
Correct
Serverless v2 scales the capacity (CPU/memory) of existing instances. The number of instances is fixed unless you manually add replicas or use Auto Scaling.
Mistake
Serverless v2 supports all Aurora MySQL versions.
Correct
Serverless v2 only supports Aurora MySQL 3.04+ (MySQL 8.0 compatible) and Aurora PostgreSQL 13.6+. Older versions like MySQL 5.7 are not supported.
Mistake
Serverless v2 is always cheaper than Provisioned.
Correct
Serverless v2 can be more expensive for steady, high-usage workloads because it bills per second without reservation discounts. Provisioned with reserved instances is cheaper for predictable workloads.
Mistake
You can convert an existing Provisioned Aurora cluster to Serverless v2.
Correct
Conversion is not supported. You must create a new Serverless v2 cluster and migrate data (e.g., via snapshot restore or DMS).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Aurora Serverless v2 offers finer scaling (0.5 ACU increments vs 1 ACU), no pause/resume (always runs at minimum capacity), supports Multi-AZ, Global Database, and read replicas, and uses newer engine versions. v1 has a cold start when pausing, max 256 ACU, and limited features. For the exam, remember that v2 is more feature-rich and suitable for production workloads.
Yes, RDS Proxy is fully compatible with Aurora Serverless v2. It helps manage connection pooling, reducing the number of database connections and improving scaling efficiency. The exam may suggest RDS Proxy as a way to handle burst connections with Serverless v2.
The minimum capacity is 0.5 ACU, and the maximum is 128 ACU per instance. For a cluster with multiple instances, each instance can have its own min/max. The exam often tests these exact numbers.
Yes, Aurora Serverless v2 supports Global Database. You can have a primary cluster and secondary clusters in different regions, all using Serverless v2. This is useful for disaster recovery.
Billing is per second for the ACUs consumed. You pay for the capacity used each second, with a minimum of the configured min ACU. Storage and I/O are billed separately. There is no upfront cost.
No, Aurora Serverless v2 requires Aurora MySQL 3.04+ (compatible with MySQL 8.0). For MySQL 5.7, you must use Aurora Provisioned or Serverless v1.
Yes, you can add reader instances to a Serverless v2 cluster. Each reader scales independently within its own min/max ACU configuration. You can also use Auto Scaling to automatically add readers based on load.
You've just covered Aurora Serverless v2 Scaling — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?