Skip to main content
emnode
Cost

Identified vs. realised cloud savings: the gap that sinks FinOps programs

Your tooling is great at finding savings. The number that matters is how much of it actually came off the bill, and most teams never measure it.

The Emnode team · · 7 min read

Every cloud cost tool on the market is good at the same thing: finding savings. Point one at your AWS or Azure account and within minutes it will hand you a list of rightsizing opportunities, idle resources, and commitment gaps adding up to a big, satisfying number. That number is your identified savings, the total of everything that could be saved if every recommendation were acted on.

Realised savings is a different number entirely. It is what actually came off the bill after the work was done. And the gap between the two is where most FinOps programs quietly fail.

Why the gap opens

Identified savings is potential energy. Turning it into realised savings means someone has to do something, and that is where it leaks away:

  • The recommendation is never actioned. It sits in a console tab nobody opens.
  • It is actioned, then reverted: a rightsizing that hurt performance, a deletion that broke something downstream.
  • The estimate was wrong. The recommendation assumed steady-state usage that does not match reality.
  • Savings on one line are swallowed by growth on another, so the total bill never visibly moves.
  • Nobody owned it, so it stalled in a half-finished state with no deadline and no follow-up.

Why the gap is expensive

The damage is not just the missed money, it is the credibility. A FinOps lead who reports a big identified-savings figure to the CFO, and then cannot show a matching drop in the bill, has a problem. The next time they ask for headcount, tooling budget, or engineering time to chase savings, the answer is "you said that last quarter."

Identified savings is a forecast. Realised savings is a result. Leadership only ever trusts the second one.

Closing the gap

Closing the gap is an operational discipline, not an analytical one. The tooling that found the saving is necessary but not sufficient. What actually moves the bill is a process that takes each opportunity from a list to a confirmed result:

  1. Give every opportunity a single owner, not a team, a person.
  2. Track it through a defined lifecycle, so a half-done change cannot silently disappear.
  3. Verify the saving against the real bill over an observation window after the change lands, rather than trusting the original estimate.
  4. Report realised savings to leadership, and keep identified separate. Never conflate the two.

Do that, and your reported number becomes one you can defend in any room, because it already happened.