6 Min. read time
At the end of the month, the cloud bill arrives-noticeably higher than the previous month-and no one in the room can immediately pinpoint which workload caused the spike. This scenario is playing out in IT departments across the board as they juggle AWS, Azure, and Google Cloud. The money’s been spent, but accountability is missing. Those who take FinOps seriously flip the script: visibility first, savings second. That’s when the marketing promise of 30% cost reductions becomes a verifiable audit result.
Key Takeaways
- Visibility before cost-cutting: Without consistent tagging and euro-based showback across all three clouds, teams are optimizing blind-and still paying in the wrong accounts.
- 30% is realistic, but not automatic: The figure holds true where basic discipline is lacking-untagged, oversized spend without commitments or storage tiering.
- Guardrails ensure success: Budget limits, anomaly alerts, and fixed showback routines prevent savings from evaporating in the next sprint.
Related:FinOps sees everything, but can’t act / AI sovereignty starts with infrastructure
Making costs visible: Tagging, showback, and the euro question across three clouds
Most multi-cloud bills aren’t too high because the prices are excessive. They’re too high because no one actually reads them. AWS Cost Explorer, Azure Cost Management, and Google Cloud Billing each offer their own perspective-with their own logic, often in a foreign currency. Without consolidating these three worlds into a single view, you only see totals, not causes.
The first lever isn’t discounts-it’s tagging. Every workload needs a cost center, a team, and a purpose as a tag. Only then can you implement showback, showing each department its actual consumption. In practice, the hurdle is rarely technical; it’s almost always discipline. A single untagged project account is enough to keep flying blind. Industry surveys consistently identify around a quarter to a third of cloud spend as avoidable waste, most of which is simply unassigned.
In the DACH region, there’s an additional factor missing from U.S. guides: currency. Bills often arrive in foreign currency, while internal budgets are in euros. Without accounting for FX fluctuations, you’re comparing apples to oranges every month. Add data residency and EU regions, which may intentionally cost more because a GDPR-compliant setup carries a premium. That premium should be budgeted and disclosed-it’s part of the bill, not a savings target.
The Big Levers: Where the 30 Percent Really Lies
This waste is also the savings potential. Once costs become visible, the real work begins-and it follows a strict sequence. The single biggest lever is rightsizing, including shutting down unused resources: instances running overnight and on weekends, with no one needing them, account for 15 to 25 percent of the compute budget. This isn’t a one-time downsizing exercise; it requires two to four weeks of real usage data.
The second block is commitments. Reserved Instances, Savings Plans, Azure Reservations, and Google Cloud’s Committed Use Discounts cut the cost of stable workloads by 20 to 40 percent. The key word here is *stable*: if you know predictable workloads over twelve months, the savings are significant. If you buy on speculation, you’ll end up paying more than on-demand. For fault-tolerant jobs-like batch processing, CI/CD, or dev and test environments-Spot or Preemptible capacity can slash costs by 50 to 70 percent.
The third block is almost always underestimated: storage and data transfer. Lifecycle rules that automatically move cold data to cheaper tiers-such as Glacier, Azure Archive, or GCP Coldline-save 30 to 60 percent on storage costs. And egress traffic is the classic multi-cloud killer: replicating data between AWS, Azure, and Google Cloud without a clear business case can inflate the total bill significantly-up to a quarter for data-heavy setups. These percentages apply per cost line, not cumulatively. When you add up the typical spend mix of unused compute, expensive storage, and avoidable egress, the total often hits around 30 percent-assuming little prior optimization. But this isn’t a guarantee for every maturity level. Presenting it this way to the board is exactly how it should be done.
Enforcing Budget Controls: Guardrails, Alerts, and Escalation Before Month-End
Savings that aren’t locked in last exactly one sprint. A common mistake in FinOps projects is treating optimization as a one-off task. That’s why governance is the final link in the chain: budgets with hard and soft limits, policies against untagged resources, and anomaly alerts that flag deviations before the bill arrives.
But technology alone isn’t enough-rituals matter just as much. A monthly showback meeting, where each team sees its own numbers, drives behavioral change more effectively than any technical measure. Once someone has to explain why a test cluster ran for three weeks, they’ll tag resources properly next time. FinOps succeeds through data and accountability, not tools. The tool shows the costs-but whether that translates into margin is up to the organization.
Frequently Asked Questions
Are 30 percent savings in multi-cloud realistic?
Yes, but not everywhere. The figure applies where basic discipline is lacking: untagged spend, oversized instances, no commitments, and no storage tiering. Those who have already optimized will see less. The claim is only credible with a spend baseline and maturity assessment.
Where does a FinOps project begin?
With visibility-long before discounts come into play. First, implement consistent tagging and a consolidated view across AWS, Azure, and Google Cloud, then introduce showback by department. Without this foundation, the team optimizes blindly and may cut costs in the wrong places.
Which lever delivers the biggest impact?
In most environments, rightsizing combined with shutting down unused resources, accounting for 15 to 25 percent of the compute budget. Commitments and spot capacity can yield even higher percentages for suitable workloads, but these only apply to stable or fault-tolerant loads.
What should you consider when transferring data in multi-cloud?
Egress fees between hyperscalers are costly and often unnecessary. Replicating data across AWS, Azure, and Google Cloud without a clear business case can inflate the total bill by up to a quarter in data-heavy architectures. Architecture and data flows should come before chasing discounts.
What DACH-specific factors come into play?
Primarily currency and data residency. Cloud bills often arrive in foreign currency, while budgets are set in euros-exchange rate fluctuations must be factored into planning. EU regions and GDPR-compliant setups may cost more. This premium is budgeted and disclosed, as it’s a fixed part of the bill.
More from the MBF Media Network
Image source: AI-generated (June 2026)
