Most enterprises did not plan to be multi-cloud. It happened: a Microsoft 365 estate pulled in Azure, a product team chose AWS, data science preferred BigQuery, and an acquisition brought another provider. The result is three billing portals, three pricing models and nobody with a complete picture.
This guide explains how to make multi-cloud cost management work in practice.
The result is three billing portals, three pricing models and nobody with a complete picture.
Why is multi-cloud cost management so hard?
- Different billing formats. AWS Cost and Usage Reports, Azure cost exports and GCP BigQuery billing export all use different schemas and terms.
- Different discount models. Savings Plans, Azure Reservations and Google Committed Use Discounts behave differently.
- Different ownership metadata. Tags on AWS and Azure, labels on Google Cloud, plus accounts, subscriptions and projects as hierarchy.
- Different teams. Each cloud often has its own owners who optimise in isolation.
What is FOCUS and why does it matter?
FOCUS (FinOps Open Cost and Usage Specification) is an open standard from the FinOps Foundation that defines a common format and terminology for cloud billing data. Major providers now offer FOCUS-formatted billing data: AWS through Data Exports (FOCUS 1.2), Microsoft through Cost Management exports, Google Cloud through a FOCUS view of its BigQuery billing export, and Oracle Cloud Infrastructure through its own FOCUS reports. Version support and completeness still vary by provider.
Normalising cloud billing data with FOCUS
Illustration in progress
With FOCUS, a column like "BilledCost" or "ServiceCategory" means the same thing regardless of provider, which makes cross-cloud dashboards and allocation much simpler.
How do you build a unified multi-cloud cost view?
- Export billing data from every provider into one data store (for example, a data warehouse or a FinOps platform).
- Normalise to FOCUS or a common internal schema.
- Map hierarchy. Treat AWS accounts, Azure subscriptions and GCP projects as equivalent units.
- Apply one tag schema across tags and labels. See our tagging strategy.
- Build one set of dashboards for executives, finance and engineering.
- Set anomaly detection across all providers, not separately per cloud.
How do you optimise costs on each cloud?
| Lever | AWS | Azure | Google Cloud |
|---|---|---|---|
| Flexible commitment | Compute Savings Plans | Savings plan for compute | Flexible CUDs |
| Resource commitment | Reserved Instances | Reservations | Resource-based CUDs |
| Spare capacity | Spot Instances | Spot VMs | Spot VMs |
| Licence reuse | BYOL options | Azure Hybrid Benefit | BYOL options |
| Recommendations | Compute Optimizer, Trusted Advisor | Azure Advisor | Recommender |
| Automatic discount | — | — | Sustained use discounts (eligible VMs) |
For deeper dives, see our AWS bill guide and Azure checklist.
Should you move workloads between clouds to save money?
Rarely for cost alone. Migration effort, data egress charges, retraining and lost commitment discounts usually outweigh price differences. Instead, make cost a criterion when deciding where *new* workloads run, and optimise existing workloads where they are.
How do you govern multi-cloud spend?
- One FinOps owner or team across all providers
- One review cadence and one set of KPIs
- One commitment calendar showing expiries across clouds
- Policy-as-code guardrails on each provider for tags, Regions and SKUs
How Crozaint approaches multi-cloud costs
Fragmented billing data across provider portals is the first gap our FinOps engagements address. In the Visibility phase (weeks 3–5), Crozaint ingests billing data from AWS, Azure and Google Cloud, builds a single cost allocation model and launches an AI Dashboard where teams can ask questions in plain language across all providers at once.
Crozaint is an AWS Select Consulting Partner, a Microsoft AI Cloud Partner and a Google Cloud Partner, so we optimise each provider natively while reporting centrally. The tools can be deployed inside your own environment if data residency or compliance requires it.
Common mistakes to avoid
- Separate FinOps efforts per cloud with no shared reporting
- Different tag keys on each provider
- Moving workloads between clouds purely for list-price differences
- Ignoring egress costs in multi-cloud architectures
- Tracking commitments in separate spreadsheets
Conclusion
Multi-cloud does not have to mean multi-chaos. Normalise the data, allocate it once, optimise each provider natively and govern centrally.
Running more than one cloud? Book a 30-minute discovery call and get a unified view of your spend.
