FinOps Inform · Multi-Cloud FinOps

Recover 20–35% in 90 Days: Multi Cloud Cost Management for FinOps

Actionable multi cloud cost management for FinOps leaders: fix Kubernetes and AI/GPU blind spots, run a 90 day savings plan, and get a free Koritsu...

Kori September 1, 2026 · 15 min read

The best approach unifies billing across every provider, assigns every cost to a named owner, automates rightsizing and commitment purchasing, and puts a FinOps function in place to keep it that way. Organisations that do this consistently report savings in the 20 to 35% range within a year. Going into 2026, the two areas demanding the most attention are AI and GPU spend, and Kubernetes cost allocation, since both are notoriously hard to see and even harder to control once they scale.

TL;DR:

Automating rightsizing and commitment purchasing is essential, as waste elimination can deliver savings of 20 to 35 percent within a year.

Unified visibility requires normalizing billing data from all providers, including currency conversion, billing periods, and shared costs, to produce a trustworthy dashboard.

Proper cost allocation depends on enforced tagging, virtual rules, and transparent logic, with teams typically starting with showback before moving to chargeback.

AI and Kubernetes costs pose the biggest blind spots in 2026, requiring detailed telemetry, workload-level attribution, and model-specific tagging for accurate control.

A continuous, disciplined approach with automation, immediate quick wins, and a 90-day plan is critical to sustainably reduce multi-cloud expenses.

What is multi-cloud cost management?

Multi-cloud cost management is the discipline of tracking, allocating, and controlling spend across AWS, Azure, Google Cloud, and any other provider a business runs workloads on, so that costs stay proportionate to the value they generate. Practitioners often call the broader field FinOps, short for Cloud Financial Operations, a term the FinOps Foundation has spent years formalising into a repeatable set of practices. The two terms overlap heavily. Multi-cloud cost management is the specific challenge; FinOps is the organisational discipline built to solve it.

The reason this has become urgent rather than optional is straightforward: Gartner forecasts worldwide public cloud end-user spending will reach $723 billion in 2025, and that figure keeps climbing. When spend was smaller, waste was a rounding error. Multi-cloud makes the problem worse, not better, because every additional provider adds its own billing format, its own discount structure, and its own blind spots.

The rest of this guide breaks the discipline into its component parts: visibility, allocation, waste elimination, commitment buying, Kubernetes and AI cost control, the organisational model that sustains it, and a 90-day roadmap to get moving.

Why unified visibility matters for multi-cloud cost management

You cannot manage what you cannot see in one place, and that is precisely where most multi-cloud programmes stall before they start. Each provider ships its own billing export, its own naming conventions, and its own granularity, so a raw AWS Cost and Usage Report looks nothing like an Azure Cost Management export or a Google Cloud BigQuery billing table.

Building a single source of truth means ingesting several distinct data streams and reconciling them into one model:

Detailed billing exports from every provider (AWS Cost and Usage Reports, Azure Cost Management exports, Google Cloud billing export tables)
Reserved capacity and savings plan utilisation data, kept separate from on-demand usage
Tagging and resource metadata, pulled from each provider's inventory API
Usage telemetry from monitoring tools, needed to connect cost to actual consumption rather than just spend

Normalisation is the unglamorous work that makes any of this useful. Currency needs converting to one reporting currency at a consistent exchange rate, not whatever rate happened to apply on the invoice date. Billing periods need aligning, since providers don't all close their books on the same day of the month. Shared costs, support fees, marketplace charges, and cross-account discounts, need a defined split rule rather than being dumped into a general overhead bucket where nobody owns them.

The FOCUS specification from the FinOps Foundation exists specifically to solve this problem, giving providers and tools a common schema for billing data so teams stop reinventing the same normalisation logic. Architecture patterns for this kind of aggregation are well documented; AWS's own engineering blog walks through pipeline designs for ingesting and normalising billing data at scale.

Done properly, a unified view gives engineering teams a dashboard they can trust, gives finance a number that reconciles with the actual invoice, and gives leadership a single figure they can forecast against instead of three conflicting ones. A cloud cost dashboard built around owner visibility is usually the first concrete deliverable a FinOps programme produces, and it's the one that earns trust fastest.

How do you allocate multi-cloud costs to the right owner?

Allocation is where most cost programmes either earn credibility or lose it. Engineers ignore a cost dashboard that can't tell them which service, team, or feature is actually driving the number. Getting this right means combining disciplined tagging with rules that cover the gaps tags will always leave.

Tagging that actually holds up in production starts with a small, mandatory set: team, environment, product, and cost centre, enforced at resource creation rather than audited after the fact. Enforcement matters more than the taxonomy itself. A tagging policy nobody enforces decays within a quarter, as new resources get spun up without labels and old ones get forgotten.

Define a minimal mandatory tag set and block resource creation without it, using provider-native policy tools or infrastructure-as-code guardrails.
Run a monthly tag compliance report and treat untagged spend as a KPI, not an afterthought.
Apply virtual tagging and business rules to anything tags can't reach, shared databases, load balancers, support contracts, using usage ratios or headcount splits as the allocation key.
Publish allocation logic openly so engineering teams can challenge it, rather than treating the finance model as a black box.

Virtual allocation matters because perfect tagging is a fantasy. Shared Kubernetes clusters, multi-tenant databases, and platform-level networking rarely map cleanly to one team. The practical fix is a business rule, split by proportional CPU usage, request volume, or headcount, applied consistently and documented so engineering doesn't dispute the number every month.

Pro Tip: Show engineers their own team's cost trend before you show finance the consolidated total. Teams that see their own number first tend to self-correct waste faster than teams that only see it in a quarterly finance review.

Once allocation is solid, the presentation split matters. Showback gives teams visibility into what they're consuming without moving money, useful for building awareness without political friction. Most organisations start with showback for two or three quarters, then move high-confidence categories to chargeback once the model has survived scrutiny. Practical attribution templates can shortcut a lot of the trial and error here.

Cloud spending allocated to engineering teams

What causes cloud waste, and how do you eliminate it?

Waste hides in plain sight: instances running at 5% CPU utilisation, load balancers pointing at nothing, snapshots nobody has touched in eighteen months. Practitioner surveys consistently show usage optimisation remains one of the largest untapped opportunities in cloud cost programmes, which tells you most teams know waste exists but haven't built the muscle to remove it systematically.

The clearest waste signals show up directly in telemetry, once you know where to look:

Compute instances with sustained CPU or memory utilisation below 10 to 15% over a rolling two-week window
Storage volumes attached to terminated instances or unattached entirely
Idle load balancers and NAT gateways with near-zero traffic
Snapshots and backups retained past their compliance or recovery window
Development and staging environments running 24/7 with no usage outside working hours

Remediation splits cleanly into two patterns. Automated remediation suits low-risk, high-frequency waste: scheduled shutdown of non-production environments outside business hours, automatic deletion of snapshots past a retention threshold, and lifecycle policies that move cold storage to cheaper tiers without anyone approving each move. Manual remediation belongs on anything customer-facing or stateful, since automated rightsizing can degrade performance if it misjudges peak load. CoreSite's guidance on multi-cloud cost strategies reinforces autoscaling and rightsizing as the tactical core of this work, alongside disciplined commitment management.

Pro Tip: Rightsize in two passes, not one. Cut obviously oversized instances immediately, then wait two full billing cycles before the second, more aggressive pass. Some usage spikes are seasonal, and a single month of data will fool you.

The reason waste keeps coming back isn't laziness, it's process. Without a scheduling policy and a recurring audit cadence, every fix is temporary. Build waste detection into a weekly automated report rather than a quarterly manual sweep, and set lifecycle policies as defaults on new resources rather than exceptions applied later.

How do commitments and reservations cut multi-cloud costs?

The trap is treating this as a one-off purchasing exercise rather than a continuous discipline. Usage patterns shift, teams migrate workloads, and a commitment bought in January can look badly mismatched by September.

The mechanics differ enough across providers to matter:

Reserved Instances lock in specific instance types and regions, offering the deepest discounts but the least flexibility if workloads change shape.
Savings Plans and Committed Use Discounts apply more broadly across instance families, trading some discount depth for flexibility as workloads evolve.
Spot and preemptible capacity offer the steepest discounts of all but require workloads tolerant of sudden interruption, generally batch and stateless processing rather than production services.

Continuous coverage analysis beats the traditional annual bulk purchase in almost every environment with variable usage. Rather than committing to a large tranche once a year and hoping usage holds steady, buy incrementally as a stable usage baseline emerges, and let coverage grow with real consumption rather than a forecast. This approach also reduces the single biggest risk in commitment purchasing: over-commitment against workloads that shrink, get decommissioned, or migrate to a different provider.

Governance keeps this safe. Every commitment purchase above a defined threshold should route through an approval flow, and someone needs explicit ownership of coverage and utilisation metrics, not just the initial purchase decision. Role-based access control is the practical mechanism most organisations use to restrict who can authorise a large commitment purchase, preventing an enthusiastic engineer from locking the business into a three-year term on a whim.

AI and Kubernetes workloads are emerging as the dominant cost growth areas heading into 2026, and they share a common problem: both obscure the connection between spend and the team or model actually generating it. A Kubernetes cluster bills as a handful of compute instances; the split between the forty microservices running on it is invisible unless someone builds it deliberately.

Kubernetes cost attribution requires telemetry that standard cloud billing simply doesn't provide. You need namespace-level resource requests versus actual usage, pod-level CPU and memory consumption mapped against node capacity, and a clear view of whether a workload is over-requesting resources it never uses, the single most common waste pattern on Kubernetes. Without this, cost gets smeared evenly across a cluster regardless of which team is actually driving consumption.

AI and GPU costs raise the stakes further because the spend profile is so different from conventional compute:

Training runs are bursty and expensive per hour, often justifying premium GPU instances for a defined, time-boxed window.
Inference workloads run continuously and need right-sized capacity, since an oversized inference endpoint burns money every hour it sits idle.
GPU utilisation below 30 to 40% is a common signal of over-provisioned training or inference capacity, though the threshold varies by workload type.
Model-level tagging, attributing GPU spend to the specific model or experiment consuming it, is now essential, since a single ballooning training job can dwarf an entire team's normal monthly cloud bill.

One AI training run that runs unattended over a long weekend can generate cost equivalent to weeks of normal team spend. That asymmetry is exactly why quotas and alerts matter more here than almost anywhere else in the cloud estate.

Operational controls that work: resource quotas at the namespace level to cap runaway pod scaling, horizontal and vertical autoscaling tuned to actual demand rather than static thresholds, and chargeback models that attribute GPU hours to the model or experiment consuming them rather than a generic "AI/ML" bucket that tells nobody anything useful.

What does a FinOps team actually look like?

FinOps only works as an organisational function, not a dashboard someone checks occasionally. The FinOps Foundation's framework defines three core roles that most mature programmes converge on regardless of company size.

FinOps practitioners own the platform, the data pipeline, and the reporting cadence, and act as the translation layer between raw billing data and decisions engineering teams can act on.
Engineering leads own remediation, since they're the only ones with the context to judge whether a rightsizing recommendation is safe to execute or will break something in production.
Finance partners own budgeting, forecasting, and the chargeback model, translating engineering decisions into numbers the business can plan around.

The operating rhythm follows a repeating loop: discover what's being spent and by whom, optimise the obvious waste and commitment gaps, then operate a governance cadence that keeps both from drifting back to where they started. This isn't a project with an end date. Teams that treat it as a one-time clean-up watch savings erode within two or three quarters as new resources get provisioned without the same discipline applied.

Metrics worth tracking regularly include unit economics (cost per customer, per transaction, or per API call, depending on the business model), commitment coverage and utilisation rates side by side, and the percentage of spend allocated to a named owner versus sitting unattributed. Presenting these to stakeholders works best as a trend line rather than a single snapshot; a finance director cares far more about the trajectory than the number on any given Tuesday. A well-built FinOps framework guide is a useful reference when defining these roles for the first time.

What should you require from a multi-cloud cost management platform?

Feature checklists for cost tools tend to bury the essentials under a long list of nice-to-haves. Prioritise capability by actual financial impact, not by how many logos a vendor lists on their integrations page.

Ingestion and normalisation: native support for all your providers' billing exports, plus a normalisation layer that handles currency, billing periods, and shared cost splitting without custom engineering work on your end.
Allocation engine: support for both hard tagging and virtual tag rules, since no environment achieves complete tag coverage and the platform needs to handle that gap gracefully.
Rightsizing automation: recommendations backed by actual utilisation telemetry, not just instance size comparisons, and ideally with a safe automated execution path for low-risk categories.
Commitment optimisation: continuous coverage analysis rather than a one-time purchasing recommendation, with alerts when utilisation drifts below target.
Kubernetes and AI/GPU visibility: namespace and pod-level attribution, plus model-level tagging for GPU workloads, treated as first-class features rather than an afterthought.
Anomaly detection: statistical baselining that flags unusual spend spikes within hours, not the following month's invoice.
Forecasting APIs: programmatic access to forecast data, so budgeting tools and internal dashboards can pull projections rather than relying on manual exports.

Integration requirements matter as much as the feature list. Check export cadence (daily exports beat weekly ones for anomaly detection to actually work), permission scopes needed for read access across every cloud account, and whether the tool plugs into CI/CD pipelines to catch cost regressions before they reach production rather than after the invoice arrives.

The last test is operational fit: does a recommendation from the platform turn into an approved, executed change within days, or does it sit in a backlog for a quarter? Tools that generate reports nobody acts on are worse than useless, they create the illusion of progress while the underlying waste keeps accumulating.

How do you measure real savings from cloud cost optimisation?

Realised savings only count once they show up on an actual invoice, not in a dashboard projection. Reconciliation means comparing the pre-intervention baseline against the post-intervention bill over an equivalent period, adjusted for any genuine usage growth so you don't accidentally credit the programme for a rightsizing win that was actually just quieter traffic that month.

Double-counting is the most common measurement error. If a commitment purchase and a rightsizing effort both touch the same resource in the same month, attribute the saving to one intervention, not both, or the reported total will drift well past what the invoice actually shows.

Industry evidence points to a fairly consistent range: organisations that combine FinOps discipline with active remediation typically recover 20 to 35% of prior spend within the first year. Where an organisation lands within that range depends on how mature its tagging was to start, how much idle waste had already accumulated, and how quickly engineering teams act on recommendations once they're surfaced.

The pattern that matters more than the exact figures: waste elimination delivers the fastest win, commitment optimisation compounds it, and neither works without the tagging discipline that made allocation possible in the first place. A closer look at total cost of ownership helps frame these savings against the full picture finance actually cares about.

What's a realistic 90-day plan to cut multi-cloud costs?

Ninety days is enough time to move from chaos to a functioning programme, provided the phases stay disciplined and quick wins come before anything structural.

Days 1 to 15, discover: connect billing exports from every provider, stand up the normalised data model, and run the first tag compliance audit to see how bad the gap actually is.
Days 16 to 30, quick wins: eliminate obvious waste, orphaned volumes, idle load balancers, unattached snapshots, since these carry zero migration risk and deliver savings within the first billing cycle.
Days 31 to 60, pilot allocation: roll out mandatory tagging on new resources, apply virtual allocation rules to the largest shared cost categories, and publish the first showback report to two or three pilot teams.
Days 61 to 90, scale and automate: extend showback to the full engineering organisation, launch continuous commitment coverage analysis, and set up scheduled automation for non-production environments.

Prioritisation through all four phases follows one rule: rank by ratio of effort to impact, not by absolute savings potential. A £3,000-a-month idle resource cleanup that takes an afternoon beats a £15,000 commitment restructuring that needs three weeks of stakeholder alignment, at least in the first quarter, when momentum and visible wins matter more than maximising the single largest number.

Pro Tip: Publish the first savings number, however small, within 30 days. A programme that goes quiet for a full quarter before reporting anything loses executive attention fast, and attention is what funds the next phase.

Sustainability beyond day 90 depends on automation and policy enforcement replacing manual review. Lifecycle policies, tagging guardrails at resource creation, and scheduled reforecasts every quarter keep the gains from eroding. Tactical quick-win playbooks are useful references for phase two specifically, where speed matters more than sophistication.

How Koritsu AI approaches multi-cloud cost management

Most of what's described above is straightforward in principle and genuinely hard to execute consistently, because it demands both continuous analysis and engineering time most teams don't have spare. That gap is exactly where Koritsu AI operates.

The model combines two things deliberately, rather than picking one. Kori, Koritsu AI's AI agent, continuously analyses billing and telemetry across providers to surface where money is actually being lost, often in architectural decisions rather than obvious pricing mistakes. Specialists then work directly with engineering teams to execute the fix, because a report identifying waste is worthless if nobody has the bandwidth to act on it.

A few things worth noting about how this is structured:

Engagements start with a free assessment, so there's no upfront commitment before you see where the waste actually sits.
Pricing is charged as a share of savings actually verified against billing, which aligns incentives tightly. Koritsu AI only gets paid when the client's invoice genuinely drops.
Clients can move to an ongoing subscription once the initial engagement proves out, keeping continuous monitoring in place rather than letting savings erode after a one-off clean-up.

That performance-based structure matters more than it might first appear. A consultancy paid regardless of outcome has no particular incentive to chase the harder architectural fixes; one paid only against realised savings has every incentive to find them.

Why tools alone won't fix your cloud bill

Here's what I'd tell any engineering leader starting this work: fix Kubernetes and GPU attribution first, before anything else on this list. It's the area with the least existing visibility and the fastest-growing spend, and every month you wait, the blind spot gets more expensive to unwind.

The uncomfortable truth is that no platform, including ours, delivers savings by itself. A tool can surface an idle GPU cluster burning money overnight. It cannot walk into a standup and convince an engineering team to change how they provision capacity. That requires ownership, an actual person accountable for the number, and a process that survives past the initial clean-up. Teams that treat cost optimisation as a one-off audit watch the savings evaporate within two quarters. Teams that build the habit keep it.

Get a free assessment of your multi-cloud spend

Koritsu AI exists for exactly the gap this guide describes: the space between knowing costs are too high and having the engineering time to actually fix it. Kori continuously analyses your billing and infrastructure across providers, and Koritsu AI specialists then work directly with your team to execute the changes, rather than handing you a report and disappearing.

A free assessment shows you where the waste actually sits before you commit to anything, and because Koritsu AI is paid as a share of verified savings, there's no incentive mismatch between the recommendation and the invoice you actually see afterwards. One recent engagement, detailed in the UK bidding platform case study, delivered a 52% reduction in cloud costs once the architectural inefficiencies behind the bill were identified and fixed. If your multi-cloud spend has been climbing faster than your workload growth explains, book a free assessment and see what's actually driving it.