The first FinOps review for a cloud environment that has grown organically — provisioned by engineering teams responding to immediate needs rather than under a coherent cost-governance model — almost always finds the same things. Oversized instances. Reserved instances bought for workloads that no longer exist. Orphaned snapshots. Dev and staging environments running continuously when they are used only during business hours.
In our managed cloud practice, the post-migration FinOps review typically finds 25–40% of the provisioned spend that can be reduced without impacting any production workload. The range reflects the degree to which cost was thought about at provisioning time.
Year one of FinOps is the easy year. The quick wins are visible and the savings from right-sizing, reserved-instance alignment, and cleanup are immediate. Year two is harder because the easy targets are gone and the remaining opportunities require changes to the architecture or the development practice rather than just the configuration.
The architectural opportunities — moving to managed services that cost less at scale than self-managed equivalents, introducing caching layers that reduce compute and data-transfer cost, moving appropriate workloads to spot or preemptible instances — require engineering investment to realise. The savings are real and often substantial, but they require prioritisation against feature work.
The development-practice opportunities are harder still. Cloud cost is a consequence of architectural decisions made during development, and influencing those decisions requires FinOps to be present in the design process rather than in the operations review. Unit-economics thinking — cost per transaction, cost per API call, cost per active user — has to be embedded in engineering culture rather than applied retroactively.
The organisations that sustain FinOps outcomes across multiple years are those that have embedded cost visibility into their engineering practice, not those that run a periodic optimisation exercise.