38% Lower Cloud Costs: FinOps Case in Mechanical Engineering

A mid-sized mechanical engineering company from Baden-Württemberg, with around 600 employees, cut its monthly cloud bill by 38 percent in just six months. No new provider, no migration, no IT layoffs. Just four levers, pulled consistently. This case is condensed from multiple FinOps projects over the past two years, with typical industry benchmarks that align with FinOps Foundation data.

Key Takeaways

• 38 percent in six months is realistic, not spectacular. The FinOps Foundation cites 30 to 50 percent savings for full programs. This case sits in the lower mid-range because calculations were conservative.
• Four levers drive the savings. Savings Plans, rightsizing, shutting down dev and test environments, and cleaning up orphaned resources. None of these are new.
• The lever is the sequence. Without clear cost transparency, every optimization falls flat. The inventory isn’t a preliminary step—it’s the first move.

Related:The Inference Bill No One Budgeted For  /  AI Spending Is Pushing FinOps Teams Into New Budget Traps

The Starting Point: A Bill Nobody Read

The company manufactures custom machinery, has run production workloads in the cloud for about five years, and had recently racked up a monthly bill of around €80,000. The growth wasn’t the result of one bad call—it was many small ones. A workload here, a database there, a test environment left running after the project ended. The invoice arrived monthly, was paid, and never read.

That’s the norm, not the exception. Across industries, a significant share of cloud spending is wasted on unused or oversized resources. The engineering firm’s IT team knew this in broad strokes but lacked the mandate and tools to quantify it. The first step, therefore, wasn’t technical.

What FinOps meant in this case

What is FinOps? FinOps is the operational discipline of managing cloud costs as a shared responsibility between engineering, finance, and business teams. It combines cost transparency per workload with clear decision rules on when to purchase, downsize, or shut down resources. FinOps is not a tool—it’s a routine.

In the machinery manufacturer’s case, this began with one person being allocated one day per week to analyze the cloud bill by cost center and workload. No dedicated team, no certification, no new platform procurement—just a meeting room, provider billing data, and a spreadsheet. After three weeks, the first reliable allocation was ready. It revealed that nearly a third of spending went toward resources that were either over-provisioned or running idle outside business hours.

It was this single figure that created the urgency needed to sustain a FinOps program. A vague directive to cut costs goes nowhere. But a concrete line item showing that a particular test environment cost €14,000 in Q1 and sat idle for 19 of 24 hours? That doesn’t go unnoticed.

The four levers that made the difference

The 38 percent savings came from four actions. The order wasn’t random—it followed the risk profile: the changes that touched architecture the least came first.

First: Savings Plans and Reserved Instances. The single largest contributor, roughly 16 percentage points. For steady baseline workloads, buying on-demand is the most expensive option. Pre-committing a portion of capacity for one to three years can cut costs by up to 60 percent compared with on-demand rates, depending on the model. The manufacturer deliberately reserved only the baseline workloads it had run consistently for years, keeping commitment risk minimal.

Second: Rightsizing. Roughly 10 percentage points. Many servers had been over-provisioned from day one, when no one knew the real load. Provider utilization data showed instances running below 15 percent CPU for months. Downsizing by one or two tiers cut costs without users noticing.

Third: Shutting down dev and test environments. Roughly 7 percentage points. Non-production environments don’t need to run nights and weekends. A simple schedule that powers them down in the evening and back up in the morning nearly halves runtime. This measure costs almost nothing yet is often overlooked because no single team owns it.

Fourth: Cleaning up orphaned resources. Roughly 5 percentage points. Unassigned storage volumes, old snapshots, databases from completed projects, unused IP addresses—each is small, but collectively they added up to an afternoon’s effort for measurable savings.

Three Phases Over Six Months

The timeline wasn’t ambitious—it emerged from the sequence itself. Some levers act immediately, while others require observation before you pull them.

The most common sequencing mistake in practice: buying Savings Plans first because the discount is tempting, then rightsizing. The commitment is already tied to an instance size you’ll soon downsize. The commitment keeps running while the discount applies to a workload that no longer exists.

What Eats the Savings

A FinOps saving isn’t a one-time effect; it’s a state you must maintain. These patterns have either sustained savings or erased them within a single quarter.

Often it’s the second half that fails, not the first. Achieving the saving is a project with a clear end. Keeping it is a habit without one. The machinery maker solved it pragmatically: the cloud-cost KPI now appears in the monthly executive report. What’s on that page gets read.

Cloud costs don’t drop because of a better tool, but because one person has the mandate—and a calendar entry.

What can be applied to other businesses

The 38 percent is not a promise. A company that already buys in a disciplined way will see smaller gains. One that has never paid attention often sees much larger ones. What’s transferable isn’t the number, but the process.

Getting started doesn’t require a platform or a team. It requires one day a week of someone who can do the math and has the mandate to act. Every provider already holds the billing data; the utilisation metrics are there too. After three weeks of work, you’ll have a number. And a number is the beginning of every cloud-cost discussion that doesn’t end in vague estimates.

Frequently Asked Questions

Image source: AI-generated (May 2026), C2PA certificate embedded in image