Cutting Cloud Costs: FinOps Practices for Mid-Market Companies

The cloud invoice lands in the inbox on the first of the month, it’s a few hundred euros higher than last month, and nobody in the company can immediately explain why. We see this pattern over and over with mid-market clients: the migration happened two or three years ago, and the bill has been quietly creeping up ever since — regardless of whether the business is growing at the same pace.

The problem is rarely technical. What’s usually missing is a process that questions cloud spend on a regular basis. That’s what FinOps actually is: not a piece of software, but a set of recurring practices that get technical and finance stakeholders looking at the same numbers together, so cloud spend stays aligned with business value. For companies with 50 to 500 employees, that typically translates into savings of 20 to 40 percent on the running cloud bill, without touching performance or availability.

Why Cloud Costs Creep Up Unnoticed

Cloud resources can be spun up in minutes, but they’re rarely torn down at the same speed. A developer launches a test environment for a sprint, the project wraps up, the instance keeps running. An IT lead orders servers “one size up” ahead of the November peak and forgets to scale back down in January. After two or three years without anyone owning cost as a metric, a company typically ends up with a sizeable share of infrastructure that’s either idle or oversized for what it actually does.

The second reason is structural: the cloud bill sits with IT, the budget sits with leadership, and there’s no regular sync between the two. The invoice gets paid, but nobody systematically checks whether every line item is still needed. FinOps closes that gap through clear, repeatable routines rather than one-off cleanup sprints.

Rightsizing: the Biggest Lever, Pulled Least Often

The single most effective first step is almost always rightsizing existing instances. In our assessments at mid-market clients, average CPU utilization on production servers frequently sat between 8 and 15 percent — yet the instances had been provisioned “to be safe,” often one or two size classes above actual need.

A useful rule of thumb: an instance is a rightsizing candidate if it stays below 20 percent CPU and memory utilization over an observation window of at least two to four weeks (long enough to catch seasonal spikes like month-end close or payroll runs). AWS Compute Optimizer, Azure Advisor and Google Cloud Recommender all generate these recommendations for free and automatically, typically within a few days of being switched on.

How Rightsizing Plays Out in Practice

Sequencing matters: start with non-production environments, move to non-critical production systems, and only touch business-critical workloads last, with a maintenance window and a rollback plan in place. Most providers let you scale a downsized instance back up within minutes if the new size turns out too small, so the risk stays manageable as long as you work iteratively rather than resizing everything at once.

A frequently overlooked side effect: rightsizing routinely surfaces resources that have been completely orphaned — test servers whose project ended a year ago, database replicas nobody queries anymore. Shutting those “zombie resources” down costs nothing and often delivers a surprisingly large share of the total savings.

Reserved Instances and Savings Plans vs. On-Demand

Anyone who knows their baseline load and keeps paying on-demand rates for it is overpaying. Reserved Instances (AWS, Azure) and Compute Savings Plans offer discounts of typically 30 to 60 percent against the on-demand rate in exchange for a one- or three-year usage commitment — with three-year prepayment terms often pushing that discount considerably higher.

The commitment pays off for the portion of infrastructure that demonstrably runs around the clock: the ERP system, the production database, the central file server. For variable or seasonal load — the online shop during the holiday rush, month-end batch processing — on-demand or auto-scaling remains the better choice, because an unused reservation costs exactly as much as a used one.

When the Commitment Pays Off — and When It Doesn’t

A practical starting point: commit only workloads that have run consistently for at least three months, and start with a one-year term rather than a three-year one. That limits the risk of locking yourself into an instance size that no longer fits in two years. AWS and Azure now also offer flexible variants (Compute Savings Plans, Azure Reservations with instance-size flexibility) that let you switch instance family mid-term — which removes most of the lock-in risk.

A rough rule from practice: once more than 60 percent of compute capacity is demonstrably needed on a permanent basis, a one-year reservation typically pays for itself against on-demand pricing within four to six months.

Egress Costs: the Bill Nobody Budgets For

The most consistently underestimated cost category is data egress. Unlike traffic flowing into the cloud, every gigabyte leaving it comes with a price tag — typically between €0.08 and €0.12 per gigabyte depending on provider, destination region and volume. For companies handling video content, large reporting exports, or backup replication to a second region, that adds up quickly to several hundred or even a few thousand euros a month.

Three egress traps show up again and again. Cross-region replication, set up for compliance or availability reasons, often ends up mirroring far more data than necessary. Backups get exported to a different cloud or provider without anyone checking the bandwidth cost first. And content gets served directly from a storage bucket instead of through a content delivery network — a CDN not only speeds up load times for customers but frequently cuts egress costs by 30 to 50 percent, since repeat requests are served from cache instead of the origin.

A quick diagnostic: filter your monthly cloud invoice by the “data transfer” or “network” cost category. If that line accounts for more than 5 to 8 percent of total spend, there’s likely untapped savings in your network architecture.

Tagging and Cost Center Transparency

None of the measures above hold up over time without an answer to one simple question: who in the company is causing which cost? Without consistent tagging, the entire cloud bill shows up in accounting as a single line item — nobody can trace it back to a department, project or product, and as a result nobody feels responsible for it either.

A workable tagging scheme needs only a handful of mandatory fields: cost center, environment (production, test, development), project or application, and an owner. Those four tags are enough to break the cost report down by department or project, flag unused test environments automatically, and deliver cost-center-level reporting to business units at month-end. What matters is enforcing tagging technically — through a policy that blocks the creation of untagged resources — rather than relying on developers’ goodwill. In our experience, voluntary tagging guidelines tend to fall apart within a few months.

The Monthly Cost Review: FinOps as a Process, Not a Project

A one-off cleanup lowers the bill for a quarter or two — after that it creeps back up, because the same mechanism that inflated costs in the first place is still in place. The real difference between a one-time project and genuine FinOps is a fixed monthly meeting where IT leadership and someone from finance or controlling walk through cost trends together.

A working review takes 30 to 45 minutes and follows a fixed agenda: variance against last month and against budget, the largest individual cost items, newly identified rightsizing candidates, reservations expiring soon, and any unusual cost spikes on individual tags or cost centers. Most providers ship the reporting needed for this out of the box (AWS Cost Explorer, Azure Cost Management, Google Cloud Billing Reports); multi-cloud setups benefit from a dashboard on top that pushes budget-threshold alerts, instead of finding out at month-end.

A Worked Example: What FinOps Delivers in a Typical Mid-Market Company

To make the scale of this tangible, here’s an illustrative example modeled on a typical manufacturing company with around 180 employees (the figures are constructed for illustration, not an actual client case):

Starting point: a monthly AWS bill of €22,000 covering around 60 virtual servers spread across an ERP system, an online shop, a reporting database, and various test and development environments.

After three months of systematic FinOps work:

• Rightsizing oversized instances: 18 servers downsized, plus six orphaned test environments shut down → roughly €3,200 saved per month
• Compute Savings Plan for the baseline load: one-year commitment covering ERP and database servers that had demonstrably run continuously for over a year → roughly €2,800 saved per month
• CDN placed in front of the online shop, cross-region backup trimmed to the essentials → roughly €900 saved per month
• Unused resources cleaned up (orphaned snapshots, unattached IP addresses, stale volumes) → roughly €1,100 saved per month

Result: the monthly bill drops from €22,000 to roughly €14,000 — a reduction of about 36 percent, or nearly €96,000 a year, without a single application slowing down or going offline. Roughly three-quarters of that saving came from just the first two measures, rightsizing and reserved capacity — which matches what we see across industries: pulling those two levers consistently accounts for most of the work.

What to Do in the First 90 Days

Getting started doesn’t require building a full FinOps team on day one. A realistic timeline looks like this: in the first two weeks, turn on the cloud provider’s free rightsizing tools and let them collect three to four weeks of observation data. In parallel, introduce a simple tagging scheme with the four mandatory fields above and apply it retroactively to existing resources wherever that can be automated. By week six to eight, there’s enough data to act on the first rightsizing candidates and decide which share of the infrastructure is ready for a reservation. By week twelve, the monthly cost review should have a standing slot on the calendar — permanently, not just for the first quarter.

Conclusion

Cloud costs don’t come down through a one-off project; they come down through a process that runs for as long as the cloud usage itself does. The four levers — rightsizing, reserved capacity, egress control, and cost center transparency — can each be introduced independently, and nearly all of them pay for themselves within a few months. The harder part is rarely the technology; it’s the discipline to keep the monthly review on the calendar once day-to-day business gets in the way.

If you’re not sure where the biggest savings potential sits in your cloud environment, or want an independent look at your current cost structure, we’re happy to walk through your largest cost items with you in a first conversation and give you an honest read on where a deeper analysis would pay off. Schedule a no-obligation call.