A cloud cost data warehouse is a central store that loads the detailed billing exports from AWS, Azure, GCP, and OCI, normalizes them to a common schema such as the FinOps FOCUS specification, joins in tags and business metadata, and serves a BI layer the whole company reads. It exists because four provider consoles cannot answer one cross cloud question, and because finance, engineering, and procurement each need the same numbers cut a different way. Build it on FOCUS so one model spans all four clouds, model cost so unallocated spend is visible rather than hidden, and judge it on a single test: can a team see its own trend and the one lever that moves it. Reporting that passes that test is where most optimization programs actually begin.
This is the layer that turns raw bills into action. Here is what goes into it, how to model it, and how to know it is working.
Why do four consoles fail to answer one question?
Each provider gives you a detailed export: the AWS Cost and Usage Report, Azure cost exports, GCP billing export to BigQuery, and OCI cost reports. Each is rich, and each is shaped differently. The same idea, the cost of a thing before and after discounts, the account it belongs to, the service that produced it, carries a different column name and a different meaning in each one. The moment a CIO asks what the company spent on databases last quarter across every cloud, or which team drove the increase, no single console can answer, because the answer lives in four schemas that do not line up. A warehouse exists to make that question a single query.
What goes into a cost data warehouse?
Three layers, in order. The raw layer lands each provider export unchanged, so you always have the source of truth and can reprocess if a model changes. The normalized layer maps every export to one schema, ideally FOCUS, so amortized cost, list cost, billed cost, service, region, and account mean the same thing everywhere. The semantic layer joins in the human context the bill does not carry: which team owns an account, which product a tag maps to, which environment is production. That last layer is where allocation lives, and it is the difference between a bill and a decision.
| Source export | Provider | Grain it lands at |
|---|---|---|
| Cost and Usage Report | AWS | Hourly or daily line items, with amortized and unblended cost |
| Cost exports / FOCUS export | Azure | Daily usage and purchase records, reservation and savings plan amortization |
| Billing export to BigQuery | GCP | Usage and credit rows, CUD and sustained use discount detail |
| Cost and usage reports | OCI | Resource level usage, Universal Credits drawdown |
The FinOps FOCUS specification matters most here, because it gives all four exports the same column names and the same definitions. One FOCUS model, one set of dashboards, four clouds. Read how the standard works in the FOCUS billing standard explained and how to wire the loads in FOCUS data pipelines in practice.
What should the BI layer actually show?
A dashboard that lists total spend by service is a starting point and rarely changes a decision. Useful reporting answers an owner question. Every team should see its own spend, its trend against last month and against its budget, its unit cost where one exists, such as cost per active customer or cost per thousand requests, and the largest movers since the previous period. Finance needs the same data rolled to the business unit with amortized commitments spread correctly. Procurement needs commitment coverage and utilization so renewals start from fact. The skill is not building more charts, it is building the few that name an owner and a lever.
Open any team dashboard. If a platform owner cannot tell within ten seconds whether their spend is up or down, why, and what they would change this week, the report is decoration. Reporting earns its cost only when it shortens the distance to a decision.
Build, buy, or both?
A FinOps platform stands up fast, maintains the provider connectors, and ships opinionated dashboards, which is why most teams start there. A warehouse you model yourself gives unlimited custom joins, full control of allocation logic, and a home for the bespoke analysis finance and engineering will always ask for. The two are not rivals. A common pattern is a platform for everyday visibility and alerting, plus a FOCUS warehouse for the cross cloud, board level, and unit economics questions a packaged tool cannot anticipate. Weigh the total cost of ownership of either path honestly, including the engineering time a build consumes, as covered in the tooling total cost of ownership.
A European SaaS company ran spend across AWS and Azure with reporting split between two consoles, and no one could state product level margin. We landed both bills into a FOCUS modeled warehouse, joined the team and product mapping from their tagging dictionary, and built three dashboards: a per team trend, a per product unit cost, and a commitment coverage view for procurement. The first month exposed an unallocated slice large enough to fund the work, and the per product view changed where engineering invested next. Figures are verified against billing data and anonymized.
How do you keep the warehouse trustworthy?
A cost warehouse is only as good as the metadata feeding it. Untagged resources land as unallocated spend, and unallocated spend is the number that quietly grows until no report is believed. Treat tag and account coverage as a tracked metric, give the warehouse an owner, reconcile the loaded totals against each provider invoice every month so a broken pipeline is caught fast, and keep the model documented so a new analyst can trust it. Pair the warehouse with a tagging standard, described in the multicloud tagging dictionary, and with single pane reporting principles in single pane reporting across providers.
Frequently asked questions
What is a cloud cost data warehouse?
Why use FOCUS for cost reporting?
Should you build or buy cost reporting?
Turn your bills into reporting that drives savings
We design and model cost warehouses on FOCUS data, build the BI layer your teams will actually use, and tie it to a saving plan, independent of any provider and taking zero provider commissions. Our guarantee: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk.
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.