See AWS, Azure & GCP Bills in One Place (No Enterprise Contract)

Tools like CAST AI, nOps, and Spot.io are optimization platforms first and reporting platforms second — their pricing (often a share of the savings they generate, or a percentage of managed cloud spend) reflects an automation product, not a viewing product. If what you actually need is visibility — one place to see what you spent on AWS, Azure, and GCP last month, broken down by service and account — that is a solved problem using tools every cloud provider already gives you for free.

The gap those free tools leave is normalization: AWS, Azure, and GCP each bill differently, label services differently, and export in different formats. Closing that gap used to mean writing custom mapping logic per provider. That is exactly what FOCUS, covered below, was built to standardize — which is why this guide treats it as the centerpiece of a no-vendor multi-cloud view rather than a footnote.

AWS Cost Explorer is built into every AWS account and free to use. It gives you filterable, groupable charts of spend by service, linked account, region, and tag, with up to several years of history depending on when Cost Explorer was enabled on the account. For a single-cloud view, or for spot-checking numbers before you build anything else, start here — no export required.

For a real multi-cloud aggregation, you want the underlying data, not just the UI. That is the Cost and Usage Report (CUR) — AWS's most granular billing export, delivered as files to an S3 bucket you control, updated on a recurring schedule. CUR data includes line-item detail down to individual resource usage, discounts applied, and amortized costs for Reserved Instances and Savings Plans. AWS also supports exporting CUR data in the FOCUS format directly, which matters a great deal for the aggregation approach in this guide (see the AWS Cost and Usage Report documentation).

Once CUR lands in S3, it is queryable directly with Amazon Athena (pay-per-query, no cluster to manage) or loaded into whatever warehouse you're centralizing on. Either way, the data leaves AWS's control the moment it hits your bucket — you own it.

Azure Cost Management + Billing is Azure's free, built-in equivalent to Cost Explorer — cost analysis views, budgets, and basic anomaly alerts, all included with every subscription. For day-to-day Azure-only visibility it's genuinely capable.

The export mechanism you want for aggregation is Azure's scheduled cost export feature inside Cost Management: it writes detailed usage and cost data on a recurring schedule to a storage account (a Data Lake or Blob Storage container) that you own. Azure also supports exporting in the FOCUS format as one of the available export dataset types, which is the detail that makes cross-cloud normalization realistic rather than a custom parsing project. See Microsoft's Azure Cost Management + Billing documentation for the current export configuration options.

From the storage account, the files can be picked up by a pipeline (Azure Data Factory, a scheduled function, or a simple scheduled script) and loaded into your shared warehouse alongside the AWS and GCP data.

GCP takes a different approach from AWS and Azure: instead of writing files to object storage first, Cloud Billing export sends detailed billing data directly into a BigQuery dataset you specify, on an ongoing basis. There are two variants — standard usage cost data, and a pricing/detailed variant with more granular SKU-level pricing information. Because it lands directly in BigQuery, GCP's export is arguably the easiest of the three to start querying with SQL immediately, with no separate load step. Full setup instructions are in Google's Cloud Billing export to BigQuery documentation.

If your warehouse of choice for the unified view is BigQuery, GCP's leg of the pipeline is essentially already done the moment you enable the export — you're just adding AWS and Azure data into the same project.

Here is the part that makes a true single view possible without a vendor: the FinOps Open Cost and Usage Specification (FOCUS), maintained by the FinOps Foundation (part of the Linux Foundation). FOCUS defines a common, provider-agnostic schema — standardized column names, standardized units, standardized definitions for concepts like effective cost, list cost, and billing period — so that a row of AWS billing data and a row of Azure billing data can sit in the same table and mean the same thing.

This directly solves the normalization problem described above. Without FOCUS, "unifying" three clouds' billing data means hand-mapping each provider's own column names and discount logic into something comparable — real, ongoing engineering work that breaks every time a provider changes its export format. With FOCUS, AWS, Azure, and GCP can each export (or be transformed into) the same schema, and your query layer only has to be written once.

As of 2025–2026, all three major hyperscalers have shipped native or near-native FOCUS export support, and the spec itself has moved through multiple point releases with FinOps Foundation governance and hyperscaler participation — genuinely current, active work, not a proposal gathering dust. It is worth reading the specification directly at focus.finops.org before building a pipeline against it, since column definitions and version numbers do evolve.

The practical upshot for a small team: if you can get each cloud's billing data out in (or transformed to) FOCUS format, "one view across AWS, Azure, and GCP" stops being a custom-engineering problem and becomes a UNION ALL across three tables with matching columns.

None of these mechanisms are identical, and the differences matter when you're deciding where to land the data. Here's how the three native exports compare on the facts that actually affect a DIY pipeline:

Qualitative mechanism comparison based on each provider's public documentation (AWS CUR docs, Microsoft Learn Cost Management + Billing docs, Google Cloud Billing export docs). Exact delivery frequency, retention, and FOCUS field coverage change over time — check current provider docs before building a pipeline dependency on specific behavior.

Putting the pieces above together, here's the practical sequence a small team can follow without touching a vendor contract:

None of these four steps individually is hard. What makes the project real work is the combination: three different export mechanisms, three different schedules, error handling when a file doesn't land on time, and keeping the schema mapping correct as providers change their billing categories. Budget it as a multi-day engineering task, not an afternoon.

Two open-source tools come up constantly in this space, and it's worth being precise about what each one actually does — neither is a substitute for the bill-consolidation pipeline above.

OpenCost — Kubernetes cost allocation

OpenCost is a CNCF project (donated by Kubecost) that allocates the cost of a Kubernetes cluster's compute, memory, and storage down to namespace, label, or pod level. It runs inside your cluster and reads Prometheus metrics to attribute cost to workloads. If your multi-cloud footprint includes Kubernetes clusters on more than one provider, OpenCost can give you cost allocation within each cluster — but it does not aggregate your full cloud bill (RDS, S3, networking, etc.) the way a CUR/export pipeline does. Think of OpenCost as a zoom-in tool for container spend, not a zoom-out tool for the whole bill. See opencost.io for the project itself.

Infracost — pre-deploy cost estimates

Infracost solves a different problem entirely: it estimates what a Terraform (or other IaC) change will cost before you deploy it, typically as a comment on a pull request. That's valuable for catching expensive infrastructure changes early, but it has nothing to do with consolidating bills you've already been charged — Infracost estimates spend that hasn't happened yet, while this guide is about seeing spend that already has. Don't conflate the two: a team could run Infracost in CI and still have zero visibility into their actual multi-cloud bill. See infracost.io for details.

Both are excellent tools for what they do. Neither replaces steps 1–4 above.

The DIY path above is real and it works, but it isn't free in engineering time, and it keeps costing time after the initial build — schema drift, pipeline failures, and someone needing to own it. Whether that trade is worth it depends on your team.

DIY tends to make sense when: you already have SQL/data-engineering capability on the team, your reporting needs are relatively simple (spend by provider, service, and month is often enough), and you want full control over the schema and where the data lives.

A paid tool tends to make sense when: nobody on the team wants to own a data pipeline, you need near-real-time anomaly alerts rather than a monthly review, or your reporting needs go beyond spend visibility into recommendations and automated actions (rightsizing, commitment purchase suggestions, and so on) — which is the actual product CAST AI, nOps, and Spot.io are selling, beyond raw visibility.

It's also fine to combine the two: use the native exports and FOCUS for a lightweight, always-on view, and reach for a paid tool later only if the team's spend or complexity outgrows what a spreadsheet-plus-warehouse setup can handle.

This guide describes the current (2025–2026) mechanisms each major cloud provider documents for billing export, and the FinOps Foundation's FOCUS specification as the standardization layer that makes cross-cloud aggregation practical without a vendor. It deliberately avoids inventing specific dollar costs, exact export frequencies, or retention periods for these features — those details change over time and vary by account configuration, so always confirm current behavior against each provider's live documentation before building a dependency on it:

• AWS Cost and Usage Report — docs.aws.amazon.com/cur
• Azure Cost Management + Billing — learn.microsoft.com/azure/cost-management-billing
• GCP Cloud Billing export to BigQuery — cloud.google.com/billing/docs/how-to/export-data-bigquery
• FOCUS specification, FinOps Foundation / Linux Foundation — focus.finops.org
• OpenCost, CNCF project — opencost.io
• Infracost — infracost.io

To compare what AWS, Azure, and GCP would cost you for a given workload before you commit to an architecture, use SpendArk's free cloud cost calculator — it's a planning complement to the billing-history view this guide builds, not a replacement for it.