Running workloads across AWS, Azure and Google Cloud gives you flexibility and leverage, but it almost always costs more than teams expect. Multi-cloud cost optimization is the practice of seeing, allocating and reducing that spend across every provider at once, instead of optimizing each bill in isolation. This guide walks through the steps in the order that works in practice: visibility first, then allocation, then the discounts and architecture changes that actually cut the bill.
Why Multi-Cloud Costs More Than Expected
Each provider’s bill can look reasonable on its own while the total quietly grows. The usual causes:
- Data egress. Moving data between clouds is billed as internet egress on the sending side. Chatty services split across providers can generate a surprising line item.
- Split commitments. Spreading usage across three providers means smaller committed-use discounts with each, and more risk of paying for commitments you don’t use.
- Duplicated tooling. Separate monitoring, logging, security and support plans per cloud.
- No single view. Three billing consoles, three data formats and three tagging schemes make it hard to answer a basic question: what does this product cost to run?
Step 1: Get One View of Spend
Multi-cloud cost management starts with getting every provider’s billing data into one place, at line-item detail:
| Provider | Detailed billing export | Lands in |
|---|---|---|
| AWS | Data Exports (Cost and Usage Report 2.0 or FOCUS format) | S3 |
| Azure | Cost Management exports (including FOCUS format) | Storage account |
| Google Cloud | Cloud Billing export | BigQuery |
The hard part is that each provider names things differently. The FinOps Foundation’s FOCUS specification (FinOps Open Cost and Usage Specification) solves that: it defines one common schema for billing data, and all three major clouds now offer FOCUS-format exports. Load those into one warehouse and a single query or dashboard can cover every provider.
Step 2: Allocate Every Dollar
Visibility without ownership doesn’t change behavior. Decide on a small set of required tags (labels on Google Cloud), use the same keys everywhere, and enforce them:
| Key | Example | Answers |
|---|---|---|
team | payments | Who owns this spend? |
product | checkout-api | What does this product cost? |
env | prod / staging / dev | How much goes to non-production? |
cost-center | CC-1042 | Which budget pays for it? |
- Enforce tags at creation time: AWS Tag Policies and SCPs, Azure Policy, and Terraform validation in your pipeline for all three.
- Track percentage of spend allocated as a metric. Untagged spend is where waste hides.
- For shared costs (Kubernetes clusters, networking, support plans), agree on a split rule up front rather than arguing about it each month. OpenCost can break Kubernetes costs down by namespace and workload on any cloud.
Step 3: Right-Size and Clean Up
Each cloud has a free recommendation engine; use all of them:
- AWS Compute Optimizer for EC2, EBS, Lambda and ECS right-sizing.
- Azure Advisor cost recommendations.
- Google Cloud Recommender for idle and oversized VMs, disks and IP addresses.
Beyond right-sizing, look for unattached disks, old snapshots, idle load balancers and unused IP addresses. These are small individually and add up fast across three clouds.
Step 4: Use Commitments Where Usage Is Steady
| Provider | Commitment options | Automatic discounts |
|---|---|---|
| AWS | Savings Plans, Reserved Instances | None for on-demand compute |
| Azure | Reservations, Savings Plan for Compute | None for on-demand compute |
| Google Cloud | Committed use discounts | Sustained use discounts on eligible VMs |
Commit only to the baseline you’re confident in, and watch two numbers per provider: coverage (how much eligible usage is under a commitment) and utilization (how much of what you committed you actually use). This is where multi-cloud hurts most: if a workload might move between clouds, keep it on flexible pricing until it settles.
Step 5: Design Around Egress
Architecture decisions often matter more than any discount:
- Keep services that talk to each other constantly in the same cloud and region.
- Replicate data deliberately rather than reading it across clouds on every request.
- For steady, high-volume cross-cloud traffic, compare dedicated interconnects (AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect) with internet egress pricing.
- Put a CDN in front of public content so origin egress shrinks.
Step 6: Automate Schedules and Scaling
Development and test environments rarely need to run nights and weekends. Scheduling them off for roughly 12 hours a day and all weekend removes well over half of their compute hours. Combine that with autoscaling on production, and with spot or preemptible capacity for fault-tolerant batch work.
Multi-Cloud Cost Optimization Tools
You can get a long way with native exports, a warehouse and a dashboard. Commercial multi-cloud cost management platforms add normalized reporting, anomaly alerts and commitment management out of the box, which is often worth it once spend is large enough. Whichever route you choose, check that the tool reads FOCUS or each provider’s detailed export, supports your tagging scheme, and can allocate Kubernetes costs. Tools built only on summary-level billing data are the usual source of “unreliable” cost allocation numbers.
Metrics to Track
- Unit cost, such as cost per customer, per transaction or per environment. This tells you whether spend is growing faster than the business.
- Allocated spend %: target 90% or more.
- Commitment coverage and utilization per provider.
- Egress as a share of total spend.
- Non-production share of spend.
Common Multi-Cloud Cost Management Mistakes
- Optimizing each cloud separately. Three teams each saving 10% on their own bill can still miss that the biggest cost is the data moving between them.
- Buying commitments before allocation is in place. Without knowing who owns the usage, nobody is accountable when a commitment goes unused.
- Treating tags as optional. Untagged resources created “just for a test” are a reliable source of long-lived waste.
- Ignoring support and marketplace charges. Premium support plans and marketplace subscriptions are billed per provider and are easy to leave out of the comparison.
- Reporting totals instead of unit costs. A growing bill can be healthy if cost per customer is falling; a flat bill can hide a product that is getting more expensive to run.
A 30-Day Starting Plan
- Week 1: turn on detailed (ideally FOCUS) billing exports for every provider and load them into one place.
- Week 2: agree on required tags, enforce them for new resources, and backfill the largest untagged spend.
- Week 3: act on the right-sizing recommendations and clean up idle resources; schedule non-production environments.
- Week 4: review steady baseline usage and buy conservative commitments; set budgets and anomaly alerts.
The FinOps Framework describes how to keep this going as a practice, with engineering, finance and product sharing ownership of cloud spend. If you’d like help setting up multi-cloud cost visibility or reviewing your architecture for egress and commitment savings, our cloud computing services cover AWS and Google Cloud end to end.