Amazon Aurora Serverless v2

Amazon Aurora Serverless v2 is an on-demand, auto-scaling configuration for Amazon Aurora. It automatically adjusts the database capacity based on the current workload, scaling in fine-grained increments (0.5 Aurora Capacity Units, or ACUs) and in milliseconds. Unlike Aurora Serverless v1, which scaled in larger increments and required a brief pause during scaling, v2 scales without any downtime or connection drops. It supports all Aurora MySQL and PostgreSQL features, including Multi-AZ deployments, Read Replicas, and Global Database.

Traditional provisioned Aurora requires you to choose a fixed instance size (e.g., db.r5.large) and manually scale up or down. This leads to either over-provisioning (paying for unused capacity) or under-provisioning (performance issues during spikes). Aurora Serverless v1 solved the scaling problem but had limitations: it could not be used in a Multi-AZ cluster, had a limited capacity range (2-256 ACUs), and scaled in 1-2 minute steps with a brief pause. Serverless v2 addresses all these limitations.

Aurora Serverless v2 uses a distributed storage system shared across all ACUs in a cluster. When a query is submitted, the writer endpoint (or reader endpoint) routes it to the appropriate instance. The instance processes the query using its allocated ACUs. Each ACU provides approximately 2 GB of memory, with corresponding CPU and networking. The scaling is handled by the Aurora fleet manager, which monitors metrics like CPU utilization, memory pressure, and connection count. When it detects increased demand, it adds ACUs to the instance in 0.5 ACU increments, without restarting the database or dropping connections. The process is transparent to the application—the same endpoint remains valid throughout.

You can create an Aurora Serverless v2 cluster using the AWS CLI, SDK, or Console. 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=2,MaxCapacity=32 \
    --master-username admin \
    --master-user-password password

Then create an instance in the cluster:

aws rds create-db-instance \
    --db-instance-identifier my-instance \
    --db-cluster-identifier my-serverless-v2-cluster \
    --db-instance-class db.serverless \
    --engine aurora-mysql

To verify the current ACU allocation, use:

aws rds describe-db-instances --db-instance-identifier my-instance

Look for the ServerlessV2ScalingConfiguration and Capacity fields in the output.

A retail company runs an e-commerce platform on AWS. During normal operation, the database handles a few thousand transactions per minute. During flash sales, traffic spikes to hundreds of thousands of transactions per minute, lasting only 30-60 minutes. With provisioned Aurora, they would need to over-provision for the peak, paying for unused capacity most of the time. With Aurora Serverless v2, they set min=4 ACUs (normal load) and max=64 ACUs (peak). During a flash sale, the database scales from 4 to 64 ACUs in less than a minute, handling the spike seamlessly. After the sale, it scales back down. They save approximately 70% on database costs compared to provisioned instances for the same peak performance.

A SaaS provider hosts hundreds of tenants on a shared Aurora cluster. Each tenant has varying usage patterns. Some tenants run monthly reports that spike CPU, while others have steady low traffic. Using Serverless v2, they set a wide ACU range (min=2, max=128) to accommodate all tenants. The database automatically scales based on total workload. However, they learned the hard way that a single tenant's runaway query could trigger scaling up to the max, increasing costs. They now use RDS Proxy and query timeouts to prevent runaway queries. They also set CloudWatch alarms to notify when ACU usage exceeds 80% of max for proactive management.

A development team creates multiple Aurora clusters for feature branches. These clusters are used only during business hours and are idle at night. With provisioned clusters, they would incur costs 24/7. With Serverless v2, they set min=0.5 ACU (the minimum) for each cluster. When not in use, the cluster scales down to 0.5 ACU, costing about $0.10 per hour. They also schedule automated snapshots and deletion scripts to clean up clusters after a branch merge. This reduces database costs by over 90% compared to running small provisioned instances.