A cloud cost driver is a quantity whose change moves cost: instance hours, requests, stored gigabytes, or a business volume such as customers and orders. Knowing the driver behind a cost line lets you explain a change and hand it to whoever can steer it; seeing only the total tells you that it went up and nothing more. Every change splits into three parts: more or less quantity, a different price per unit, and a different mix, meaning a shift towards dearer or cheaper items. Before that comes a simpler question: whether the line shows a trend at all or only noise.
How it works
Trend or noise
Daily data fluctuate for reasons that have nothing to do with consumption. Workloads that run on business days produce a weekly pattern; months have 28 to 31 days; the most recent days are incomplete because providers report usage late (data freshness in cost reports); and purchases show up as spikes in billed cost. AWS, for instance, adds a Savings Plan's recurring fee on the first day of each billing period, and Azure cost analysis shows a reservation purchase on the day of purchase in actual cost and spread over the term in amortized cost.
A trend is therefore a direction that holds across several comparable windows: daily averages per month, seven-day sums in which every weekday appears exactly once, or the same weekday against the same weekday, each in effective cost. A single day out of line is a question for anomaly detection. The consoles keep different amounts of history for this: Cost Explorer by default up to 13 months, hourly for the previous 14 days once enabled; Azure cost analysis daily for up to 92 days and monthly beyond; Google Cloud by usage date back to January 2017.
Quantity, price and mix
FOCUS separates the building blocks. PricingQuantity is the quantity charged in the PricingUnit; ConsumedQuantity is the quantity used in the ConsumedUnit, often finer and filled only on usage rows. ListUnitPrice and ContractedUnitPrice are the list and contracted price per unit, and the specification requires a cost metric to equal its unit price times PricingQuantity. Unit prices hold only within their row and, according to FOCUS, should not be added up to a total. FOCUS has no effective unit price; per SkuPriceId it is EffectiveCost divided by PricingQuantity, and Azure supplies it as the extension x_EffectiveUnitPrice. How the providers name quantity, unit and rate in their exports is covered in usage, rates and line items.
| Effect | What it measures | FOCUS | AWS CUR 2.0 | Azure | Google Cloud |
|---|---|---|---|---|---|
| Quantity | more or fewer units at the same price | PricingQuantity | line_item_usage_amount | Quantity | usage.amount_in_pricing_units |
| Price | a different amount per unit | EffectiveCost ÷ PricingQuantity, ContractedUnitPrice | line_item_net_unblended_rate, line_item_unblended_rate | EffectivePrice, UnitPrice | price.effective_price, plus credits.amount |
| Mix | a shift between items with different prices | SkuId, SkuPriceId, RegionId | line_item_usage_type | MeterId, MeterRegion | sku.id, location.region |
The calculation runs per price item: with q for quantity and p for the effective price per unit, the quantity effect is (q₁ − q₀) × p₀ and the price effect q₁ × (p₁ − p₀). Summed over all items, the two effects give the change exactly. For a group of items in the same unit, such as instance hours of different sizes, the same split can also be calculated with the group's average price. The price effect then differs from the sum of the per-item price effects; the difference is the mix effect. New and discontinued items stand apart, because they have no prior price. How the monthly review builds this split, with exchange-rate and credit effects added, is shown in monthly cloud cost review.
Business drivers
Technical drivers explain the bill; business drivers say whether it is in order. Requests, active customers or orders are the denominator of unit economics: if cost grows at the same rate as the driver, cost per unit stays flat and the increase is growth. If it grows faster, the price per business unit rises and the increase is a question for engineering. The count does not come from the bill but from the product, and it needs the same period and the same scope as the cost.
What it means for your cost
Why did the line move? This sequence rules out the cheap explanations first:
- Cut-off. Is the last day complete, is the month still estimated?
- Calendar and cost basis. The same number of days or daily averages, and the same cost basis on both sides; a purchase in billed cost is not consumption (period comparison).
- Currency. Is it an exchange-rate effect (multi-cloud reporting in one currency)?
- Scope. Has an account, subscription or project been added, or an allocation rule changed?
- Location. Group by service, then account, then usage type or SKU. Azure cost analysis groups by one attribute at a time; Microsoft's workaround is to filter first and then group by the finer attribute.
- Quantity or price. Split per item: if quantity moved, it is consumption; if price moved, a commitment expired, a credit ended or a tier changed; if both held, it is mix or a new item.
- Business driver. Did the business volume move in step?
- Owner and evidence. The cause goes to its owner with a query, a deployment or a contract change as evidence.
Working this way explains a change with figures anyone can recalculate, and it separates what a team can steer (quantity and mix) from what purchasing and contracts decide (price).
Where it goes wrong
- Quantities added across units. Symptom: a service's usage rises by a figure that means nothing. Cause: hours and gigabytes were added up; the Cost Explorer API sums
UsageQuantityregardless of unit, and AWS advises filtering by usage type. - Coverage read as price. Symptom: the unit rate of EC2 hours falls in the Cost and Usage Report, the bill does not. Cause: EC2 and RDS usage covered by Reserved Instances has a
line_item_unblended_rateof 0 and the fee sits in other rows; the price effect belongs in effective cost. - Unit prices summed. Symptom: an average price that matches no invoice. Cause: prices were added or averaged across rows instead of dividing cost by quantity.
- A discount beside the price. Symptom: Google cost falls at the same quantity and the same
price.effective_price. Cause: resource-based and legacy spend-based committed use discounts appear as credits incredits, not in the price. - A weekday taken for a trend. Symptom: a rise is reported every Monday. Cause: workloads run on business days, and Monday was compared with Sunday rather than week with week.
- Mix overlooked. Symptom: quantity and price per service are stable, yet cost rises. Cause: within the service, usage shifted towards dearer items or regions, and the split was only calculated per service.
Sources
Read on 2026-10-16. FOCUS 1.4 Pricing Quantity, Consumed Quantity, List Unit Price, Contracted Unit Price, Effective Cost, Resource Usage and verification, comparison and fluctuation tracking of unit prices; AWS what is AWS Cost Explorer, modifying your chart, GetCostAndUsage and CUR 2.0 line item columns; Microsoft customize views in cost analysis, understand usage details fields and FOCUS cost and usage details file schema; Google Cloud structure of standard data export and Cloud Billing reports.