What goes in a multi-cloud dashboard in Metabase?

A multi-cloud dashboard governs AWS, GCP, and Azure in one view: spend by provider and its month-over-month movement, workload distribution, utilization, SLA comparison, tagging compliance, and egress costs. It is the breadth view that the cost-focused cloud spend overview and the provider-deep AWS monitoring dashboard drill out of.

What does a multi-cloud dashboard look like?

Here’s the layout this guide builds. Governance scalars and the attention card lead with the numbers a review meeting opens on; spend and egress come next, including a waterfall that names which provider drove the month’s change; workloads and reliability close the page — where things run, how hard they work, and which provider kept its SLA.

Which cards belong on a multi-cloud dashboard?

The eight below keep the three providers comparable in the four dimensions governance cares about: money, placement, efficiency, and reliability.

• Monthly spend by provider (stacked bar)
• Month-over-month spend change by provider (waterfall)
• Egress cost by provider, monthly (line)
• Tagging compliance by provider — share of spend tagged (bar)
• Workload distribution by provider (donut)
• Utilization by provider — CPU and memory (row)
• SLA attainment by provider, weekly, from your own monitoring (line)
• Top workloads by spend, with provider, team, and month-over-month movement (table)

What data does the dashboard need?

• A normalized_billing table — invoice_month, provider, account, service, usage_category, team_tag, cost — built from the AWS CUR, the GCP billing export, and the Azure cost export.
• An egress flag or usage category on billing rows, so transfer costs can be separated per provider.
• A workload inventory — service, provider, team — from your infrastructure catalog or Terraform state.
• Utilization rollups (CPU, memory) per provider from your monitoring stack, snapshotted weekly.
• Uptime probes measured identically across providers, for the SLA comparison.

How do you build it?

1. Land all three billing exports in the warehouse — see the AWS billing and Google Cloud billing guides — and normalize them into one table with shared columns and tag keys.
2. Classify egress rows per provider from each export’s usage categories, so the egress line is computed rather than estimated.
3. Join the workload inventory and weekly utilization snapshots on provider and service, keeping one row per workload per week.
4. Compute SLA attainment from your own probes with one downtime definition across providers — never from the providers’ published numbers.
5. Add filters for provider, account, and date range, and review the waterfall and untagged-share cards in the monthly cost meeting.

Example card SQL

SELECT
b.invoice_month,
b.provider,                                           -- 'aws' | 'gcp' | 'azure'
ROUND(SUM(b.cost), 0)                                 AS total_cost,
ROUND(SUM(b.cost) FILTER (
  WHERE b.usage_category = 'egress'
), 0)                                                 AS egress_cost,
ROUND(
  100.0 * SUM(b.cost) FILTER (WHERE b.team_tag IS NULL)
    / NULLIF(SUM(b.cost), 0), 1
)                                                     AS untagged_pct,
ROUND(
  SUM(b.cost) - LAG(SUM(b.cost)) OVER (
    PARTITION BY b.provider ORDER BY b.invoice_month
  ), 0
)                                                     AS mom_change
FROM normalized_billing b
WHERE b.invoice_month >= date_trunc('month', now()) - interval '6 months'
GROUP BY 1, 2
ORDER BY 1, 2;

Related

Metrics

Integrations

Dashboards

FAQ