FinOps reduces cloud spend by making cost attributable, eliminating waste, then committing to discounts and improving unit economics. The order matters: commitments signed before waste is removed lock in the cost of resources you should have deleted.
Allocation and accountability
Cost optimisation without attribution is an exercise in guessing. Every resource needs tags for owner, environment, service and cost centre, enforced at creation time by policy rather than added retrospectively by a human. Untagged resources should fail to deploy.
Once allocated, cost must reach the people who can change it. That means per-team dashboards showing spend against budget, and a monthly review where variances are explained rather than merely reported.
Shared costs, such as networking, observability and platform services, need an explicit allocation rule. Common approaches are proportional to consumption or a flat platform charge. The method matters less than choosing one and applying it consistently.
- Enforce required tags at creation via policy.
- Publish per-team cost against budget monthly.
- Define a consistent rule for allocating shared costs.
- Fail deployments that lack required tags.
Eliminating waste
Waste is usually the first and largest opportunity. Typical sources are oversized instances running at low utilisation, orphaned storage volumes and snapshots, idle load balancers, non-production environments running continuously, and log or metric retention longer than anyone uses.
Right-sizing should be driven by observed utilisation over a representative period, not by intuition. A resource consistently below twenty percent CPU and memory utilisation is a right-sizing candidate; one that peaks above eighty percent is not.
Scheduling non-production environments to shut down outside working hours is one of the highest-return, lowest-risk changes available, and it is frequently left undone because it requires a small amount of coordination.
| Source | Detection | Action |
|---|---|---|
| Oversized compute | Low sustained utilisation | Right-size or move to burstable |
| Orphaned volumes and snapshots | Unattached resource inventory | Delete with retention policy |
| Idle non-production | Scheduled shutdown absent | Schedule off-hours shutdown |
| Excessive log retention | Retention versus access review | Tier to cold storage, shorten retention |
| Over-provisioned databases | Read replica utilisation | Reduce replicas, right-size instances |
| Data egress | Traffic analysis by destination | Co-locate workloads, add caching |
Commitments and purchasing
Discount instruments such as savings plans, reserved capacity and committed use discounts trade flexibility for price, typically in the range of twenty to fifty percent depending on term and coverage. The right coverage is a function of your stable baseline, not of your peak.
Buy commitments only after waste is removed and right-sizing is complete. Committing to a baseline that includes oversized instances converts a temporary inefficiency into a multi-year financial obligation.
Cover the baseline and let the variable portion run on demand. Over-committing is as costly as under-committing, because unused commitment is paid for regardless of consumption.
- Right-size and eliminate waste before purchasing commitments.
- Cover the stable baseline, not the peak.
- Review coverage and utilisation monthly.
- Model term length against realistic growth assumptions.
Unit economics
Total spend rising is not necessarily a problem if it rises slower than the business. The metrics that matter are cost per order, cost per active tenant, cost per thousand requests and cost per customer. These separate growth from inefficiency and make the conversation about efficiency rather than about a number going up.
Set an efficiency target, such as reducing cost per transaction by a defined percentage per year, and make it a shared objective between engineering and finance. Without a shared target, optimisation remains a periodic clean-up rather than a sustained practice.
Finally, build cost awareness into delivery. Show the projected monthly cost difference in infrastructure pull requests, so cost becomes a design input rather than a monthly surprise.
- Track cost per business unit of output, not just total spend.
- Set a shared annual efficiency target across engineering and finance.
- Show projected cost impact in infrastructure pull requests.
- Review unit economics alongside reliability metrics.
Frequently asked questions
How much can a FinOps programme realistically save?
Organisations that have never run one commonly find twenty to forty percent through waste elimination and right-sizing alone, with further savings from commitment coverage once the baseline is stable.
Should we buy reserved instances before optimising?
No. Committing before removing waste converts temporary inefficiency into a long-term financial obligation. Eliminate waste and right-size first, then commit to the remaining stable baseline.
What is the most useful FinOps metric?
Unit cost, such as cost per order, per active tenant or per thousand requests. It distinguishes genuine growth from inefficiency, whereas total spend rising says nothing on its own.
References
Engineer your next strategic platform
Estimate your project investment and delivery timeline instantly, or schedule an architectural discovery call with our engineering leadership.