48.3k Log in Get started
Dashboard

What does an infrastructure cost dashboard show in Metabase?

An infrastructure cost and utilization dashboard shows where capacity and spend concentrate, and where they're wasted — utilization against requests, cost by service, and the idle resources nobody remembers. It combines snapshots and billing data from platforms such as Kubernetes, Amazon ECS, Amazon EKS, and GKE.

For: Platform engineers, engineering leadership, and finance partners. Grain: one row per workload per day (snapshots), plus cost allocations per service per day.

Which cards belong on an infrastructure cost dashboard?

  • CPU and memory utilization vs. requests by workload (bar)
  • Cost by service or namespace, trailing 30 days (bar)
  • Cost trend by month with forecast (line)
  • Over-provisioned workloads — low use, high cost (table)
  • Idle or unattached resources (table)
  • Node or instance count by cluster over time (line)
  • Cost per request or per tenant where the join exists (line)

What data does the dashboard need?

  • resource_snapshots — daily requested vs. used CPU and memory per workload, cluster, and namespace.
  • cost_allocations — spend by service, namespace, or cluster per day, from your cloud billing export (AWS CUR, GCP Billing → BigQuery) or cost tooling.
  • services with owners and teams, so cost lands on a roadmap, not a shrug.

How do you build it?

  1. Land daily snapshots from kube-state-metrics/Prometheus or the platform APIs (see the Kubernetes guide for routes).
  2. Enable cost allocation at the source — GKE cost allocation, AWS split cost allocation, or a tool like OpenCost — and export it daily.
  3. Join usage and cost on service and day; normalize service names across platforms first.
  4. Build the over-provisioned table first — it's where the money is — then trends and per-team views.

Example card SQL

Expensive, under-utilized workloads (candidates for right-sizing)PostgreSQL
SELECT
  s.workload_name,
  ROUND(AVG(s.cpu_used_cores / NULLIF(s.cpu_requested_cores, 0)) * 100, 1)
    AS avg_cpu_utilization_pct,
  ROUND(SUM(c.cost_usd), 2) AS cost_usd_30d
FROM resource_snapshots s
LEFT JOIN cost_allocations c
  ON c.service_name = s.workload_name
  AND c.usage_date = s.snapshot_date
WHERE s.snapshot_date >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY s.workload_name
HAVING AVG(s.cpu_used_cores / NULLIF(s.cpu_requested_cores, 0)) < 0.3
ORDER BY cost_usd_30d DESC;

Metrics

Resource utilizationService availabilityDeployment frequency

Integrations

Kubernetes + MetabaseAmazon ECS + MetabaseAmazon EKS + MetabaseGKE + Metabase

Dashboards

Service availabilityIncident response

FAQ

What is an infrastructure cost dashboard?
An infrastructure cost dashboard shows where capacity and spend concentrate — and where they're wasted. It joins daily resource utilization snapshots from platforms like Kubernetes, Amazon EKS, or GKE with cost allocations from cloud billing, so over-provisioned workloads, idle resources, and cost trends land in one governed view that platform engineers and finance partners read the same way.
What data sources feed an infrastructure cost dashboard?
Two feeds, joined on service and day. Usage comes as daily resource_snapshots — requested vs. used CPU and memory per workload — from kube-state-metrics via Prometheus or the platform APIs of Kubernetes, Amazon ECS, and GKE. Spend comes as cost_allocations from the billing export — AWS CUR, GCP Billing to BigQuery — or tooling like OpenCost. Normalizing service names across the two feeds is most of the work.
Is high utilization good or bad?
Both, depending on the target. Very low utilization is money spent on nothing; very high utilization is a reliability risk with no headroom for traffic spikes or node failures. Judge each workload against an explicit capacity target — often 50–70% for latency-sensitive services, higher for batch — rather than a single "higher is better" scale, and read utilization next to the service availability dashboard so right-sizing never buys savings with an outage.
Where does the cost data come from?
From the platform's billing export: AWS Cost and Usage Reports (with split cost allocation enabled for EKS), GCP Cloud Billing export to BigQuery (with GKE cost allocation enabled), or tooling like OpenCost for any Kubernetes cluster. Whichever source you use, land it as a daily cost_allocations table keyed by service or namespace — shared, untagged spend needs an explicit allocation rule, or it quietly distorts every per-team number.
How often should infrastructure cost be reviewed?
Monthly is the wrong default — by the time the bill lands, the over-provisioned quarter is already paid for. Review the over-provisioned-workloads table in the platform team's weekly ops rhythm, alongside utilization and the availability view, and keep the monthly cost-trend review for leadership and finance. Daily snapshot grain makes both cadences work from the same resource_snapshots and cost_allocations tables.