Cloud spend has gone from a manageable line item to one of the largest controllable cost categories in most modern organisations. It has also gone from a centrally negotiated capital expense to a continuously incurred operational expense driven by thousands of individual engineering decisions. The combination — material spend, decentralised drivers — produces predictable patterns: bills that grow faster than business, surprise charges nobody anticipated, optimisation projects that produce one-time savings followed by drift back toward the prior level. FinOps is the operating discipline that addresses this structurally.
What FinOps Actually Is
FinOps is a cultural practice and operating discipline that brings engineering, finance, and the business together to make accountable, data-driven cloud financial decisions. The FinOps Foundation framework defines six principles, three lifecycle phases (Inform, Optimize, Operate), and a set of capabilities organisations build over time. The discipline is not a tooling category, even though tools support it. It is a cross-functional practice that requires organisational commitment.
The Three Lifecycle Phases
Inform — visibility into cloud spend, allocation to teams and products, forecasting, and benchmarking. This is the foundation. Without it, neither optimisation nor operation works because nobody can see what is happening. Optimize — actually reducing spend through rightsizing, commitment-based discounts, architectural changes, and elimination of waste. This is where the visible savings come from. Operate — sustaining the gains through governance, automation, embedded engineering practices, and ongoing accountability. This is what prevents the optimisation gains from eroding within two quarters.
Where the Real Savings Live
- Rightsizing — instances and services running larger than they need to be, often by 2-3x
- Commitment discounts — Reserved Instances, Savings Plans, committed-use discounts on stable workloads
- Storage tiering — data on premium-cost storage that has not been accessed in months
- Idle resources — non-production environments, forgotten projects, orphaned volumes and snapshots
- Architecture choices — workloads on expensive services that could run on cheaper ones with similar outcomes
- Commercial structure — enterprise discount programmes, marketplace deals, vendor negotiation timing
A pattern that almost universally surfaces in FinOps engagements: 20-40% of cloud spend goes to resources that are oversized, idle, or running in non-optimal commercial structures. The first round of optimisation is large and fast. The harder discipline is preventing the same waste from re-accumulating in the next year as new teams launch new workloads with the same defaults that caused the original waste.
Allocation: The Foundation of Accountability
Cloud spend allocated to a single shared account that nobody owns is spend nobody manages. Allocation by team, product, environment, and customer (where applicable) is the precondition for accountability. Tagging strategy, account structure, and chargeback or showback decisions are the building blocks. Most organisations have allocation that works for the largest cost centres and degrades into ambiguity at the long tail. Investing in allocation quality pays back disproportionately because every other FinOps capability depends on it.
Engineering Engagement: The Hardest Part
FinOps frequently fails when it operates as a finance-led activity that bombards engineering with cost reports. Engineers ignore the reports because the reports do not change what they should do today. FinOps that succeeds embeds cost as a first-class engineering metric — visible in the same dashboards engineers already use, attributed to the team or service the engineer owns, with cost-relevant feedback in the same review cycles where performance and reliability are discussed. The cultural shift is more important than any tool.
How to Build the Practice
Start with visibility. Get spend allocated and forecasted before optimising — without baseline understanding, the optimisation work cannot be prioritised. Tackle the highest-value optimisation opportunities first; the early wins fund the rest of the programme. Build the operating model that prevents drift — embedded cost ownership, automated guardrails, regular review cadence. Treat the function as a permanent capability rather than a project. The organisations that get sustained value from FinOps treat it as ongoing operating discipline, not as a periodic optimisation exercise.