Multi-Cloud Cost Strategy: Normalize Before You Optimize
Three providers produce three billing formats, three discount systems, and three tagging rulebooks. A strategy has to reconcile them before it can compare them.
A multi-cloud cost strategy is the set of decisions that lets an organization see, compare, and reduce spend across more than one cloud provider as a single estate. Its first job is not optimization. It is making the numbers comparable, because each provider reports cost on a different basis, and a comparison built on mismatched bases produces confident, wrong conclusions.
Where the bills disagree
Cost basis. Providers differ in how commitments show up. In Azure’s Actual Cost dataset, usage that receives a reservation discount has an effective price of zero and the purchase appears as its own record; the Amortized Cost dataset instead prices that usage at the prorated reservation cost. In the Google Cloud BigQuery billing export, sustained use, committed use, and promotional discounts are recorded in a separate credits field, so summing the cost column alone overstates what you pay. If one provider’s figures are amortized and another’s ignore credits, the second will look more expensive than it is.
Currency. Accounts billed in different currencies need conversion at a rate tied to the date of usage, not at today’s rate, or month-over-month trends pick up currency noise.
Discount mechanics. AWS Savings Plans, Azure reservations and savings plan for compute, and Google Cloud’s resource-based and spend-based CUDs are not portable between providers. Each one is sized against that provider’s steady usage only.
Metadata. Google Cloud label keys must be lowercase, 63 characters at most, while AWS tags are case sensitive and Azure tag names are case-insensitive for operations. A tag key that works on one provider can be invalid or split on another. See cloud tagging best practices.
A common data model
The FinOps Foundation’s FOCUS (FinOps Open Cost and Usage Specification) is an open specification that defines requirements for billing data so datasets from different vendors are consistent. AWS Data Exports offers a FOCUS 1.2 export with AWS columns, and Microsoft Cost Management offers a FOCUS file that carries the same data as its actual and amortized files, with a billed cost column and an amortized effective cost column side by side. Where a FOCUS export exists, adopting it removes much of the translation work.
Decisions a strategy should make
- One cost basis for reporting, stated on every report: amortized, or billed.
- One reporting currency, converted with date-specific rates.
- One tag schema that satisfies the strictest provider rules, such as Google Cloud’s lowercase, 63-character label format.
- Commitments per provider, each sized to the always-on baseline on that provider after scheduling and rightsizing.
- One ownership model, so a team’s AWS, GCP, and Azure spend rolls up to the same owner.
- Placement decisions on total cost, including data transfer between clouds, not on unit compute price alone. See data transfer costs.
How ZopNight handles normalization
ZopNight reads billing from AWS Cost Explorer or an opt-in CUR 2.0 export, Azure Cost Management, and the GCP BigQuery export. It reports AWS at unblended cost, uses amortized cost for Azure so reservation and savings plan purchases land on the resources that used them, and folds GCP credits into each row so costs are net of credits. Totals that span providers are labelled “Mixed (by provider)” so the basis is visible. It converts currencies with date-specific exchange rates. Billing lines that match no discovered resource are kept as unattributed spend so org totals reconcile with the invoice. Scheduling, recommendations, and team and tag showback then work across the three providers from one inventory.
Related: multi-cloud management and AWS vs GCP vs Azure costs.