Aurora Serverless v2 pricing: idle cost (2026)

Aurora Serverless v2 pricing looks like pay-per-use, and the bill for an idle cluster says otherwise. You pay per ACU-hour, and an Aurora Serverless v2 cluster that nobody is using still bills its minimum capacity, multiplied by every writer and every reader that follows the writer. Only a minimum of zero ACUs, with automatic pause, takes that to nothing, and a long list of ordinary features quietly stops the pause from happening.

What is an Aurora Serverless v2 ACU?

The billing unit. The Amazon Aurora pricing page says Aurora serverless "measures database capacity in Aurora Capacity Units (ACUs) billed per second. 1 ACU has approximately 2 GiB of memory with corresponding CPU and networking, similar to that used in Aurora provisioned instances."

The Aurora User Guide's explanation of how Aurora serverless works sets the range: "Aurora serverless offers capacity from 0 ACUs to 256 ACUs." Capacity moves in "increments as small as 0.5 ACUs", and you set one minimum and one maximum that applies to every serverless instance in the cluster. Which range you actually get depends on the engine version:

The platform version can narrow that range further. AWS notes that "The scaling range is determined by the lowest capable engine or platform version", so an upgraded engine on an older platform can still be stuck above zero.

How much does Aurora Serverless v2 cost per ACU-hour?

The pricing page's rate tables are rendered in the browser, but its worked example for US East (N. Virginia) states the rates in plain text: "5 ACUs * $0.12 per ACU-hour * 30/60 hour" on Aurora Standard, and "5 ACUs * $0.156 per ACU-hour * 30/60 hour" on Aurora I/O-Optimized. I/O-Optimized compute costs 30% more per ACU-hour, in exchange for no read and write I/O charges.

AWS totals that example at $0.33: $0.30 for 30 minutes at 5 ACUs, plus $0.03 for a 3-minute scale-down it bills at the full 5 ACUs. Read the setup again, though: "the minimum database capacity you can set is 0.5 ACUs", and the database "scales down to the minimum capacity of 0.5 ACUs". The example stops the clock there. The same cluster sitting at 0.5 ACUs for the other 23.45 hours of that day adds $1.41, so the realistic daily bill is $1.74, and the 30-minute workload is less than a fifth of it.

That example is also out of date on its own page. The same section of the pricing page lists a starting capacity of "0 ACU", and the User Guide documents zero as a valid minimum on the engine versions in the last row of the table above. Both sentences are live on the same page.

What does an idle Aurora Serverless v2 cluster cost?

The minimum ACUs, times the instance count, times every hour of the month. The User Guide puts it as a formula: a cluster with n writers and readers "consumes approximately n x minimum ACUs when you aren't running any database operations." That holds for every reader, whatever its promotion tier: an idle reader in tier 2 to 15 sits at the minimum too.

The promotion tier matters once the writer is busy. "For readers in promotion tiers 0 and 1, the minimum capacity is defined by the current writer capacity", which is what makes them good failover targets and also means a tier 0 or 1 reader bills at least as many ACUs as the writer for as long as the writer is busy. Readers in tiers 2 to 15 scale on their own, so a quiet one stays near the minimum while the writer works.

AWS also recommends floors above 0.5 for some features. Its guidance on choosing the minimum capacity lists "Performance Insights" at 2 ACUs and "Aurora global databases" at 8 ACUs for the primary Region. Priced at the $0.12 Standard rate over a 730-hour month:

On I/O-Optimized every figure is 30% higher: the 0.5 ACU writer is $56.94. And the floor you set is not a guarantee of reaching it. The same page warns that Aurora global databases, exporting CloudWatch Logs, Enhanced Monitoring and Performance Insights can "prevent the database from scaling down to minimum capacity", as can raising shared memory parameters such as max_connections above their defaults.

Does Aurora Serverless v2 scale to zero?

Yes, on the newer engine versions, and only if you set the minimum to zero. Per the Aurora serverless auto-pause documentation, "You aren't charged for instance capacity while an instance is in the paused state." Aurora PostgreSQL "must be running at least version 16.3, 15.7, 14.12, or 13.15", and Aurora MySQL "must be running version 3.08.0 or higher."

• Timeout. "The minimum interval that you can set is 300 seconds (five minutes). That's the default if you don't specify an interval. The maximum interval that you can set is 86,400 seconds (one day)." Every resume therefore buys at least five more minutes of compute.
• Resume latency. "the typical time to resume might be approximately 15 seconds". After more than 24 hours paused, "the resume time can be 30 seconds or longer".
• Maintenance wakes. After a wake for an upgrade or maintenance, "Aurora waits at least 20 minutes before pausing that instance again."
• Storage keeps billing. "AWS still charges for Aurora storage and other aspects of the cluster that aren't tied to that specific DB instance."

Any connection attempt wakes it, including one with bad credentials: "A connection attempt that doesn't include valid credentials still causes the DB instance to resume." So do describing or downloading its log files, changing a parameter group it uses, and some maintenance, though taking or deleting a snapshot does not. The reverse also bites: scheduled jobs in pg_cron or the MySQL event scheduler do not wake a paused instance, and "Such jobs are skipped when the instance resumes later."

Pausing is the database equivalent of stopping an EC2 instance: compute stops, storage does not. AWS says the savings "are similar to using the stop/start cluster feature", with a faster resume.

What stops Aurora Serverless v2 from auto-pausing?

This is the list that decides whether a minimum of zero saves anything. AWS is explicit that you get no warning: "For incompatible features, you won't get any error if you use them in combination with auto-pause." From the same auto-pause page:

Two rows deserve a closer look. On RDS Proxy the documentation says "the proxy maintains an open connection to each DB instance in the cluster. Thus, any Aurora serverless instances in such a cluster won't automatically pause." And the RDS Proxy pricing page says that for Aurora Serverless, "RDS Proxy is priced per Aurora Capacity Unit (ACU) per hour consumed by your database." Its price table then lists a minimum charge of 8 ACUs for Aurora Serverless v2. So a proxy does two things to a small cluster: it removes the zero, and a single-instance cluster idling at 0.5 ACUs is still billed for 8 ACUs of proxy capacity, sixteen times its own floor.

The other is topology. "The writer can only pause if the entire cluster is idle. That's because a connection to any reader instance causes the writer to resume." A reporting reader in tier 2 that someone queries every few minutes keeps the writer billing all day.

To check what a cluster is actually configured for, the auto-pause page shows the setting directly. A missing SecondsUntilAutoPause means the minimum is above zero:

aws rds describe-db-clusters --db-cluster-identifier my-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'

To check whether it pauses in practice, AWS suggests watching how often ServerlessDatabaseCapacity drops to zero and how long it stays there, and recommends "measuring the actual paused time over a period of several days, with a realistic workload."

Is Aurora Serverless v2 cheaper than a provisioned RDS instance?

Only when average capacity is low. AWS never prints this comparison, but its own pricing page supplies both sides. The Global Database example prices a provisioned "db.r6i.large (at $0.29 per hour)" on Aurora Standard, and the Aurora instance class hardware table gives that class 16 GiB of memory. AWS's own sizing rule converts memory to ACUs at 2 GiB each, the method it uses to map a 32 GiB db.r6g.xlarge to 16 ACUs. So the memory-equivalent serverless capacity is 8 ACUs.

At full memory-equivalent capacity, serverless costs 3.31 times the provisioned instance per hour. The break-even is identical on I/O-Optimized, because both the ACU rate and the instance rate rise by the same 30% ($0.377 against $0.156 gives 2.42 ACUs again).

A development database at 8 ACUs for 10 hours on each of 22 working days uses 220 hours, costing $211.20, which is almost exactly the always-on provisioned instance. If it idles at 0.5 ACUs the rest of the month instead of pausing, the bill is $241.80 and provisioned wins. The break-even depends on the pause working, which is why the list above matters more than the rate.

This is the same shape of decision as DynamoDB on-demand versus provisioned capacity, where AWS does publish the utilisation threshold. For Aurora you have to derive it. The CPU side is not guaranteed to match: an ACU carries "corresponding CPU", not a vCPU count, so treat the memory comparison as AWS's sizing heuristic rather than a benchmark.

What else is on an Aurora Serverless v2 bill besides ACUs?

Storage and, on Aurora Standard, I/O. "With Aurora Standard, you pay for your database instances, storage, and pay-per-request I/O." The pricing page's US East examples use "$0.10 per GB-month" and "$0.20 per 1 million I/Os" for Standard, and "$0.225 per GB-month" with no I/O charge for I/O-Optimized. The configuration applies to serverless: you can "configure all the instances in your database cluster to use the Aurora Standard or Aurora I/O-Optimized configuration". Which one wins is an I/O question, not a serverless one, and it is out of scope here.

Two more charges are priced on ACUs and so move with your capacity floor. RDS Extended Support on an old engine version is billed per ACU per hour, covered in what RDS Extended Support costs and how enrolment works. RDS Proxy is billed per ACU-hour with an 8 ACU minimum, as above, so on a small cluster the proxy floor can exceed the database floor.

On commitments, the Database Savings Plans pricing page lists Aurora Serverless v2 as eligible and says the plans "automatically apply to eligible serverless and provisioned instance usage regardless of engine, instance family, size, deployment option, or AWS Region". It also warns you "cannot combine Database Savings Plans with Amazon RDS Reserved Instances" on the same workload. The Aurora pricing page offers Reserved Instances only as a provisioned option. A commitment sized to a floor you are about to set to zero goes unused, so measure the paused hours first, then size it the way Savings Plans coverage and utilization describes.

Finally, a charge serverless does not remove: application servers reaching the cluster from another Availability Zone pay EC2 Regional Data Transfer, which the pricing page states and cross-AZ data transfer cost explains in full. And if the question behind the database choice is where your monthly spend actually went, amortized versus unblended cost explains how a Savings Plan shows up once you buy one.