1st Floor, Building 3 Concorde Park Concorde Road Maidenhead Berkshire SL6 4BY

FinOps in 2025: Great at “spend control,” weak at answering “Are hyperscalers right for us?

Nov 4, 2025 - 2 min read

If you only looked at dashboards, you’d think the cloud cost problem is solved. Reserved Instances are humming, Savings Plans are topped up and anomaly alerts ping the right channels. Yet most leadership teams still can’t answer a harder, more strategic question:

“Are hyperscale cloud providers actually the best choice for our business, today and over the next three years?”

Right now, the honest answer at many companies is: we don’t know.

Below is how FinOps has matured, why most tools stop short of the decision that matters, and how to move from “cost control” to cloud choice with a defendable TCO and risk picture.

Where FinOps is strong today

The FinOps practice has professionalised fast. The FinOps Foundation’s evolving Framework (updated again in 2025) now formalises clear principles, personas, domains and capabilities that teams can deploy across engineering and finance. It’s increasingly scoped to cover more than just public cloud line items.

Surveys keep reinforcing the same reality: cost governance is table stakes, automation is rising and managing new spend categories, especially AI, is now a first-class concern. (Many organisations report that AI is already a budgeting headache.)

Net:

  • We’re good at optimising what we’ve already bought.
  • We’re less good at deciding what we should buy next.

The question FinOps tools rarely answer

Most cost tools were designed to reduce waste and improve commitments inside a single cloud. They’re not built to prove or disprove whether your workloads, latency profile, egress patterns, governance obligations and talent model would run better and cheaper on:

  • a different hyperscaler,
  • a split across clouds,
  • or a private/colocation stack for specific, steady workloads.

That’s because the drivers of cloud choice sit beyond the usual unit-price comparisons. You need to model:

  1. Network shape & egress gravity. Ingress is typically free; egress, inter-region and cross-AZ traffic can bite, often invisibly during architecture design.Regulatory pressure is shifting some fees (e.g., “switching”/exit transfers in certain regions), but that doesn’t erase architectural data-movement costs you’ll still pay day-to-day.
  2. Workload stability vs. elasticity. Tools optimise spot/commitments well, but they rarely quantify when a stable, high-duty workload’s TCO crosses the line where owned capacity (or colo with modern automation) wins, something real-world repatriations have highlighted, even if analysts expect public cloud spend to keep growing overall.
  3. Risk & lock-in premium. Marketplace SKUs, proprietary AI accelerators and managed services speed delivery but create exit friction that a pure price chart misses.
  4. People & process tax. The cost of platform engineering, security baselines and compliance differs materially between single-cloud, multi-cloud and hybrid footprints and rarely shows up in a FinOps dashboard.
  5. Future price paths. List prices are public; effective prices (commitment shapes, credits, enterprise agreements) are not and vary by your spend curve and negotiation leverage.

Why “Is the cloud worth it?” keeps getting asked

Three shifts keep this question alive:

  • AI changed the shape of spend. Training/inference introduces big, spiky, data-heavy graphs where data movement and GPU economics dominate. Traditional cost levers often don’t capture those pivots cleanly.
  • Policy pressure on switching fees. Hyperscalers have begun easing certain data-transfer charges for leaving or running in parallel; not out of generosity but due to regulatory scrutiny. It helps mobility, but it doesn’t answer workload-fit or steady-state TCO.
  • Evidence of selective repatriation. A handful of high-profile teams have reported meaningful savings by moving specific, stable workloads off public cloud, while the broader market continues to expand public cloud use. The nuance matters: it’s not “all-in” vs. “all-out”; it’s workload by workload.

What a better decision looks like

To answer “Are hyperscalers best for us?” you need a workload-level model that spans beyond a single provider’s bill:

  1. Map workload archetypes. Classify by duty cycle, latency/egress sensitivity, data sovereignty, GPU/CPU mix and change frequency. (This aligns with the FinOps Framework’s move to clearer scopes/personas.)
  2. Build a portable TCO for each archetype.

    Include:

    • Compute & storage list vs. effective rates (by provider, by contract shape).
      Network: inter-AZ/region, internet egress, CDN and data-processing fees under realistic traffic flows.
    • Platform operations: security baselines, compliance attestations, incident SLOs.
    • People costs: platform engineering FTEs, FinOps & SecOps time, retraining for provider-specific stacks.
    • Exit/mobility: quantify lock-in risk and the value of optionality (especially for AI accelerators).
    • Regulatory offsets: where switching/egress relief applies in your jurisdictions.
  3. Stress-test scenarios.
    • 30% traffic growth, region failover, data-residency change, GPU scarcity, or a 2× egress event.
    • Show the breakeven points where private/colo flips from worse to better (or vice versa).
  4. Decide with guardrails, not a cliff.
    Convert the analysis into policy: when a workload exceeds X egress per revenue unit, or maintains Y% duty cycle for Z months, trigger a platform review. That keeps you agile without committing to a risky all-or-nothing migration.

How OpExx helps you make (and defend) the call

We designed our approach to complement existing FinOps tooling, not replace it.

  • Scope-aware inventory. We tag workloads by business capability and network shape, not just account/subscription, so finance and engineering talk about the same thing.
  • Provider-neutral TCO engine. We plug in your real contracts and simulate equivalent shapes across AWS, Azure, GCP and private/colo options, with realistic network paths and failure domains. (Ingress vs. egress vs. inter-region adds up differently on each platform.)
  • Decision playbooks, not just charts. When the model says “move,” you get the runbook: minimal viable port, sequencing and KPI guardrails, plus the “abort” criteria if reality diverges.
  • Executive-ready narrative. We translate savings, risk and time-to-impact into CFO/Board language so you can make a choice you can stand behind.

The takeaway

FinOps has matured into a robust cost-operations discipline. But the strategic question; “Is hyperscale the best choice for this workload for the next 12–36 months?”, demands a broader, provider-neutral view of TCO, risk and mobility.

If you want that answer for your portfolio, OpExx can take you from “we think so” to “here’s the model, here’s the breakeven, here’s the plan.”

Let’s pick one critical workload and put it through the model. We’ll show you, with your numbers, whether your current cloud is still the right home, and what to do if it isn’t.

Related Blog Posts