Running infrastructure across multiple cloud providers delivers real strategic value: access to best-in-class services from each provider, reduced vendor lock-in, compliance flexibility, and the ability to place workloads where they run most efficiently. Most enterprises now operate across multiple clouds including AWS, Azure, and GCP to avoid vendor lock-in and leverage specific best-of-breed services. What those same enterprises consistently underestimate is the cost management complexity that comes with it.
In a single cloud environment, cost management is hard. In a multicloud environment, it is a fundamentally different problem. The billing systems do not speak the same language. The discount instruments work differently and cannot be combined. Tagging conventions that work well on AWS rarely translate cleanly to Azure resource tags or GCP labels. And the native tools from each provider are designed to show you their portion of the bill, not the whole picture.
This guide covers how to build a multicloud cost management practice that works: the specific challenges that make multicloud different from single cloud, the foundational capabilities every multicloud FinOps program needs, and the strategies that reduce spend without constraining engineering teams.
Why Multi-Cloud Cost Management Is a Different Problem
The instinct when moving to multiple clouds is to treat each provider as a separate cost management problem and apply single-cloud FinOps practices independently. This approach fails predictably, because most of the hardest multicloud cost problems are cross-provider problems that individual provider tools are not designed to solve.
Each cloud provider has its own pricing structure, billing metrics, and discount programs, making cost comparison and optimization difficult. Instance types, storage tiers, and networking costs vary across AWS, Azure, and Google Cloud, leading to inconsistencies in budgeting, forecasting, and cost allocation. The result is that finance teams cannot reconcile a unified cloud budget, engineering teams lose context when switching between provider consoles, and FinOps practitioners spend the majority of their time normalizing data rather than acting on it.
Only 39% of organizations can accurately track unified spend across all cloud platforms, leaving most teams without full cost visibility. That gap is the root cause of almost every multicloud cost problem: without a unified view, optimization happens in silos, cross-cloud trade-offs cannot be evaluated, and accountability is fragmented across teams and providers.
The Five Core Challenges of Multicloud Cost Management
Understanding what makes multicloud cost management hard is the prerequisite to solving it. The challenges are structural, not technical, which is why adding more native tooling rarely fixes them.
Billing data normalization. AWS exports billing data through the Cost and Usage Report. Azure exports through Cost Management. GCP exports to BigQuery. Each uses different terminology, different cost dimensions, different granularity, and different latency. A compute instance is an EC2 instance on AWS, a Virtual Machine on Azure, and a Compute Engine instance on GCP. Before any cross-cloud analysis can happen, this data needs to be normalized into a consistent schema. The FinOps Foundation’s FOCUS specification was created specifically to address this problem by standardizing how cloud billing data is structured across providers.
Tag inconsistency across providers. Tagging is the foundation of cost allocation, and every multicloud environment has a tagging problem. Tag keys that are enforced on AWS resources through Service Control Policies have no equivalent enforcement mechanism in Azure or GCP. Teams that built a clean tagging taxonomy for AWS discover that their Azure resources use different conventions and their GCP resources use labels with different character limits and key structures. The result is allocation gaps that grow as the multicloud environment scales.
Fragmented commitment management. AWS Savings Plans, Reserved Instances, Azure Reserved Instances, Azure Savings Plans for Compute, and GCP Committed Use Discounts each operate independently with different commitment structures, different discount levels, and different flexibility models. Managing discounts across AWS, Azure, and Google Cloud adds complexity. Overcommitting leads to wasted capacity, while undercommitting leaves money on the table. Optimizing commitments across three providers simultaneously requires modeling that no native billing tool is designed to support.
Cross-cloud egress costs. Data transfer between cloud providers incurs full internet egress rates on the outbound side. Moving data from AWS to GCP or from Azure to AWS can cost $0.09 per GB or more, and these charges compound rapidly in architectures that depend on regular cross-provider data movement. Because egress costs appear in the billing data of the sending provider, they are often misattributed or overlooked entirely in multicloud cost reviews.
Organizational silos. When departments need to track, monitor, and optimize spending across multiple cloud platforms, it can lead to heavier workloads. Team members may need to create separate workflows or reconciliation procedures for each environment. In many multicloud organizations, different teams own different providers, each with their own FinOps practices, their own reporting cadence, and their own optimization priorities. Without a unified governance structure, the combined cost picture is never reviewed as a whole.
Building Unified Visibility: The Non-Negotiable Foundation
Every multicloud cost management strategy starts in the same place: getting a single, reliable view of spend across all providers. Without this, every downstream capability (optimization, forecasting, chargeback, commitment management) is built on incomplete data.
Unified visibility requires three things. First, billing data from each provider must be ingested and normalized into a common format with consistent terminology and cost dimensions. Second, that normalized data must be enriched with allocation metadata: team ownership, product mapping, environment labels, and any virtual tags needed to fill gaps in the underlying resource tagging. Third, the unified data must be queryable with enough granularity to support both high-level executive reporting and resource-level engineering investigation.
The FOCUS specification provides a standard schema for this normalization. Platforms that have adopted FOCUS allow organizations to query cost data across providers using consistent field names and cost types, which eliminates the manual reconciliation work that consumes significant FinOps capacity in environments managing normalization manually.
Tagging Strategy in a Multicloud environment
Cost allocation in a multicloud environment requires a tagging strategy that is designed for multi-provider consistency from the start, not adapted from a single-provider convention after the fact. The core dimensions that every resource across every provider should carry are the same: team or owner, product or application, environment (production, staging, development), and cost center or business unit.
The implementation differs by provider. On AWS, tag policies through AWS Organizations enforce required tags across all accounts. On Azure, Azure Policy enforces tag requirements at the resource group or subscription level. On GCP, organization policies and label constraints provide similar enforcement. Using the same tag key names and values across all three providers is essential: a resource tagged env:production on AWS and environment:prod on Azure cannot be compared without manual normalization.
Virtual tagging addresses the allocation gaps that remain even after tag enforcement is in place. Rather than requiring retroactive changes to resource tags (which creates engineering dependencies and delays), virtual tags apply allocation rules at the reporting layer. A resource that cannot be tagged at the infrastructure level because it was created by a third-party tool or a legacy automation script can still be attributed correctly through virtual tag rules that map it to the right team or product based on naming conventions, account structure, or other metadata.
For a deeper look at tagging strategy specifically, the Holori guide to cloud tagging best practices covers the full taxonomy design and enforcement model in detail.
Cost Allocation in Multicloud: Attributing Spend Across Three Billing Systems
Cost allocation is harder in multicloud environments than in single-cloud for one fundamental reason: the underlying billing data arrives in three different formats, at different cadences, with different levels of granularity, and with no shared resource identifier that links the same logical workload across providers.
An application that runs compute on AWS, stores data on GCS, and uses Azure Cognitive Services for a specific capability generates costs in three separate billing systems. None of those systems know the others exist. Allocating the total cost of that application to the team or product that owns it requires a layer that sits above all three providers and applies consistent attribution logic across all of them.
The first prerequisite is a unified cost allocation model: a defined set of dimensions (team, product, environment, cost center) that applies to every resource across every provider, regardless of how that provider structures its own billing data. This model needs to be agreed upon before tagging is designed, because the tag schema is the implementation of the allocation model, not the other way around.
The second prerequisite is handling shared costs. In multicloud environments, shared infrastructure is common and difficult to attribute. A centrally managed Kubernetes cluster, a shared data lake that multiple teams read from, a networking hub that carries traffic for multiple applications: these generate costs that do not map cleanly to a single owner. Multicloud shared cost allocation requires explicit policy decisions: should shared costs be split equally, split by usage proportion, or attributed entirely to the largest consumer? The policy needs to be consistent across providers and documented so that teams understand how their allocated costs are calculated.
The third layer is handling untagged and unattributable spend. No multicloud environment achieves 100% tag coverage immediately, and some resource types cannot be tagged at all. Allocation rules that use account structure, resource naming conventions, or service type to infer ownership fill the gap between tagged spend and total spend. Holori’s virtual tagging applies these inference rules at the reporting layer, which means attribution accuracy improves without requiring ongoing changes to how resources are provisioned across each provider.
Tracking cost allocation rate across all three providers, not just within each provider separately, is the metric that tells you whether your multicloud allocation model is working. A 90% allocation rate on AWS and a 65% allocation rate on Azure means your combined allocation picture is unreliable. The goal is a single allocation rate that reflects your multicloud environment as a whole.
Cross-Cloud Commitment Strategy
Commitment-based discounts are the single largest lever for reducing cloud costs in stable, predictable environments. Managing them across three providers simultaneously requires a coordinated strategy rather than three independent approaches.
On AWS, Savings Plans provide the most flexibility, applying compute discounts across instance families, regions, and operating systems within a defined hourly spend commitment. Compute Savings Plans are the most flexible, while EC2 Instance Savings Plans offer higher discounts for specific instance commitments. Reserved Instances remain valuable for database services and other workloads where Savings Plans do not apply.
Azure Reserved VM Instances commit to specific virtual machine sizes or families in a region for one or three years, with discounts reaching around 72% for steady workloads. Azure Savings Plans for Compute provide greater flexibility through an hourly spend commitment, applying broadly to compute usage. Azure also includes the Hybrid Benefit, which allows reuse of existing on-premises Windows and SQL Server licenses to reduce costs further.
Google Cloud takes a somewhat different approach with Committed Use Discounts. These commit to specific vCPU and memory amounts in a region rather than exact machine types. One-year commitments deliver up to around 57% savings, while three-year terms can reach 70%. GCP also applies sustained use discounts automatically when instances run for a significant portion of the billing month, providing a partial discount without any commitment.
The coordination challenge across three providers is that each commitment is purchased and tracked separately, with no cross-provider netting. A team that over-purchased Azure reservations cannot apply that capacity credit toward AWS Savings Plans. This makes accurate usage forecasting per provider essential before any commitment is made. The correct sequence is always to rightsize first, then forecast by provider, then commit.
Tracking commitment coverage rate and utilization rate across all three providers in a single view is the only way to manage cross-cloud commitment efficiency without significant manual work. Holori’s commitment tracking surfaces coverage and utilization for AWS Savings Plans, Reserved Instances, Azure Reservations, and GCP Committed Use Discounts in a unified dashboard, making cross-provider commitment gaps visible without switching between native consoles.
Egress Cost Management in Multicloud Environments
Cross-cloud egress is one of the most consistently underestimated cost drivers in multicloud architectures. Teams that design systems to move data between AWS and GCP, or between Azure and AWS, frequently do not model the egress cost at design time. By the time the cost appears in the bill, it has been running for months.
The practical approach to egress cost management in multicloud environments starts with architecture review. Any data flow that crosses provider boundaries should be explicitly documented, cost-modeled at current and projected data volumes, and evaluated against alternatives. In many cases, replicating a service to avoid cross-cloud data transfer is cheaper than the ongoing egress cost, particularly for high-volume flows.
For data that must move between providers, CDN caching and regional aggregation reduce the volume of cross-provider transfer by serving repeated requests from cached copies rather than re-fetching from origin on every request.
Monitoring egress specifically requires identifying data transfer line items in each provider’s billing data and attributing them to the workloads and teams that generate them. Without attribution, egress costs sit in an unallocated shared pool where no team has visibility or accountability for reducing them.
Governance and Accountability in Multicloud
The operational discipline that keeps multicloud costs under control is governance: defined policies for how cloud resources are provisioned, tagged, and reviewed, applied consistently across all providers.
Policies should cover aspects like tagging standards, approved instance types, data retention rules, and cost allocation methodologies. By defining these guidelines, organizations can ensure that all cloud resources are deployed and managed in a cost-efficient manner from the outset. Holori
In multicloud environments, governance is harder to enforce than in single-cloud environments because each provider has different policy mechanisms. Infrastructure-as-code is the most effective governance layer: when all provisioning goes through Terraform or similar tools, policy checks can be applied consistently at the code level before any resource is created, regardless of which provider it targets. Cost estimation integrated into CI/CD pipelines (shift-left FinOps) extends this further by surfacing the cost impact of infrastructure changes before they are deployed.
Budget and anomaly alerting must cover all providers simultaneously. A cost spike on GCP that is within the GCP budget but pushes total multi-cloud spend over the combined budget is invisible to provider-specific alerting. Holori’s anomaly detection operates across AWS, Azure, and GCP in a single detection layer, flagging unexpected cost movements regardless of which provider they originate from and routing alerts to the team responsible for the relevant workload.
How Holori Solves Multicloud Cost Management
Holori is built specifically for multicloud cost management, which is why it addresses each of the structural challenges described in this guide rather than solving single-cloud problems in parallel.
Billing data from AWS, Azure, GCP, OCI, Scaleway, and OVHcloud is ingested and normalized into a unified view using consistent cost dimensions and terminology. Virtual tags allow allocation rules to be applied across all providers without requiring infrastructure changes, closing the attribution gaps that accumulate in every multicloud environment over time.
Infrastructure diagrams generated by Holori show the full resource topology across providers in a single view, including relationships between resources, attached and unattached storage, and cross-account dependencies. This visual layer makes it significantly faster to identify idle, orphaned, or overprovisioned resources than querying provider billing data programmatically.
Commitment tracking, anomaly detection, cloud cost reporting, and optimization recommendations all operate across providers simultaneously, which means the FinOps team maintains a single workflow rather than managing three parallel processes in three separate tools.
Multicloud is not going away. As AI workloads, compliance requirements, and best-of-breed service selection continue to drive organizations across multiple providers, the cost management challenge grows with the environment. The organizations that manage it well are the ones that invested early in unified visibility, consistent allocation, and cross-provider governance rather than treating each provider as a separate cost problem. Build the foundation right and multicloud cost management becomes a scalable practice rather than a permanent source of billing surprises.
Conclusion
Multicloud cost management becomes sustainable when three things work together: a unified visibility layer that normalizes data across providers, consistent allocation and governance processes that apply the same standards regardless of which cloud a resource sits in, and tooling that surfaces the right information to the right team at the right time.
The five challenges described in this guide, billing normalization, tag inconsistency, fragmented commitment management, cross-cloud egress, and organizational silos, are all solvable. But they cannot be solved by managing each provider in isolation with native tools that were designed to show you one slice of the bill at a time. The multi-cloud cost problem is a cross-provider problem and it requires a cross-provider solution.
That is exactly why we built Holori. If you are managing cloud costs across AWS, Azure, and GCP and want a single platform to unify visibility, allocation, and optimization across all three, you can get started now with Holori for free !
Frequently Asked Questions
What is multicloud cost management?
Multicloud cost management is the practice of tracking, allocating, optimizing, and governing cloud spend across multiple providers simultaneously. It combines unified billing visibility, consistent cost attribution, cross-provider commitment strategy, and governance policies to ensure cloud investment is efficient and accountable regardless of which provider a workload runs on.
Why is multicloud cost management harder than single-cloud?
Each provider has its own billing format, pricing model, discount instruments, and tagging mechanism. Native tools from each provider only show their portion of the bill, with no cross-provider visibility. Commitment discounts cannot be combined across providers. Tagging conventions that work on AWS rarely translate cleanly to Azure or GCP. All of these structural differences require a coordination layer that sits above all three providers to solve.
What is the first step to getting multicloud costs under control?
Unified visibility is always the first step. Without a normalized view of spend across all providers in a consistent format, every downstream capability including allocation, optimization, forecasting, and commitment management is built on incomplete data. Before optimizing anything, consolidate billing data from all providers into a single view with consistent cost dimensions and allocation metadata.
How do you allocate costs across multiple cloud providers?
Effective multicloud cost allocation requires a unified allocation model (team, product, environment, cost center) applied consistently across all providers through a shared tagging strategy. Virtual tags fill the gaps for resources that cannot be tagged at the infrastructure level. Shared costs require an explicit split policy. Allocation rate should be measured as a single combined metric across all providers, not separately per provider.
Do commitment discounts work across cloud providers?
No. AWS Savings Plans, Azure Reservations, and GCP Committed Use Discounts each operate independently and cannot be combined or offset against each other. Each provider’s commitments apply only to usage within that provider. This means commitment strategy must be managed per provider based on accurate per-provider usage forecasts, and over-purchasing on one provider cannot be compensated by under-purchasing on another.
