6 min. read
A typical mid-sized mechanical engineering company distributes its workloads across three hyperscalers without ever knowing the total bill. A cloud broker and a disciplined FinOps practice can meaningfully cut that multi-cloud invoice – in well-run programs, by around 30 percent. This anonymised case study reconstructs a realistic scenario and shows which levers actually matter and where the savings come from hard work rather than magic.
Key Takeaways
- Cloud brokers create visibility before negotiation: Before the company could discuss discounts, it needed a consolidated view across all three providers. The broker delivered exactly that – a central intermediary layer for procurement and billing.
- The 30 percent came from three sources: rightsizing underutilised instances, commitment discounts via Reserved Instances and Savings Plans with each individual provider, and shifting portable workloads to wherever they run cheaper per unit of performance.
- FinOps is operations, not a project: The biggest lesson was organisational. Without a firm cost mandate shared between the finance department and the platform team, the savings would have evaporated within two quarters.
Related:Frontier Model Taken Offline by Regulatory Order: The Architecture Lesson / Disaggregated Inference: Why AWS and Cerebras Are Separating the GPU
What Is a Cloud Broker?
What is a cloud broker? A cloud broker is an intermediary between a company and multiple cloud providers. It consolidates procurement, billing, and in some cases technical management across AWS, Microsoft Azure, Google Cloud, and smaller specialist providers. Instead of negotiating with each hyperscaler separately, purchasing runs through a central layer that aggregates consumption, negotiates discounts, and delivers a unified cost view.
In the DACH region, this model has so far seen limited adoption. At many mid-sized companies, workloads were placed with whichever provider happened to be convenient at the time, and a consolidated invoice never materialised. That is precisely where the case described here begins: the engineering company had production workloads on AWS, a Microsoft-365-adjacent landscape on Azure, and several data analytics workloads in Google Cloud. Three contracts, three billing logics, no overall picture.
Initially, the broker’s role was not to save money but to translate. Only once all consumption appeared in a single view did it become clear where the money was actually going.
The Starting Point: Three Providers, No Cost Control
Before the project, cloud procurement ran in a decentralised fashion. Individual teams booked resources as needed, and no one consolidated the invoices. The finance department saw only three monthly line items that kept rising – without anyone being able to explain the increase.
The classic symptoms of a multi-cloud environment without FinOps were plainly visible. Development environments ran around the clock even though they were only used during business hours. Database instances were sized for peak loads that never arrived. Snapshots and old volumes accumulated because no one was responsible for deleting them. And across all three providers, almost everything was billed at full list price, since no Reserved Instance or Savings Plan agreements were in place.
The broker’s initial inventory found that a significant share of spending went to resources that were either over-provisioned or simply forgotten. This is not unusual. Industry studies have documented the pattern extensively: unused and oversized capacity is widely recognised as one of the largest drivers of cloud waste.
The Three Levers That Actually Moved the Needle
The roughly 30 percent in savings did not come evenly across the board. It came from three clearly separable measures, implemented in this order.
First: rightsizing. The platform team compared actual utilisation against booked capacity and scaled down over-provisioned instances. Unused development environments received automatic shutdown schedules outside working hours. Orphaned volumes and snapshots were removed systematically. This step delivered the fastest results because it required no contract negotiations.
Second: commitment-based discounts. For stable, continuously running workloads, the company agreed on Reserved Instances and Savings Plans. Such commitments are provider-specific – they are concluded separately with AWS, Azure, and Google Cloud respectively. The advantage of the broker layer lies in procurement: it pools total volume and thereby achieves better terms than the company could negotiate with each provider individually. Compared to pure on-demand pricing, discounts on longer-term commitments run well into the double-digit percentage range, depending on provider and term length.
Third: workload placement. Some analytics workloads were neither tied to a specific provider nor latency-sensitive. They migrated to wherever compute was cheapest per unit. This is the most demanding lever, as it requires architectural work and only applies where neither data residency nor latency requirements stand in the way.
| Lever | Effort | Impact |
|---|---|---|
| Rightsizing and shutdown scheduling | Low, fast to implement | Immediately visible, biggest quick win |
| Reserved Instances and Savings Plans | Medium, negotiation required | Stable, ongoing savings with commitment |
| Workload placement | High, architectural work required | Effective only for portable workloads |
Source: Internal representation of the FinOps programme described.
The Tools and Metrics That Made the Difference
On the technical side, the programme relied on a cost management platform provided through the broker that normalised data across all three providers. What mattered less was the specific tool and more the standardisation it enabled: only once AWS, Azure, and Google consumption could be compared within a common framework did it become meaningful to evaluate workloads against one another.
As steering metrics, the company established a small but consistently tracked set of KPIs. These included cost per business unit rather than just the overall total, the share of spending covered by commitments, and the ratio of unused resources. These FinOps metrics are widely used in practice because they tie costs to value creation rather than to raw infrastructure size.
A tagging framework ensured that every resource was assigned to a team and a cost centre. Without that assignment, any cost analysis remains piecemeal – because no one is definitively accountable.
Lessons Learned: Where the Project Nearly Fell Apart
The technical levers were identified quickly. The real obstacle was organisational. The platform team could make recommendations, but had no mandate to enforce them against the business units. Shutdown schedules remained theoretical at first, because individual teams defended their always-on workloads.
Only when management and finance gave the platform team a clear cost mandate did the measures take lasting effect. FinOps only works as a permanent operating mode with clear accountability – not as a one-off clean-up exercise. If the discipline is not institutionalised, waste returns within a few quarters as new workloads repeat the same mistakes.
The second lesson concerned the broker itself. An intermediary layer of this kind reduces direct access to the hyperscalers and creates a dependency. The company therefore deliberately kept the technical know-how in-house, using the broker for procurement and transparency – not as a substitute for its own cloud expertise.
Frequently Asked Questions
What does a cloud broker cost, and is it worth it for mid-sized companies?
Brokers typically charge a margin on brokered volume or a service fee. For companies with significant multi-cloud spending and no in-house FinOps team, the model can pay off: bundled volume and greater transparency often produce savings that outweigh the broker fee. For small, straightforward single-cloud setups, the overhead rarely makes sense.
Does a cloud broker increase the risk of vendor lock-in?
It does introduce a new dependency on the broker layer. The best way to counter this is to keep cloud expertise in-house, negotiate contracts with clear exit clauses, and use the broker primarily for procurement and transparency – not for mission-critical technical management.
Where did the 30 percent savings actually come from?
From three sources: rightsizing and shutting down unused resources, commitment-based discounts through Reserved Instances and Savings Plans, and shifting portable workloads to whichever provider offered the best price at any given time. The biggest immediate impact came from the cleanup; the most durable long-term gains came from the commitments.
Do you need a dedicated team for FinOps?
Not necessarily a dedicated team, but clear ownership. What matters is a cost mandate that connects finance and the platform team, and a small set of metrics that are tracked consistently. Without that organisational anchor, any savings will evaporate within a few quarters.
Which workloads are suited for cross-provider placement?
Primarily portable workloads with no hard dependency on proprietary services, no strict data-residency requirements, and no tight latency constraints. Classic candidates are batch and analytics workloads. Tightly integrated, latency-sensitive, or regulatory-bound systems are better left where they already run.
More from the MBF Media Network
Image source: Unsplash / Lightsaber Collection
