What is cloud cost analytics, and how do you build it in Metabase?
Cloud cost analytics turns billing exports, tags, commitments, and allocation data into shared metrics about what your infrastructure costs — and what a unit of your business costs to serve. The FinOps industry sells costvisibility; the durable advantage is unit economics: cost per customer and per feature, built in your own BI on raw billing data, next to the revenue tables that give cost a denominator.
TL;DR — Billing data is the easiest operational data you'll ever warehouse: AWS exports CUR 2.0 to S3 (query via Athena), Google Cloud writes straight into BigQuery. Model four layers — cost rollups, allocations, commitments, unit costs — and keep amortized vs. unblended cost as explicit, labeled columns.
What does cloud cost analytics measure?
- What are we spending, and which services and teams drive the trend?
- Is spend growing faster or slower than customers and revenue?
- Are Savings Plans and committed use discounts actually saving money?
- How much of the bill does nobody own (untagged spend)?
- What does Kubernetes really cost, per namespace and team?
- What does each customer or feature cost to serve — and at what margin?
- When spend spikes, how fast do we notice and respond?
Which tools feed cloud cost analytics?
| Tool | Best for | Getting data into Metabase |
|---|---|---|
| AWS Billing | Cloud spend overview by service and account; Commitment coverage and Savings Plans utilization | AWS Data Exports (CUR 2.0), pipeline, or AWS Billing and Cost Management MCP Server for exploration |
| Google Cloud Billing | Cloud spend by project and service; Committed use discount coverage | Cloud Billing BigQuery export, pipeline, or BigQuery remote MCP server for exploration |
| Vantage | Multi-cloud spend overview; Cost by team from virtual tags | Vantage API (VQL), pipeline, or Vantage MCP for exploration |
| Kubecost | Kubernetes cost by namespace and workload; Cost allocation by team and label | Kubecost Allocation API, pipeline, or OpenCost MCP server for exploration |
| CloudZero | Cost per customer and per feature; Spend by CloudZero dimension | CloudZero API, pipeline, or CloudZero MCP Server for exploration |
| Kubernetes | Utilization joined to cost | kube-state-metrics, Prometheus, or cost tooling |
| Datadog | Usage and observability cost signals | API, connector, or Datadog MCP |
What shared data models should you build?
Build clean models on top of raw billing tables so each dashboard uses the same definitions.
billing_line_items— the atomic layer: one row per export line item, with pricing model, tags, and line-item type preservedcost_daily_rollups— one row per service per account per team per day, with amortized, unblended, and net cost as separate columnscost_allocations— spend mapped to teams and products via the tag-to-owner mapping, with an explicit untagged bucketcommitments— one row per Savings Plan, RI, or CUD, with term, scope, utilization, and expirationk8s_allocation_rollups— namespace and workload cost per day, idle and unallocated cost broken outunit_costs— cost per customer or feature per month, joined to revenue where availablebudgets— budget per scope per period, for burn and variancecost_anomaly_events— detector output with expected vs. actual cost and response timestamps
Which cloud cost metrics matter most?
- Total cloud spend — spend per period under one stated convention, credits separate.
- Cost growth rate — month-over-month change, attributed to services and compared to business growth.
- Commitment coverage rate — covered share of eligible spend, always read with utilization.
- Effective savings rate — the honest single number for commitment-program health.
- Untagged spend rate — the ceiling on every allocation and chargeback view.
- Budget burn rate — budget consumed vs. period elapsed, the early-warning pace metric.
- Cost per service — provider and application services, mapped deliberately.
- Cost per customer — allocated cost joined to revenue: the unit-economics headline.
How do you connect tools to Metabase?
- Billing exports first — CUR 2.0 to S3 + Athena, or the Cloud Billing export into BigQuery. The cloud maintains the pipeline.
- MCP + CLI — vendor MCP servers for scoped live questions,
mb upload csvfor quick analysis. - Platform syncs — Vantage, Kubecost, and CloudZero data via connector or API where their allocation engines add depth, reconciled to raw exports.
Which dashboards should you build first?
- Cloud spend overview — total spend, breakdowns, growth, and budget burn.
- Cost allocation by team and tag — ownership with the untagged bucket visible.
- Commitment coverage — coverage, utilization, and expirations together.
- Cost anomalies — spikes as an operational queue, not a surprise invoice.
- Kubernetes cost— namespace and workload cost with idle share.
- Cost per customer — the unit-economics view, with revenue joined.
Adjacent legacy guides: AWS monitoring, multi-cloud, storage costs, and cost performance indicators, plus infrastructure cost from the observability cluster.
Common mistakes
Reporting spend without naming the cost convention.→ Amortized, unblended, and net-of-credits answer different questions. Label every card; keep the conventions as separate model columns.
Building allocation dashboards on poor tag hygiene.→ Track the untagged spend rate first — allocation views are only as true as tag coverage, and pretending otherwise erodes trust.
Judging cost growth without a business denominator.→ Spend growing slower than revenue is healthy scaling. Always pair growth with customer, usage, or revenue trends.
Treating platform numbers as invoice-grade truth.→ Allocation engines distribute costs over assumptions. Reconcile platform totals against raw billing exports on a schedule.
Skipping the revenue join.→ Cost per customer without margin is half a metric. Join revenue in the warehouse — that's the whole point of building this in BI.
Related
Integrations
Analytics
Terms
FAQ
What is cloud cost analytics?
Cloud cost analytics is the practice of turning billing data — line items, tags, commitments, and anomalies — into governed, shareable business metrics. Where cost consoles answer "what did we spend yesterday?", cost analytics answers "which teams and features drive spend, is our commitment program working, and what does each customer cost to serve?" In Metabase, you build it on billing exports from AWS and Google Cloud landed in a SQL warehouse, with platforms like Vantage, Kubecost, and CloudZero layered where they add allocation depth.
What is the difference between cloud cost analytics and FinOps?
FinOps is the operating practice — the rituals, ownership, and rate-optimization work of managing cloud spend. Cloud cost analytics is the reporting layer that practice runs on: the shared metrics, dashboards, and unit-economics views. FinOps platforms optimize rates and surface recommendations; your BI layer is where cost meets revenue, customers, and product data — and where the whole company can read it without per-seat platform licenses.
Why build cost dashboards in a BI tool instead of the FinOps platform?
Three reasons. Joins: unit economics needs cost next to revenue, customers, and usage — tables that live in your warehouse, not the cost platform. Governance: metric definitions (amortized vs. unblended, shared-cost rules) become certified models everyone shares. Reach: dashboards go to every team lead and finance partner without extra platform seats. The platforms stay valuable for what they're built for — rate optimization, recommendations, and allocation engines.
Which metrics should a cloud cost dashboard track?
Start with the spend core: total cloud spend under one stated convention, cost growth rate attributed to services, and budget burn rate per team. Add the efficiency pair — commitment coverage rate and effective savings rate — plus untagged spend rate to keep allocation honest, and graduate to cost per service and cost per customer for unit economics.
What data do I need to get started?
One table: daily cost rollups by service, account, and team from a billing export — that powers the cloud spend overview on day one. AWS teams create a CUR 2.0 Data Export to S3 and query it with Athena; Google Cloud teams enable the BigQuery billing export and connect BigQuery directly. Commitments, budgets, Kubernetes allocations, and customer mappings join the model as the questions arrive.
How do I measure cost per customer?
Allocate direct costs via tags or tenancy mapping, distribute shared costs by an explicit rule (usage-based where possible), and join revenue per customer from billing or the CRM. CloudZero automates the allocation side with its dimensions model; the revenue join happens in your warehouse. See cost per customer for the SQL pattern and the unit economics dashboard for the full card list.
Can I build cost dashboards without a data warehouse?
For a first pass, yes: pull a summarized cost slice through a vendor's MCP server — AWS's billing MCP, Vantage's, or CloudZero's — and load it with the Metabase CLI (
mb upload csv). That works for spot-checks and one-off investigations. Durable cost reporting wants the billing export in a warehouse: history, scheduled refreshes, and definitions people can trust. Every integration guide documents both routes.