Realised savings are the reduction that actually shows in cost after a change was implemented, as opposed to the reduction estimated beforehand. Between the two lie four states: estimated, accepted, implemented and verified. Keep them apart and you can say at any time how much was promised, how much was done and how much is proven. Mix them and you report estimates as results, and later have to explain why the invoice does not follow.
How it works
| State | What moves an item there | What is recorded |
|---|---|---|
| Estimated | a finding with an amount, a price basis and a period | source, resources or scope, amount per month, price basis, assumptions |
| Accepted | the resource's owner commits | owner, date, expected effect, planned date, and for commitments the approver |
| Implemented | the change is live | date, evidence, resource IDs affected |
| Verified | a comparison on a fixed scope shows the effect | measured effect, comparison periods, method, or "inconclusive" |
Rejected is an exit with a reason, not a fifth step. How the states fit into the wider cycle is covered in the cloud cost optimisation loop.
How the tools estimate
AWS Cost Optimization Hub scales a recommendation's effect to 730 hours, the average month, and leaves out periods when the resource was not running. Depending on a preference, the amount is after all of the account's discounts, Reserved Instances and Savings Plans included, or at public On-Demand prices. AWS itself calls the figure a quick approximation: what is actually saved depends on future usage.
Azure Advisor calculates at retail rates, without the account's discounts and without existing reservations or savings plans, and Microsoft points out that the savings shown may therefore be higher than actually possible.
Google uses contract prices where a custom pricing contract exists and the user may view costs, and list prices otherwise, in both cases without credits or other discounts. FinOps hub does not take committed use discounts already purchased into account. For commitment recommendations the saving rests on actual usage, while the purchase summary uses list prices and assumes full utilisation.
What the providers' states mean
The Google Recommender knows ACTIVE, CLAIMED for a change in progress, SUCCEEDED for applied, FAILED and DISMISSED; you or another process set the state. Azure Advisor's state management, currently in preview, knows Active, Postponed, Dismissed and Completed. Completed means the action was applied or the recommendation no longer applies; Advisor checks this itself every 24 hours and then makes the state final.
Both states describe the resource, not the invoice. SUCCEEDED and a system-verified Completed correspond to implemented here, not verified. Both also expire: Google keeps CLAIMED, SUCCEEDED and FAILED for 90 days after the state change, and Advisor shows system-verified completed recommendations for six months. A year-end report therefore needs its own register.
Verification
The FinOps Foundation's Usage Optimization capability counts the regular comparison of actual impact with the original estimate among the marks of a more mature practice. Verification follows a fixed order:
- Fix the scope. The same resource IDs, accounts or tags before and after the change; a replaced resource with a new ID is mapped explicitly.
- Choose the baseline. A period before implementation, as long as the comparison period after it, excluding the implementation day.
- Fix the cost measure. Effective cost in both periods, because it spreads commitments over the usage; which measure answers which question is in list, billed, effective and amortized cost.
- Split the difference. Into a usage and a rate effect, as in the variance walk of the monthly cloud cost review; a rightsizing action explains only its part.
- Take out growth. Cost per unit of a driver, such as per request or per customer, as in unit economics and unit costs.
- Check confounders. Price changes, commitments bought, expired or moved, credits and exchange rates within the comparison period.
- Record the result. An amount per month with its method, or "inconclusive" with the reason.
What it means for your cost
Four totals are reported side by side, not one: estimated, accepted, implemented, verified. Only the last goes into the report to management and finance as a saving; accepted actions belong in the forecast from their planned date.
Realised savings and the difference on the invoice diverge for several reasons. A month has between 672 and 744 hours, while the AWS estimate uses 730. A change made mid-month acts for only part of the month. Where a commitment covered the resource, the freed discount moves to other usage or stays unused, so the saving looks smaller at account level than on the resource, as rightsizing explains. And growth elsewhere can push the invoice up although every action worked. Even the term is not uniform: Google's FinOps hub shows last month's "realized savings", explicitly excludes turning off idle resources, and can show a negative total when CUDs are underused.
"Inconclusive" is a valid result: when scope, baseline or confounders do not allow a clean comparison, a forced number is worse than none.
Where it goes wrong
- An estimate reported as a result. Symptom: reported savings clearly exceed what the invoice shows. Cause: estimated and accepted amounts were reported as savings, often on a retail basis.
- The scope moved. Symptom: verification finds no cost left for the resource. Cause: the resource was replaced and has a new ID, so the comparison runs into nothing.
- Growth hides the effect. Symptom: after rightsizing, the service's cost rises. Cause: more instances run, each costing less; a before-and-after comparison without normalisation shows the growth, not the action.
- A price change credited. Symptom: an action shows more effect than estimated. Cause: in the same period a price fell or a new commitment took effect, and the rate effect was credited to the action.
- A provider state taken as proof. Symptom: every recommendation is completed, cost is unchanged. Cause: SUCCEEDED or Completed say the resource changed or the recommendation no longer applies, not that the invoice falls.
- History lost. Symptom: the annual report can no longer find the first quarter's actions. Cause: the Recommender and Advisor keep closed recommendations only for a limited time.
Example
A service runs on N0 instances at hourly price P0. The action moves it to a smaller size at price P1. In the comparison period of h hours, higher load means N1 instances run.
| Quantity | Formula |
|---|---|
| Cost before | N0 × P0 × h |
| Cost after | N1 × P1 × h |
| Naive comparison | N0 × P0 × h − N1 × P1 × h |
| Cost without the action at the same load | N1 × P0 × h |
| Effect of the action | N1 × (P0 − P1) × h |
If N1 exceeds N0 × P0 / P1, the naive comparison turns negative although the action saves N1 × (P0 − P1) every hour. The last row is what is verified, provided the instance count follows the load rather than the size, P0 and P1 come from the same price basis, and no commitment covered the instances in either period.
Sources
Read on 2026-10-16. FinOps Foundation Usage Optimization (CC BY 4.0); AWS estimating monthly savings and Cost Optimization Hub preferences; Microsoft VM and scale set cost recommendations and manage recommendation state; Google Cloud Recommender key concepts, how cost savings are calculated in recommendations, recommendations for committed use discounts and optimize costs with FinOps hub.