Why did my cloud bill go up?
A cloud bill can only rise for two reasons: you consumed more, or you paid more per unit. Everything else — a new service, a lapsed discount, a region change, a tier crossing — is one of those two wearing a costume. Separating them is the whole job, and most tools never do it.
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 residualThis 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.
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
- Normalise 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. Analyse 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.
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.