Why did my cloud bill go up?

For anything billed in both periods, a cost changes because you used more or less of it, or because each unit cost more or less.

On top of that, services can be new or removed, scope and credits can change, and some charges have no quantity to split at all. The Cloud Bill Diff shows each of those as its own line, so the parts add up to the total change.

The decomposition

For any line where you know cost and quantity in both periods, the effective unit rate is p = cost / quantity. The change in cost then splits exactly:

Δcost  = cost_after − cost_before

rate   = (p_after − p_before) × (q_before + q_after) / 2
usage  = (q_after − q_before) × (p_before + p_after) / 2

rate + usage == Δcost      exactly, with no residual

This symmetric form is deliberate. The version taught in most finance courses, (p₁−p₀)·q₀ plus (q₁−q₀)·p₀, leaves an interaction residual that has to be displayed, hidden, or arbitrarily assigned to one side. Every one of those choices confuses somebody. The symmetric split always reconciles, which matters more than tradition when the audience is an engineer who will check your arithmetic.

A worked check: 1,000 units at $0.10 ($100) becoming 1,500 units at $0.12 ($180) is an $80 rise. Usage first would say $50 usage and $30 rate, rate first $60 and $20; the symmetric split used here says $55 usage and $25 rate. All three are valid conventions; this tool uses the symmetric one everywhere. A new or removed item has no price in one period, so none is invented: it is its own line, as is a charge with no quantity.

Why it only works at SKU level

An effective rate is only meaningful where the pricing unit is constant. GB-months, vCPU-hours, requests, and tokens cannot be added together, so “total quantity for Amazon EC2” is not a number; it is several different numbers stacked on top of each other.

The rule that follows is simple and is where most homegrown versions of this analysis go wrong: decompose at the SKU, then sum the effects upward. Never recompute a rate from an aggregate quantity. A service-level rate derived that way will move whenever the mix of SKUs inside it moves, and will confidently attribute a mix shift to a price change that never happened.

Reading the five shapes

Usage up, rate flat

You are consuming more of the same thing at the same price. This is normal growth, the question is whether it is proportional to whatever the business got in return.

What to do: Trace it to a team and a workload. If the growth is intended, forecast it. If it is not, this is where rightsizing and idle-resource cleanup pay.

Rate up, usage flat

You are consuming exactly the same thing and paying more per unit. This is almost never something engineering did. It is an expired Reserved Instance or Savings Plan, a committed-use discount that lapsed, a negotiated rate that ended, or a pricing tier crossed the wrong way.

What to do: Check commitment coverage and expiry dates first. This shape has the shortest path from diagnosis to fix of any finding on a cloud bill.

Rate down, usage up

Often a success story mid-flight: a commitment kicked in or you crossed into a cheaper volume tier while growing. The total may still be up.

What to do: Confirm the rate drop is structural rather than a one-off credit, then use the new unit economics in your forecast.

New SKUs appear

Spend that did not exist in the first period at all. A new service, a new region, a new instance family, or a migration in progress.

What to do: The rate/usage split does not apply; there is no prior rate to compare. Ask what was deployed and whether the old thing was turned off.

Cost moves with no quantity

Flat fees, support charges, and some marketplace items carry no quantity, so no rate exists to decompose.

What to do: Reported separately as unattributable rather than forced into a bucket. Support in particular moves because everything else did.

Three corrections to apply first

Normalize the period. Comparing a 28-day February to a 31-day March invents an 11% increase out of the calendar. Compare per-day figures, or compare equal windows.
Exclude one-off purchases. A Reserved Instance bought upfront is a cash event, not a change in run rate. Analyze usage charges, and show tax, credits, and purchases as separate reconciling lines that always sum back to the raw total.
Use amortized cost. On unblended cost, a commitment purchase lands as a spike in the month it was bought and the months it covers look artificially cheap. Amortized (or FOCUS EffectiveCost) spreads it correctly.

Run this on your own two exports → No login, and the file is read in your browser.

The answer is more useful before the invoice than after it.

Finitizer runs this decomposition daily across AWS and Google Cloud, and tells you which movements are worth a conversation, with the resource and owner already attached.

See how Finitizer works