Aurora Serverless v2

In the previous lesson, you explored how a running Aurora cluster operates through its endpoints, replication topology, failover behavior, and parameter groups. Every instance in that cluster used a fixed DB instance class such as db.r6g.xlarge, meaning you chose the compute size at provisioning time, and it stayed that size until you manually changed it. That model works well when workload demand is predictable, but many production workloads are not. Traffic spikes during business hours, drops to near zero overnight, and surges unpredictably during promotional events. Aurora Serverless v2 addresses this mismatch by letting Aurora resize its own compute automatically within boundaries you define, rather than forcing you to guess the right instance class upfront.

Aurora Serverless v2 is the current AWS on-demand autoscaling model for Aurora, replacing the older v1 approach that scaled in coarse, disruptive jumps. The fundamental unit of compute in this model is the Aurora Capacity Unit (ACU).A measure of compute capacity where each ACU provides approximately 2 GiB of memory along with proportional CPU and networking resources. Instead of selecting a specific instance class, you configure a minimum and maximum ACU range, and Aurora continuously adjusts each instance’s capacity within that band based on real-time demand.

One key difference from Aurora Serverless v1 is that Aurora Serverless v2 is not a separate database engine or isolated cluster type. It runs as one or more DB instances in an Aurora cluster, and a cluster can mix provisioned and serverless instances. Those instances use the same shared Aurora cluster storage volume, participate in the same writer/reader model, and use the cluster’s normal endpoints. You configure Aurora Serverless v2 with the same cluster and DB parameter group model, although some capacity-related parameters behave differently for serverless instances. The main difference is how compute capacity is allocated and scaled for each serverless writer or reader.

Attention: Aurora Serverless v2 can scale to zero using auto-pause (introduced in late 2024). If you set the minimum ACU to 0, the cluster can pause during idle periods to eliminate compute costs. Keep in mind that resuming from zero introduces a cold start of roughly 15 seconds, so a minimum of 0.5 ACU is still recommended for latency-sensitive production workloads.

Supported minimum and maximum ACU values vary depending on the Aurora engine (MySQL or PostgreSQL), the specific engine version, and the underlying platform capabilities. Before planning any capacity range, you must verify that your target engine version supports ...