The Business Case for FinOps: Building the ROI Model Your CFO Will Sign
Every VP of Engineering eventually gets the same request. The CFO asks why cloud spend is up 40% year over year, and the answer needs to be more precise than "the business is growing." A FinOps program is what turns that conversation from defensive to strategic. The business case for it is not hard to make. Most VPs just have not built the model.
This is the model. Numbers you can defend, categories you can populate from your own bill, and payback math your CFO will sign.
What is the total return of a working FinOps program?
Two components, both material.
- Year one savings. 8 to 15% of gross cloud spend, from rightsizing, commitment optimization, and orphaned resource cleanup.
- Ongoing annual savings. 3 to 6% per year after year one, from maintenance activities: catching anomalies within hours, tuning commitments quarterly, and keeping the unallocated bucket small.
The year-one number is the eye-catcher. The ongoing number is the reason FinOps stays funded. Together, a mature program returns 20 to 40% of what the cloud bill would have been over three years, if the program did not exist.
What do the savings buckets look like?
Break the year-one savings into five categories. Each has a realistic range and a typical time to realize.
| Category | Year 1 savings range | Time to realize |
|---|---|---|
| Rightsizing overprovisioned instances | 3 to 6% of gross spend | 30 to 60 days |
| Commitment optimization (Savings Plans, RIs) | 2 to 5% of gross spend | 60 to 90 days |
| Eliminating orphaned resources | 1 to 3% of gross spend | 30 days |
| Storage lifecycle policies | 0.5 to 2% of gross spend | 60 to 90 days |
| Network and data transfer fixes | 0.5 to 2% of gross spend | 30 to 60 days |
The categories are not additive to the top of every range; a savings program that hits the maximum in every bucket is not realistic. Expect the sum to land at 8 to 15%. If you are hitting more than 20% year over year, either the prior state was pathological or a major architectural change is being credited to FinOps that would have happened anyway.
What does a FinOps program cost to run?
Three lines. Everything else is discretionary.
- A dedicated FinOps lead. $150K to $220K fully loaded, depending on region and seniority. Not a part-time role for a controller.
- A cost management platform. $50K to $250K per year, depending on cloud spend. Bigger bills, bigger platform cost, but the ratio is usually 2 to 5% of gross cloud spend.
- Platform engineering time. 15 to 20% of two engineers, or roughly $80K to $150K per year in loaded cost. For implementing allocation rules, writing automation, and handling escalations.
Total: $280K to $620K per year for most mid-sized companies. If your program is projected to save $1M or more, the ROI is above 2x in year one, and above 5x steady state.
How do you build the savings model for the CFO?
Four inputs, one output. Populate each row from your own bill.
- Current gross cloud spend. The last 12 months of AWS, GCP, Azure, and Kubernetes billing. Not the net after commitments; the on-demand equivalent.
- Assumed savings rate. Start at 10%. Sensitize to 8% and 12% for a low and high case.
- Program cost. The three lines above, sized for your company.
- Time-to-savings curve. Ramp savings linearly from month 3 through month 9. Full run-rate by month 10.
Multiply the first two, subtract the third, apply the fourth, and you get a monthly cash flow curve. Compare cumulative savings against cumulative program cost. The crossover point is the payback.
For a company at $2M per month gross spend, the model looks like: $2M × 12 × 10% = $2.4M gross savings in year one, minus $500K program cost = $1.9M net. Payback lands between month 4 and month 6.
What are the failure modes of the business case?
Three, in order of frequency.
- Optimistic ramp. Assuming savings start on day 1 and hit full run-rate by month 3. Reality is that most savings begin in month 2 and take until month 9 to fully ramp. An overoptimistic ramp makes the business case fragile: the CFO sees the reforecast at month 6 and loses confidence.
- Ignoring the maintenance cost. Building the year-one case is easy. Sustaining it requires ongoing work, and the case must budget for it. A program that runs one big optimization project and then dies leaves savings on the table by year two.
- Confusing avoided cost with realized savings. Rightsizing an instance from $500 per month to $200 per month is a $300 per month realized saving. Deciding not to launch a new $500 per month instance is an avoided cost, not a saving. CFOs know the difference and will ask.
Address all three in the model. The credibility of the business case depends on realistic ramps, sustained investment, and honest categorization.
When do you not build a FinOps program?
Three cases where the ROI does not clear the bar.
- Cloud spend below $50K per month. Program cost consumes the savings. Use a fractional consultant and a lightweight tool. Revisit at $100K per month.
- Company is being sold or wound down. The payback horizon is longer than the ownership horizon.
- Engineering is in a full re-architecture. Savings from optimizing the old architecture are wasted if the new architecture ships in six months. Wait for the new architecture to stabilize, then run FinOps against it.
Outside these cases, the ROI math favors the program. The question is not whether to run it, but how fast to ramp.
How do you justify the platform investment specifically?
The FinOps lead needs three things a tool provides better than a spreadsheet.
- Allocation across clouds. Manual allocation across AWS, GCP, Azure, and Kubernetes is a full-time job by itself. A tool makes it a configuration.
- Anomaly detection. Statistical baselining per service per team is too much to build in-house for most companies. A tool ships it out of the box.
- Commitment planning. Modeling the optimal Savings Plan portfolio requires reading a lot of billing history. Tools do it in minutes; spreadsheets do it in days.
The build-vs-buy math almost always favors buy at any real cloud spend. A $100K per year tool that saves an FTE-worth of analyst time and unlocks 3% additional savings pays back in the first quarter.
What does the first quarter roadmap look like?
Ninety days, three objectives, all measurable.
- Month 1. Full cost allocation at 90% or better. Anomaly detection wired to team channels. Publish the unallocated dollars weekly.
- Month 2. First rightsizing wave complete. Orphaned resource cleanup underway. First Savings Plan tranche purchased.
- Month 3. Full 12-month commitment stack in place. Weekly cadence running. Report the first three months of realized savings to the CFO.
By day 90, you should be reporting a savings number to leadership. If you are not, the program is scoped wrong, not underperforming.
The mistake to avoid
The most common way a FinOps business case fails is not because the numbers are wrong. It is because the case promises savings in month 1 and delivers them in month 6, so the CFO stops trusting the model. Build the case with realistic ramps: some savings in month 2, most by month 6, full run-rate by month 10. Under-promise, over-deliver, and use the credibility from the first year to fund the ongoing program. FinOps is one of the highest-ROI investments a software company can make; the case just has to be built with numbers a CFO recognizes as reasonable.
Frequently asked questions
What is a realistic first-year savings target for a FinOps program?
8 to 15% of gross cloud spend. The range depends on starting maturity: companies with no prior FinOps effort typically hit the top of the range, while companies that have already done basic rightsizing land closer to the bottom. Above 15% is possible in the first year but requires meaningful architectural change, not just optimization. Below 8% suggests the program is not scoped correctly or lacks executive support.
What does a FinOps program cost to run?
For a mid-sized company at $500K to $2M per month in cloud spend, the ongoing cost is $250K to $500K per year. That covers one dedicated FinOps lead, a cost management platform, and 15 to 20% time from two platform engineers. Companies at scale often add a second FinOps analyst or a dedicated commitment planner. The rule of thumb: program cost stays under 15% of the savings the program delivers, or the ROI does not clear the bar.
How fast is the payback period?
Three to six months when the first quarter is scoped correctly. The fastest wins are eliminating orphaned resources, rightsizing overprovisioned instances, and buying the first tranche of Savings Plans. All three can move in the first 60 days. Payback slower than six months usually means the program is chasing architectural changes before harvesting the low-hanging fruit.
Should we build FinOps in-house or outsource it?
Build in-house for anything above $500K per month in cloud spend, with tool support. Below that, a fractional consultant plus a good platform can be enough. The reason to build in-house is that the ongoing work is 60% relational and 40% technical: getting teams to prioritize savings takes context and trust that a consultant cannot easily replicate. The consultant model works for the first project; not for the ongoing program.
How do you defend the ROI when engineering pushes back on the effort?
Two arguments. First, the savings are large and provable within a quarter, and the engineering time investment is bounded, usually 5 to 10% of two platform engineers. Second, the alternative to FinOps is a cost surprise in a board meeting, which costs more engineering time to explain than the program takes to run. Frame the program as insurance against fire drills, not as an additional burden.
Every cloud dollar gets an owner
Pyrenis allocates 100% of AWS, GCP, Azure, and Kubernetes spend to the teams that create it, catches anomalies in hours, and ships savings with real numbers.
Request early access