2026-03-08 · FinOps

Volume vs Price vs Mix Variance in Cloud Billing Explained

Your cloud bill went up. The natural question is why. But that question is actually three separate questions dressed up as one.

Did you use more? Did the price per unit go up? Or did your workloads shift toward more expensive services?

Each of those has a different cause and a different fix. Mixing them up leads to the wrong diagnosis. This post explains how to tell them apart.

The Three Types of Variance

Cost variance decomposition comes from financial analysis. It breaks a change in total spend into components so you can assign blame correctly.

In cloud billing, there are three components:

Volume variance is the portion of the cost change caused by using more or less of a service. If you ran twice as many Lambda invocations this month and the price per invocation stayed the same, that increase is pure volume.

Price variance is the portion caused by the unit cost changing while usage stays the same. The most common example is a Reserved Instance or Savings Plan expiring. Your EC2 hours did not increase, but the rate jumped from the discounted RI price to full on-demand pricing. That delta is price variance.

Mix variance is the portion caused by your usage shifting between services or tiers that have different unit costs. Say you ran fewer t3.medium instances this month but more m5.4xlarge. Total hours stayed roughly the same but the bill went up because you moved toward a more expensive instance type. That is mix variance.

Why It Matters

If the spike is volume, the conversation is about growth or about a bug. Either your traffic went up, or something is running that should not be.

If the spike is price, the conversation is about discounts. An RI expired, a Savings Plan ran out, or you lost an EDP credit. The fix is to buy coverage again.

If the spike is mix, the conversation is about configuration. Someone changed instance types, switched regions, or started using a more expensive tier of a service.

These three situations call for completely different responses. Buying more Reserved Instances does nothing if the problem is that your team accidentally stood up a fleet of m5.24xlarge instances. Investigating usage patterns wastes time if the real issue is that your three-year RI expired last Tuesday.

A Simple Example

Suppose your S3 bill was $400 last month and is $600 this month, a $200 increase.

To figure out why, you need two numbers for each billing period: the usage amount (in this case, GB stored) and the effective price per unit (cost divided by usage).

Say last month you stored 10,000 GB at $0.04 per GB. This month you stored 13,000 GB at $0.046 per GB.

The volume effect is the change in usage times the old price: 3,000 GB multiplied by $0.04 equals $120. That is how much more you would have paid if the price had not changed.

The price effect is the change in unit cost times the new usage: $0.006 multiplied by 13,000 GB equals $78. That is how much more you paid just because the rate went up.

Add them together: $120 plus $78 equals $198, close to the $200 actual change (rounding explains the gap).

Now you know that volume drove most of it, but there was also a meaningful price component. Worth checking whether a storage discount expired.

[figure:waterfall-variance]

Where Mix Comes In

The example above only has one service and one tier. Mix variance appears when you have multiple line items with different unit costs and the proportion shifts between them.

Think about EC2. You might have a mix of t3, m5, and r5 instances. Each has a different hourly rate. If the distribution shifts toward r5 instances (memory optimized, more expensive), your total EC2 hours might stay flat but the bill goes up. That is mix variance.

Mix is the hardest of the three to spot manually because it requires comparing the composition of your spend across periods, not just the totals. Aggregating by service or even by usage type can hide it.

How to Do This With a CUR File

The raw data you need is in your Cost and Usage Report. The key columns are line_item_usage_amount for volume and line_item_net_amortized_cost divided by usage amount for the effective unit price.

Group by service and usage type across two billing periods. For each group, calculate the volume effect and the price effect using the formulas above. Anything left over after accounting for volume and price is mix.

The catch is that a real CUR has tens of millions of rows across hundreds of usage types. Building the grouping and comparison logic in SQL or Python is doable but takes time to get right, and the edge cases add up fast.

If you want to do it manually, that is the right approach for a one-off investigation. If you are finding yourself repeating the same process every time a spike shows up, BillSpike automates the decomposition. Upload your CUR and you get the ranked driver breakdown, with volume and price attribution split out per service, in a few seconds.

The Short Version

Volume variance means you used more. Price variance means you paid more per unit. Mix variance means you shifted toward more expensive options.

When your bill goes up, figure out which one it is before you decide what to do about it. The diagnosis determines the fix.

Analyze your own AWS cost spike at billspike.io