A cloud cost baseline is a normalised reference figure for your spend over a representative period, broken down by service, account, and team, that every future change is measured against. It is the first thing to build before any optimization, because savings claims are meaningless without an agreed number to compare against. Build the baseline from actual net cost in your billing data, the Cost and Usage Report on AWS and its equivalents on Azure, GCP, and OCI, across at least three full billing months so it absorbs month end batch and seasonal swings. Then attach a unit metric, cost per customer or per transaction, so the baseline survives growth and tells you whether spend is rising for good reasons or bad.
Here is how to build one that finance and engineering both trust: the data source, the normalisation steps, the breakdown, and the unit metric that makes it durable.
Why does a baseline come before optimization?
Optimization without a baseline is a series of unverifiable claims. A team rightsizes an instance and says it saved money, but saved against what? If spend then rises because traffic grew, did the optimization work or not? A baseline answers these questions by fixing a reference point. It also exposes the shape of the bill, which services dominate, which accounts are growing fastest, where the long tail of small charges adds up, so the first wave of optimization targets the pools that actually matter rather than whatever is most visible. The 31 percent median reduction we see in the first 90 days of an engagement starts here, because you cannot reduce what you have not first measured.
What data should the baseline use?
Use the authoritative billing export, not a dashboard summary. On AWS that is the Cost and Usage Report; Azure exposes cost exports in the FOCUS format; GCP has billing export to BigQuery; OCI has its cost and usage reports. Three rules keep the data clean.
- Net, not list. Baseline on actual cost after discounts, Savings Plans, Reservations, CUDs, and Universal Credits, because that is the money leaving the business. Keep list price separately to measure what your commitments save.
- Amortised, not lumpy. Spread upfront commitment payments across their term so a single month is not distorted by a one time charge. This is what makes month to month comparison meaningful.
- Tagged, or honestly untagged. Allocate cost to team and service by tag, and measure the unallocated remainder explicitly. A baseline that hides a large untagged pool is not a baseline you can manage against.
How do you normalise across an uneven period?
Raw monthly totals jump around for reasons that have nothing to do with efficiency: a leap in traffic, a migration, a one off data transfer. Normalise by amortising commitments, excluding clearly one off charges and noting them separately, and dividing by a unit of business value. A cost per active customer or per thousand transactions converts an absolute number that only ever grows into a ratio that tells a story. If absolute spend rises 20 percent but cost per customer falls, the platform is getting more efficient even as the bill grows. That distinction is the single most useful output of a baseline and the one finance leaders care about most.
A worked example
A Fortune 500 retailer had three clouds and no agreed spend number, so every optimization debate stalled on whose figure was right. We pulled three months of net, amortised billing data from AWS, Azure, and GCP into one model, allocated 86 percent of it to teams by tag, and flagged the 14 percent untagged remainder as the first cleanup target. We then divided total spend by monthly active customers to get a unit cost. With that baseline agreed, the first optimization wave could be measured precisely: rightsizing and idle cleanup cut the unit cost while absolute spend stayed flat through a growth quarter. The baseline turned a circular argument into a managed program. Figures are verified against billing data and anonymised.
How do you keep the baseline alive?
A baseline is not a one time snapshot. Rebase it on a fixed cadence, typically quarterly, so it tracks a changing estate, and always record why it moved: new product, migration, commitment renewal, or genuine efficiency. Pair it with anomaly detection against the same data so a regression shows up in hours rather than at the next bill. Done this way the baseline becomes the spine of a FinOps operating model, the agreed number that budgets, forecasts, and savings claims all hang from. Get the baseline right and everything downstream, allocation, forecasting, and accountability, has solid ground to stand on.
Frequently asked questions
What is a cloud cost baseline?
How long a period should a baseline cover?
Should a baseline use list price or actual cost?
Start with a baseline you can defend
Our playbook walks through building a baseline that finance and engineering both trust, across AWS, Azure, GCP, and OCI, with zero provider commissions and only your interests on the table. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on a Fixed Fee or a no risk Gainshare basis. Download the guide, then read the cross cloud cost optimization guide for the full program.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.