FinOps: the practical levers that cut your cloud bill

July 15, 2026 · 3 min read · SOVALYX Technologies

A cloud bill does not shrink thanks to a one-off audit, but thanks to a discipline: seeing who consumes what, sizing to reality, paying each workload at the right rate — and recognising the moment when dedicated infrastructure becomes cheaper than on-demand elasticity. Here are the FinOps levers, in the order they pay off.

Visibility first: you cannot reduce what you cannot see

A global cloud bill is unreadable by design: thousands of lines, technical labels, no link to your products. The first lever saves nothing directly but conditions all the others: enforce tags on every resource — service, team, environment — and publish the monthly cost per service to the teams that generate it. That simple display changes behaviour without a single directive: nobody enjoys being the most expensive team on the board.

The first findings are almost always the same: unattached storage volumes, reserved but unused IP addresses, snapshots several years old, test environments created for a demo and never switched off. This fat can be cut with zero functional risk, and it funds the rest of the effort.

Size to reality, not to the peak or to comfort

The second source of savings is oversizing: instances specced "large to be safe" at project launch and never revisited. Rightsizing relies on actual usage data — CPU and memory utilisation over several weeks — not on the intuition of whoever created the machine.

Two complements are essential:

• autoscaling: load peaks are handled by temporary elasticity, not by permanent oversizing that bills the peak all year round;
• switching off non-production: a staging machine running 24/7 costs several times its real usage. Shutting down development and test environments at night and on weekends is the best effort-to-gain lever there is.

Pay the right rate: reserved, on-demand, spot

For the same resource, the price varies widely with the purchasing model. The allocation rule is simple:

• steady, predictable workloads (databases, ERP, permanent services): reserved instances or commitment plans, trading duration for a substantial discount;
• variable workloads: on-demand pricing, precisely because you only pay for what you use;
• interruptible jobs (batch compute, rendering, mass testing): spot or preemptible instances, the cheapest of all, at the price of possible interruption.

The classic trap: committing for three years to an architecture you plan to redesign within one. Commitments are managed like a portfolio — cover the demonstrated stable base, never the optimistic projection.

Cold storage, egress — and the point where dedicated wins

Storage follows the same logic as compute: data read every day should not live alongside archives read once a year. Lifecycle rules automatically move data to cold then archive tiers — keeping in mind that retrieving an archive has its own cost and delay.

Egress fees are the item discovered too late: off-site backups, cross-region replication, large volumes served to users. They must enter the calculation before architecture choices, not after — and they weigh heavily in any exit scenario, as the cloud repatriation movement shows.

Then comes the lever public cloud providers rarely mention: for a steady, predictable workload running 24/7 — the central database, the ERP, the application core — continuously billed elasticity buys you nothing. A dedicated server or a private cloud at a fixed monthly cost often wins over three years, with no internal egress fees and no billing surprises. The sensible model is frequently hybrid: the stable base on dedicated infrastructure, peaks and exploratory projects in the public cloud. A migration to private cloud is priced precisely on that comparison.

FinOps checklist: the levers in order

• Tag 100% of resources and publish monthly cost per service and per team.
• Delete orphaned resources: unattached volumes, unused IPs, old snapshots.
• Switch off non-production environments at night and on weekends.
• Rightsize on measured usage, then automate elasticity for peaks.
• Cover the stable base with reserved capacity, never the optimistic projection.
• Tier storage by lifecycle and estimate egress before any architecture choice.
• Compare steady workloads over three years against a dedicated or private cloud scenario.

🧰 The companion tool: What does one hour of downtime cost you? — free · 2 minutes.

Reviewed and optimised by AI.