Optimizing a multi provider estate is a sequencing problem before it is a savings problem. Unify the billing data, cover commitments against a defensible forecast, fix the architecture that drives the bill, then install the governance that holds the saving. Cut before you can see the whole estate and you waste effort and risk over committing.
Stage 1: why start with one billing model?
Across clouds, the first failure is fragmented data. You cannot compare or commit if every provider reports cost in a different shape.
Bring AWS, Azure, GCP, and OCI billing into one normalized model. The FinOps Foundation FOCUS specification standardises billing data across providers, which makes a single source of truth practical rather than a custom data project. With one model you can finally answer the questions that matter across a multi provider estate: what does a unit of value cost on each cloud, where is the same workload cheaper, and which commitments are actually being used.
Stage 2: how do you cover commitments across clouds?
Each cloud sells a different commitment instrument. The strategy is the same: cover the stable base load, flex the rest, and never carry unused commitment.
| Cloud | Primary instruments | Automatic discount |
|---|---|---|
| AWS | Savings Plans, Reserved Instances | none automatic |
| Azure | Reservations, Azure Savings Plan | none automatic |
| GCP | Committed Use Discounts | sustained use discounts apply automatically |
| OCI | Universal Credits, flexible compute shapes | Support Rewards offset support fees |
Coverage is risk adjusted, not discount maximised. Size each commitment to a defensible forecast, because the buyer carries the utilization risk. For the full method, see the cloud commitment negotiation guide.
Stage 3: what drives the bill in each cloud?
Rate moves are finite. The durable savings come from architecture, and the quiet budget eaters differ by provider.
AWS. Graviton and gp3 migrations are standing wins. Data transfer and NAT gateways are quiet budget eaters. The Cost and Usage Report is the source of truth.
Azure. Hybrid Benefit and Dev Test pricing change the math. Log Analytics and Azure OpenAI need their own discipline.
GCP. BigQuery on demand versus capacity pricing is its own discipline. Premium versus standard network tiers matter more than teams expect.
OCI. Flexible compute shapes allow precise sizing. Egress is materially cheaper than the hyperscalers. License included versus BYOL changes database economics.
Stage 4: how do you keep it optimized?
A multi provider estate drifts faster than a single cloud. Governance is what holds the saving.
Install a single operating model that spans every provider: a consistent tagging dictionary, one monthly cadence, guardrails and anomaly alerts wired to each cloud, and unit economics that compare value across providers. Native advisors such as AWS Compute Optimizer, Azure Advisor, GCP Recommender, and the OCI Cost Analysis console recommend but do not decide, so the operating model is where their suggestions become action. See the FinOps operating model guide for how we install it.
This article sits in our multicloud strategy cluster. Start with the pillar, the cloud cost optimization guide, then read the per cloud pillars for AWS, Azure, GCP, and OCI.
Frequently asked questions
What is the right order to optimize a multicloud estate?
How do commitment instruments differ across clouds?
Do native cost tools optimize multicloud spend for us?
How much can a multicloud program save?
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.