Multi-Cloud Cost Optimization: What Works, What Wastes Time

Multi-cloud cost optimization has become its own micro-industry. The vendor pitches blur together. The dashboards all look similar. The savings claims tend to be aggressive in the deck and unconvincing in production. After spending the last year talking to finance and platform leaders who actually manage workloads across two or more public clouds, the gap between what works and what wastes time is a lot wider than the discourse suggests.

This is a look at the optimization tactics that consistently moved the needle, the ones that have aged poorly, and the structural traps that eat budget no matter what tooling you bolt on.

The tactics that actually pay back

Three families of work produce most of the reliable savings, and none of them are exotic.

Right-sizing compute is still the biggest line item. Despite a decade of dashboards telling teams which instances are oversized, the actual rightsizing rarely happens until someone with authority owns it. Teams that produced real savings here gave a single platform engineer an explicit quarter to walk through the top thirty workloads by spend, talk to the owning team, and either resize or move to a smaller family. Twenty to thirty percent on compute is normal when this is done seriously. The dashboards do not save anyone money on their own. The person does.

Storage tier migration is the second. Object storage costs have diverged sharply between hot and cold tiers, and the gap between standard and archive on AWS, GCP, or Azure is large enough that even modest tiering policies pay back fast. The trap is the access pattern. Teams that flipped buckets to glacier-equivalent classes without auditing read patterns ended up paying egress and retrieval fees that swamped the storage savings. The fix is to spend a week instrumenting access before moving anything.

Commitment discounts are the third. Savings plans, reserved instances, and the equivalent constructs in GCP and Azure still produce thirty to fifty percent off list when applied to stable baseline load. The discipline that distinguishes the teams making money here from the teams losing it is honesty about which workloads are actually stable. Committing capacity for a workload that is going to be rewritten next quarter is how you end up paying for instances nobody uses.

The tactics that look smart and are not

A few optimization stories sound clever and have aged badly.

Spot and preemptible instances for stateless workloads are still real savings, but the operational tax has gone up. The interruption rates in 2025 ticked higher than the previous year across most regions and the vendor APIs around warning time got noisier. Teams who built deep spot-only fleets ended up with engineers on call to handle interruption storms. The economics still work for batch and clearly stateless processing, but the casual recommendation to put everything on spot is unwise. Mixed fleets with a stable on-demand floor and a spot ceiling are the pattern that survived.

Cross-cloud arbitrage – moving workloads from AWS to GCP because the sticker price is lower for a given instance family – almost never works out once you include data transfer, network setup, and the time the platform team spends maintaining two stacks. The cases where it does work are narrow: large batch jobs with low data egress, or compliance reasons that require physical separation. Generic arbitrage is a trap that vendors keep selling because it makes for an easy demo.

FinOps tooling without a FinOps function is the most expensive mistake of all. Buying a CloudHealth, Vantage, or Apptio license without an owner who can act on the recommendations produces dashboards nobody reads. The platform that drives savings is whichever one a real person opens every Monday morning. If nobody opens it, the cheapest tool is the right one.

The data egress trap

Egress is the single biggest source of unexpected multi-cloud spend, and it is the line item that finance and platform teams reliably underestimate. The trap is not the listed egress rate, which is bad but predictable. It is the architecture decisions that create egress without anyone noticing.

The two patterns that hurt most are storing primary data in one cloud while running analytics in another, and routing inter-region traffic through provider-public endpoints instead of private interconnects. Either pattern can quietly add seven figures to an annual bill. The teams that contained this did two things: they used cloud-native peering for any consistent cross-cloud or cross-region link, and they kept analytics close to the data it consumes, even if that meant duplicating compute in the secondary cloud.

The harder version of this conversation is what to do when an acquired company comes with a workload in a different cloud than the parent. The honest answer most of the time is to leave it where it is and stitch the data plane carefully, rather than do a forced migration that costs more than the optimization could ever save.

Kubernetes is where the bill quietly grows

Kubernetes deserves its own section because the cost shape inside a cluster is opaque in a way that classic VM spend is not. Node-level dashboards say the fleet is at 70 percent CPU utilization. Pod-level dashboards say each pod uses far less than its requests. Both are true and both miss the point, which is that requests, not usage, drive node count.

Teams that brought Kubernetes cost under control did three things together. They turned on a request-rightsizing tool – Goldilocks, Robusta, or one of the vertical pod autoscaler integrations – and acted on its output. They consolidated namespaces onto larger node types where bin-packing efficiency improved, and they killed clusters that existed for political reasons rather than technical ones. The third is the hardest. A separate cluster per team feels like good isolation and ends up being a 30 percent multiplier on infrastructure cost.

Observability as a cost line

One under-discussed contributor to cloud spend is the observability stack itself. Log ingestion, metrics retention, and trace storage have grown into a multi-million dollar line for many mid-size companies. The instinct is to keep everything just in case. The reality is that the just-in-case data is almost never queried.

The pattern that worked for several teams I have spoken to was a tiered retention policy: hot retention of seven to fourteen days for active queries, cold storage of ninety days for incident review, and aggressive log-level filters that drop debug-level production logs at the agent. Pairing that with sampling on traces – nothing fancy, just probabilistic sampling at one to five percent for high-volume services – cut observability spend by half in several cases without measurable loss of incident response capability.

The political layer

Cost optimization is half a technical problem and half a political one. The political half is where most programs fail. Engineering teams resist being told that their workload is wasteful, especially when the same finance team that asks for savings also pushes for new features on a tight schedule. The pattern that resolves this in practice is showback first, chargeback later.

Showback gives each team a transparent monthly view of what they cost. No funds change hands. The conversation shifts from accusation to information. After a quarter or two of showback, the teams with the highest variance tend to self-correct because the data is visible to their leadership. Chargeback, where the cost actually hits the team’s budget, only works once that culture is in place. Skipping straight to chargeback turns the cost team into the enemy and produces gaming behavior rather than real optimization.

What good looks like

The teams that consistently kept cloud growth below revenue growth – the rough metric that finance cares about – shared a few traits. They had a named FinOps function, even if it was one person plus a part-time platform engineer. They did rightsizing quarterly, not opportunistically. They ran a kill list of low-utility workloads and actually killed them. They reviewed commitment coverage monthly. And they had a stated egress philosophy that engineering knew about before they architected anything new.

None of that is exciting. It is mostly the discipline of doing the unglamorous things on a schedule. The vendors who win the longest contracts here are the ones that help teams execute that discipline, not the ones that promise the largest single-quarter savings. Multi-cloud cost optimization in 2026 looks more like running an accounts payable function than running an AI initiative, and the teams that internalized that are the ones whose bills stopped growing faster than their headcount.