Multi-cloud cost management: one model for AWS, Azure and Google Cloud

Why three consoles are not a cost model

AWS Cost Explorer, Azure Cost Management and the Google Cloud billing reports are each good at their own bill. Each groups by its own containers, names services in its own terms, applies its own discounts at its own level, and exports in its own schema. Put a finance reader in front of all three and the first question, “what did the payments product cost us last month?”, needs three answers and a spreadsheet to add them up.

Flexera’s 2026 State of the Cloud report found 85% of organizations naming cloud spend management their top challenge, ahead of security, and most enterprises running more than one public cloud. The two facts are related. A cost that exists in three vocabularies is hard to own, and a cost nobody owns is hard to manage. The multi-cloud problem is not that there are three bills. It is that there is no single place where a consumer’s cost is one number.

What differs between the three bills

None of these differences is hard on its own. Together they mean that a naive union of three exports double-counts discounts, misses ownership on two of the three, and reports one provider in a different currency. Normalization is the step that turns three exports into one ledger where a row means the same thing regardless of its source.

FOCUS: the common vocabulary

The FinOps Open Cost and Usage Specification, FOCUS, is the FinOps Foundation’s open schema for billing data. It defines one set of columns, such as billed cost, effective cost, service category, charge category and the resource and account identifiers, with one meaning across providers. All three major providers now publish exports in the FOCUS format alongside their native ones.

FOCUS solves the vocabulary problem. It does not solve allocation: a FOCUS row still has to be mapped to a department, a product or a customer, and shared costs still need a driver. What it removes is the translation layer that every organization used to build by hand, and it makes the normalized ledger something a new tool, a new analyst or an auditor can read without a glossary.

One allocation, three inputs

1. Normalize. Load each provider’s detailed export, FOCUS where available, into one ledger with one currency and one set of columns. Reconcile each provider’s rows to its own invoice before combining anything; a ledger that does not reconcile per provider will not reconcile in total.
2. Map the containers. Accounts, subscriptions, resource groups and projects each map to an owner. This is the first dimension on all three clouds and the most reliable, because a container has exactly one owner by construction.
3. Unify the tags. Define one owner key and one product key, and map each provider’s tags and labels, with their different casing and value sets, to it. Treat an invalid value as missing and report it.
4. Share across clouds. A shared platform can span providers: a Kubernetes control plane on one cloud, a data warehouse on another, a network between them. Its driver is measured once and applied to its cost on every cloud.
5. Allocate commitments per provider. Discounts apply where each provider applies them; allocate the discounted rate to the covered usage on that provider and carry unused commitment centrally, by provider.
6. Report by consumer, not by cloud. The statement a department receives shows its total with a per-provider split, so the cloud is an attribute of the cost rather than the organizing principle.

Commitments across clouds

Commitment decisions are per provider, but the question behind them is not. A team deciding where to run a workload wants the effective price on each cloud after the discounts the organization already holds, and finance wants to know the total committed spend and its expiry schedule across all three. Both need the commitments in the same ledger as the usage they cover.

The failure mode is a reservation bought on one cloud for a workload that moved to another, discovered at expiry. A single commitment schedule with coverage per provider, next to the forecast, is the fix, and it is only possible when the three bills are already one.

Reporting that finance can use

• One statement per consumer with the total first and the per-provider split second; the reader asked what the product cost, not which cloud it ran on.
• Effective cost and list cost side by side, so the organization’s negotiated and committed discounts are visible rather than silently applied.
• One currency, converted at the rate the finance system uses, with the original billing currency retained on the row for audit.
• The unallocated remainder by provider and by cause, because tagging maturity differs across clouds and the fix is different for each.
• Forecasts and anomalies at the consumer level across clouds, from the same ledger, so a workload that moved between providers does not appear as a drop on one and a spike on the other.

Common mistakes

• Adding up three console totals in a spreadsheet and calling it a multi-cloud report. Discounts are double-counted or lost and nothing reconciles.
• Organizing the report by cloud first. Finance owns products and departments, not providers.
• Three tagging standards. One owner key, mapped from each provider’s metadata, with the invalid values reported.
• Ignoring currency until the numbers do not add up to the invoice.
• Treating FOCUS as the finish line. It is the vocabulary; allocation is still the work.
• Buying tools per cloud for a problem that exists between the clouds.

How Runcost handles multi-cloud

Runcost ingests the AWS, Azure and Google Cloud detailed exports, FOCUS files included, into one FOCUS-compatible ledger, reconciles each provider to its invoice, and maps containers and tags from all three to one set of owners, products and customers. Shared services can span providers, commitments are allocated where each provider applies them, and every statement, forecast and alert is produced per consumer with the cloud as an attribute of the cost.