AWS cost · Aurora Serverless v2

Aurora Serverless v2: the min ACU floor bills 24/7

Serverless sounds like you pay for what you use. Aurora Serverless v2 scales between a minimum and a maximum you choose, and the word doing the damage is minimum. Whatever number you put in that field is a floor the cluster never goes below, billed every hour of every month whether any query runs or not. It is one line in a configuration block, not a resource, so nothing in the console lists it and no alarm watches it.

One ACU costs $0.12/hour in us-east-1 - about $87.60/month held continuously. A cluster configured with a minimum of 1 ACU that never needs more than 0.5 pays roughly $43.80/month for capacity it never uses. Check the lowest capacity your cluster actually reached, then set the floor to match.

What does the ACU floor actually cost?

The floor is charged at the same rate as capacity you asked for on purpose:

Pick the right rate for your cluster. An I/O-Optimized cluster costs a third more per ACU, so pricing one at the standard rate under-reports what the floor is really costing you.

Why does nobody notice the minimum?

Because it is not a thing you can see. A stopped instance still has a disk you can list. An idle load balancer has a name in a console. The ACU floor is a number inside a scaling configuration, chosen once when the cluster was created, usually copied from an example or a module default. It never breaks, never warns, and the bill it produces looks like normal database spend rather than waste.

It is the same shape as a development database left running overnight - capacity nobody decided to keep paying for, on a resource that looks busy because it exists.

How low should the floor go?

Capacity is set in steps of 0.5 ACU across a range of 0 to 256. A minimum of 0 is only available on engine versions that support automatic pause and resume; everywhere else the lowest floor is 0.5. Some engine versions also cap the top of the range lower than 256.

The cost of going lower is warm-up time. Scaling from 0.5 to the capacity a spike needs takes longer than scaling from 4, and a paused cluster has to resume before it answers the first connection. For a development, staging, or reporting cluster that delay is free money. For a production workload with sharp traffic spikes, the headroom is what you are buying - keep it, and take the saving somewhere else.

How do I find a floor set too high?

List the clusters with a scaling configuration, then look at the lowest capacity each one reached over the last couple of weeks. Note the dimension: ServerlessDatabaseCapacity is published per DB instance, not per cluster, so a query keyed on the cluster identifier matches nothing and looks exactly like a cluster that never scaled:

# clusters with a Serverless v2 floor, and what it is set to
aws rds describe-db-clusters \
  --query "DBClusters[?ServerlessV2ScalingConfiguration!=null].{Id:DBClusterIdentifier,Min:ServerlessV2ScalingConfiguration.MinCapacity,Max:ServerlessV2ScalingConfiguration.MaxCapacity,Storage:StorageType}" \
  --output table

# lowest capacity one instance reached (equal to the floor = the floor is the limit)
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS --metric-name ServerlessDatabaseCapacity \
  --dimensions Name=DBInstanceIdentifier,Value=my-aurora-instance-1 \
  --start-time 2026-07-29T00:00:00Z \
  --end-time   2026-08-12T00:00:00Z \
  --period 86400 --statistics Minimum

# changes the floor - review the warm-up trade-off first
aws rds modify-db-cluster \
  --db-cluster-identifier my-serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=4

If the minimum observed capacity sits exactly on the configured floor across the whole window, the configuration is the limit and the cluster would have gone lower. If it sits above the floor, the workload needs that capacity and there is nothing to cut.

Frequently asked questions

More AWS cost breakdowns