Skip to content
Cloudreason

Multi-cloud FinOps for a UK public sector organisation

£2.3m saved across a four-year engagement. £900k annual run-rate reduction.

£2.3m

saved over four years

£900k

annual run-rate reduction

4 years

of coordinated FinOps

Public sector · Azure + AWS

A large UK public sector organisation

The UK public sector now spends around £3 billion a year on cloud through the G-Cloud framework alone, and the wider public sector cloud market is estimated at roughly £6 billion. Very little of that spend sits in one tidy account with one accountable owner. It accumulates across departments, programmes and delivery partners, each procuring what they need, when they need it, on the platform that suited the project at the time.

This client was a case in point: a substantial estate spread across both Azure and AWS, with spend distributed across multiple independent engineering teams and third-party delivery suppliers. Each team could see, and to a degree control, its own corner of the estate. Nobody owned the total.

The problem

That structure has a predictable consequence: costs that belong to everybody belong to nobody. Suppliers optimise within their own contracts. Engineering teams optimise the workloads in front of them. Finance sees an invoice that no single person can explain, let alone reduce. And the tools don’t rescue you, because Azure and AWS each report cost in their own way, on their own billing model, with their own discount instruments, so even a diligent team ends up comparing apples with oranges.

There is also a quieter, structural problem that public sector organisations know well. A delivery partner has no natural incentive to shrink the estate it is paid to run. Nobody is behaving badly; the incentives simply point the wrong way. Without an independent function whose only job is the total number, the estate grows in line with the organisation’s ambitions and never shrinks in line with its actual needs.

What we did

Cloudreason worked across the organisation rather than within one part of it.

The first job was visibility: a single, coordinated view of spend across both platforms, normalised so Azure and AWS could be read side by side, and attributed to the teams and suppliers actually driving it. Cost allocation sounds administrative, but it is the foundation of everything else: until spend has an owner, no saving has an owner either.

The second job was method. We established a shared cost-management cadence across engineering teams, internal stakeholders and delivery suppliers: regular reviews in which savings opportunities were identified, given a named owner and tracked to completion, whether the change sat with an internal team or a third party. Commitment decisions, covering reservations and discount instruments on both clouds, were planned centrally across the whole estate rather than left to individual teams to get partially right, because commitment discounts reward exactly the kind of aggregate, long-horizon view that fragmented ownership makes impossible.

The third job was the one no dashboard does: carrying the client’s authority into supplier conversations. When an independent consultancy, working to the client’s numbers, asks a delivery partner why an environment is still running, the conversation is different from the one an overstretched internal PMO can have. Coordination was the deliverable; the savings were the consequence.

The results

Over four years the engagement delivered a total saving of £2.3 million, including a twelve-month run-rate reduction of £900,000: money removed from the ongoing baseline, not a one-off rebate.

Just as importantly, the organisation finished the engagement with something it did not have at the start: a shared set of numbers that engineering, finance and suppliers all recognise, and a working method for keeping the estate honest as it continues to change.

What made it work

Multi-team, multi-cloud cost management isn't a technical problem, it's a coordination problem. The savings came from getting suppliers, engineers and budget holders working to the same numbers.

Why this client isn't named

This is a real engagement with real numbers. We don't name clients on our website because we'd rather they weren't fielding sales calls for appearing here. If you'd like more detail, ask us and, where the client is happy, we'll arrange a direct conversation or reference.

← All case studies

Facing something similar?

Book a free consultation and we'll tell you honestly whether we can help, and what it would save.