After the Big Rocks Are Gone

A practitioner quoted in the 2026 State of FinOps report described where their team is now: "We have hit the big rocks of waste and now face a high volume of smaller opportunities that require more effort to capture."

Another said they reached 97% in their Cost Optimization Hub, with the remaining 3% intentionally left unactioned for business reasons.

These are not complaints, they are signals of something maturing. The issue is that most FinOps tooling, most frameworks, and most conversations are still built for the phase before this one. Finding idle resources, purchasing Reservations for uncovered compute, cleaning up zombie workloads. That phase produced visible savings quickly. For a growing number of organizations, it is done.

What comes next requires a different approach. It is worth being honest about what that means.

What ESR Tells You and Where It Stops

ESR, or Effective Savings Rate, is the closest thing FinOps has to a single headline number for rate optimization. It measures the discount realized across cloud spend relative to what the same usage would have cost at full on-demand pricing. It accounts for commitment coverage (the share of usage protected by discount instruments like Reserved Instances or Savings Plans), utilization of those commitments, and the actual discount rate achieved.

The 2025 rate optimization study from ProsperOps, drawing on anonymized AWS compute usage data, showed the largest organizations (above $10 million in annual compute usage) reaching a 38% median ESR but with minimal year-over-year improvement despite higher commitment coverage. They were approaching a ceiling.

At high coverage levels, adding more commitments produces smaller incremental gains. And the commitment risk, being locked into capacity that becomes underutilized if workloads shift, starts to outweigh the discount benefit.

This is what a coverage ceiling looks like: the work has been done, the ESR is competitive, and the only way to improve it meaningfully is to accept commitment risk you probably should not take or to find savings in dimensions ESR was never designed to measure.

What ESR Does Not See

ESR measures the rate you are paying per unit of compute. It does not measure whether you need the unit.

A workload running at 8% CPU utilization with 100% Reservation coverage has a good ESR and a waste problem. The discount is working, but the resource is not.

This is where the focus shifts in mature environments. The actionable surface moves toward workload optimization: rightsizing instances provisioned with conservative headroom that was never reclaimed, decommissioning resources from completed projects, rethinking storage tiers for data not accessed in months, finding data transfer patterns that generate egress costs invisible in standard reporting.

These opportunities are legitimate; they are also smaller, more distributed, and slower to validate than purchasing a Savings Plan. Each one requires engineering judgment about what can be changed without breaking something. The path from recommendation to action has more friction. Teams that notice the same recommendations appearing on the list every quarter without the list shortening are usually looking at a broken handoff between FinOps and engineering, not a shortage of real opportunities.

The Governance Gap

There is a pattern to identify: savings erode over time if governance does not hold them in place.

A team runs a cleanup sprint. Forty idle instances removed, sixty oversized VMs rightsized, dev and test workloads scheduled to stop overnight. By the following quarter, half of the savings have been offset by new resources provisioned without the same review. This is not because engineers are being careless, it is the default behavior in most cloud environments. It is to provision at the safe size and leave things running until someone says otherwise.

This is what the governance priority shift in the 2026 State of FinOps data is pointing at. Teams are moving from reactive optimization toward proactive policy: budget controls, tagging compliance enforcement, anomaly detection, real-time cost monitoring at the team level.

For a finance audience: optimization savings are a one-time event. Governance converts them into a recurring line by changing the default behavior. Tagging policies that block untagged resources from running in production, budget alerts at the team level, architectural review processes that include cost as a criterion. These make savings durable rather than temporary.

The Scope Expansion Problem

Two years ago, 31% of practitioners reported managing AI spend. Today it is 98%. SaaS is now in scope for 90% of respondents. Licensing, private cloud, and data centers are being added to the mandate.

Teams that just worked through public cloud optimization are being handed SaaS portfolios and told to apply the same discipline. The playbook does not transfer directly. You cannot rightsize a software license the way you can rightsize a VM. The savings mechanism is contract renegotiation or vendor consolidation, which is slower and requires different skills. The optimization cycle has to restart from the beginning in each new category, at a different maturity stage, with the same small team.

Each technology category has its own big rocks and its own eventual ceiling. Cloud is further along that curve than SaaS. SaaS is further along than AI. A mature FinOps practice is running multiple optimization cycles simultaneously at different stages, with governance holding the earlier ones in place while the newer ones are still in their discovery phase.

The organizations doing this well are tracking cost at the unit level (cost per customer, cost per product feature, cost per inference request), building governance into the workflow rather than adding it as a review step, and resetting expectations with leadership about what the next phase looks like.

Sustained efficiency across a broader scope, with the discipline to keep what was already gained.