Calculating costs from CloudWatch ServerlessDatabaseCapacity does not match values from Cost Explorer for Aurora RDS

In my understanding, the previous answer suggested using ACUUtilization. This is not optimal for cost tracking because ACUUtilization shows what percentage of your currently allocated capacity is being used.

Example: If your cluster is scaled to 10 ACUs but your internal load "only" uses 5, the metric shows 50%. However, AWS bills you for the full 10 ACUs.

• https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.how-it-works.html

To "fix" that: Stick to ServerlessDatabaseCapacity. This metric represents the actual number of ACUs AWS has provisioned and is billing you for at that specific moment.

You also need to consider the following:

Aurora Serverless v2 does not scale linearly (e.g., 2.12 ACUs). It scales in 0.5 ACU increments.

• Billing Reality: If your workload requires 2.1 ACUs of resources, Aurora scales to 2.5 ACUs.
• CloudWatch: If you use the Average statistic over an hour, CloudWatch might show an average of 2.2 ACUs, but the billing engine saw "2.5 ACUs" for that entire duration. This "rounding up" at the provisioning layer accounts for a significant portion of that "couple %" difference.

AWS bills Aurora Serverless v2 per second. CloudWatch typically aggregates data in 1-minute or 5-minute chunks.

• If you have a 10-second spike to 16 ACUs and the rest of the minute is at 2 ACUs, the Average for that minute will look like ~4.3 ACUs. However, you were billed for those 10 seconds at the 16 ACU rate.
• Instead of hourly averages, pull 1-minute intervals using the Maximum statistic for ServerlessDatabaseCapacity. This better captures the "high-water mark" that Aurora provisioned to handle your load.
• Aurora scales up instantly but scales down conservatively. After a spike ends, the service maintains the higher ACU capacity for a short "cooldown" period (often a few minutes) to prevent "flapping" (constant scaling up and down). So, your application might be idle, but ServerlessDatabaseCapacity will remain elevated for those few minutes. If your calculation ignores this tail-end, your estimate will be too low.

see: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMonitoring.Metrics.html

You cannot compare CloudWatch metrics to the "Total Cost" in Cost Explorer. You should filter Cost Explorer specifically to isolate compute:

• Filter by Usage Type: Look for [Region]-ServerlessV2Usage.
• Exclude Everything Else: Storage (VolumeUsage), I/O (DataTransfer or IOUsage), and Snapshots are billed separately and do not appear in the ServerlessDatabaseCapacity metric.

see: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html

The discrepancy you're experiencing is likely due to how Aurora Serverless v2 capacity is measured and billed. When calculating costs from CloudWatch metrics, there are a few important considerations:

Use ACUUtilization Instead of ServerlessDatabaseCapacity

Rather than using the ServerlessDatabaseCapacity metric (which represents a fixed number of ACUs), consider using the ACUUtilization metric. This represents a percentage of the upper limit on ACUs and provides a more accurate view of actual capacity usage without needing to know the exact minimum and maximum ACU values in your capacity range.

Billing Granularity

Aurora Serverless v2 measures database capacity in Aurora Capacity Units (ACUs) and bills per second. However, when aggregating CloudWatch metrics by the hour and averaging, you may lose precision. Usage is metered by the hour with partial hours rounded up, which can contribute to small discrepancies between your calculations and Cost Explorer.

Scaling Behavior

Aurora Serverless scales instantly up but takes time to scale down (up to 15x faster than previous versions, but still approximately 3 minutes in some cases). During scale-down periods, you're still being charged for the higher capacity, which might not be fully captured if you're simply averaging hourly metrics.

Additional Costs Beyond Compute

Cost Explorer includes all RDS costs, not just compute capacity. Your CloudWatch-based calculation using ServerlessDatabaseCapacity only accounts for ACU usage. You also need to factor in storage costs (charged per GB-month), I/O operations (for Aurora Standard configuration), backup storage beyond the free tier, and data transfer costs to match Cost Explorer totals.

To achieve more accurate cost allocation, you would need to combine the ACU utilization metrics with your actual storage, I/O, and other ancillary costs from your billing data.
Sources
Performance and scaling for Aurora Serverless v2 - Amazon Aurora
Amazon Aurora Pricing

Hey there! That's a great question. Tying back CloudWatch metrics to Cost Explorer can definitely be a bit tricky because they measure things slightly differently. Here’s a breakdown of why you’re seeing that gap and how you can get those numbers to align more closely!

1. Why the numbers don't quite match up

The main reason you're seeing a discrepancy is that the ServerlessDatabaseCapacity metric is a snapshot of instantaneous utilization, while billing is much more granular.

• The "Sampling Gap": If you're averaging minute-level data to get an hourly figure, you might be missing brief spikes. Aurora scales in seconds, and even if a spike only lasts 10 seconds, AWS bills you for a minimum of 1 minute at that higher capacity.
• The 1-Minute Minimum: Every time your instance scales up, you're committed to that capacity for at least 60 seconds. Simple averaging of periodic samples often "smooths out" these billing floors.

2. A more accurate way to calculate it

To get closer to the real cost, try shifting from an Average to a Sum of Seconds approach:

1. Get the raw data: Pull the ServerlessDatabaseCapacity at 1-minute resolution.
2. Calculate ACU-Seconds: Multiply each 1-minute ACU value by 60.
3. Factor in the Floor: Make sure your calculation never goes below your cluster’s Minimum ACU setting (usually 0.5 ACU), as you're billed for that even if the metric shows lower.
4. Convert to Hours: Sum all those ACU-seconds for the month and divide by 3,600.
5. Apply the Rate: Multiply that final "Total ACU-Hours" by your specific region's rate.

3. Pro-tip: Check for "Extra" costs

If you're still a few percent off, double-check that your Cost Explorer view is only looking at compute. CloudWatch's capacity metric only tracks the ACUs (the "brains"). It doesn't include:

• I/O Costs: If you're on Aurora Standard, those per-request charges won't show up in capacity metrics.
• Storage: The actual GBs of data sitting on the disk.

The "Golden Source"

If you need 100% accuracy without tagging, the best place to look is the AWS Usage Report. You can filter it by UsageType for Aurora:ServerlessUsage. It provides the exact billed ACU-Hours per Resource ID, which should match Cost Explorer perfectly!

Hope this helps you bridge the gap! Let me know if you have any other questions.