Rightsizing is not a project. It is a practice. One-time optimization creates short-term savings that erode the moment usage patterns shift, which they always do.
The rightsizing paradox
You ran a cloud rightsizing project. Your team spent weeks analyzing utilization, identifying over-provisioned instances, and implementing changes. You generated real savings, maybe six figures, maybe more. Everyone was pleased.
Six months later, the bill is back where it was. Or higher.
This isn't a failure of execution. It's a failure of framing. Rightsizing was treated as a project with a finish line, when the actual problem, cloud environments growing faster than governance, is continuous.
Why savings erode
Cloud environments are not static. Every sprint ships new infrastructure. Every new team spins up resources. Every growth event adds capacity. And unless someone is continuously watching the relationship between what's provisioned and what's actually used, drift is the default.
The three most common drift patterns we see:
Provisioning ahead of demand. Engineering teams, reasonably, provision for anticipated load. When the anticipated load doesn't materialize, or materializes differently than expected, the provisioned capacity stays. No one is watching it, and no one has the authority to scale it back without going through a change management process that nobody wants to trigger.
Orphaned resources from deprecated projects. When a project ends, its cloud resources often don't. Instances, storage volumes, snapshots, and load balancers associated with discontinued features continue to run and accrue cost. They're not serving anyone. They're just there.
Reserved instance misalignment. Reserved instances and savings plans create significant discounts, but only when they're matched to actual usage. When usage patterns shift (new services, new architectures, team reorganizations), reserved commitments frequently end up misaligned. You're paying for a commitment that no longer reflects how you're actually running.
What continuous FinOps looks like in practice
Continuous cloud financial management isn't a tool, it's a governance discipline. The tools matter, but only insofar as they support the practices.
At a minimum, continuous FinOps requires: regular (at least monthly) review of utilization against provisioned capacity by workload; a clear owner for cloud cost governance with the authority to make or recommend changes; tagging discipline that enables cost attribution to teams, projects, and environments; and a defined process for retiring resources associated with deprecated work.
None of this is technically complex. All of it requires organizational commitment, specifically, the commitment to treat cloud spend as a continuously managed asset rather than a utility bill that arrives monthly.
The visibility problem
Most organizations have access to cloud cost data. They have dashboards. They have billing reports. They have anomaly alerts. What they often lack is a coherent view that connects cost to business value, and a governance model that makes someone responsible for closing the gap when costs drift from value.
Visibility without accountability is just monitoring. You can see the problem growing. You just can't make it stop, because no one owns it in a way that creates the authority to act.
Effective FinOps connects visibility to accountability by making cost governance part of how engineering teams plan and operate, not an external audit function that shows up periodically to point out what went wrong.
What to do if you're in this situation
If you've run rightsizing projects and watched the savings erode, the first question to ask isn't "what did we miss", it's "who owns this on an ongoing basis."
If the answer is "our last rightsizing engagement did," you don't have a FinOps practice. You have a history of FinOps projects. The distinction matters, because projects end and drift resumes the moment they do.
Building a real practice means assigning ownership, establishing cadence, creating accountability structures that connect engineering decisions to cost outcomes, and treating cloud financial management as an operating discipline rather than an optimization event.
It's more work than a project. It's also the only thing that actually works.