The optimisation loop is the repeating sequence that turns a finding into a proven saving: identify, estimate, decide, implement, verify, and feed the result back into the next round of identifying. It is not a project with an end date, because every new resource, every price change and every expired commitment produces new findings and invalidates old estimates. Each round works a few actions off the open list of savings opportunities, and none ends before the invoice shows what the change did.
How it works
The FinOps Foundation's Framework describes three phases a practice passes through again and again: Inform, Optimize and Operate. The loop on this page covers Optimize, the part of Operate that implements the chosen actions, and the return to Inform, where the Foundation places validating their impact; the phases themselves are covered in Inform, Optimize, Operate.
| Step | Question | Output | Who |
|---|---|---|---|
| Identify | Where do we pay for units doing no work, or at too high a rate? | an entry on the list of savings opportunities | provider tools, cost report, engineering |
| Estimate | How much per month, on which price basis, at what risk? | an amount with its basis and assumptions | whoever records the finding |
| Decide | Do we do it, when, and who does it? | accepted, deferred or rejected | the resource's owner; for commitments, the approver |
| Implement | Is the change live? | a date and evidence such as a ticket, commit or purchase | engineering or purchasing |
| Verify | Does the invoice show the effect? | a realised saving, or "inconclusive" | whoever runs the cost report |
The verification result feeds back: an action that delivered less than estimated corrects the next estimate of the same kind, and a change that created new cost elsewhere becomes a finding itself.
Usage levers and rate levers
The Foundation assigns this work to two capabilities in the Optimize Usage & Cost domain: Usage Optimization, called Workload Optimization before the 2026 Framework, for consumption, and Rate Optimization for the rate. Usage levers change what is consumed and how much: rightsizing, removing idle and orphaned resources, schedules, storage classes and less data transfer. Rate levers lower the price for the same consumption: commitments such as Savings Plans, reservations and committed use discounts, spot capacity and negotiated prices. The order matters because a commitment locks in the usage it covers: usage first, rate second. How that steers a whole portfolio is covered in commitment strategy.
AWS
Cost Optimization Hub collects recommendations across an organisation's accounts and Regions: rightsizing and idle resource deletion, which AWS Compute Optimizer supplies, plus Savings Plans and Reserved Instances. The hub removes overlaps. For an instance that can either be deleted or rightsized it counts only the larger saving, and it reduces a Savings Plans recommendation in proportion to the cost of idle instances that would be stopped. The estimated saving refers to 730 hours and, depending on a preference, is calculated after the account's discounts or at public On-Demand prices. It can be aggregated by account, Region, resource type, implementation effort, whether a restart is needed and whether the change can be rolled back, among others.
Azure
Azure Advisor lists cost recommendations, for virtual machines and scale sets such as shutdown and resize. Advisor calculates the saving at retail rates, without the account's temporary or long-term discounts and without existing reservations or savings plans. Microsoft notes that following a recommendation to move to another series can even raise cost when reservations were bought for the old one. Each recommendation carries an impact from High to Low and, with state management, currently in preview, can be postponed, dismissed or marked as completed.
Google Cloud
The Recommender produces recommendations and insights; Active Assist is Google's name for the portfolio of these tools. Google calculates the saving with the billing account's contract prices where a custom pricing contract exists and the user may view costs, and at list prices otherwise; credits and other discounts are left out. FinOps hub brings the recommendations together, counts only the larger saving where they overlap, and does not take committed use discounts already purchased into account. Each recommender sets its priority from P1 to P4 by its own logic.
What the tools do not know
All three work from past usage. They know nothing of next month's launch, the machine kept for disaster recovery, the test environment that deliberately stays the same size, or the rule that every instance in a group stays identical; Microsoft names exactly such cases as reasons to dismiss a recommendation. Nor do they know the owner. A recommendation is therefore a finding, not a decision.
What it means for your cost
One round of the loop delivers a few implemented actions, not a long list. Ranking uses four inputs: estimated saving per month, effort, risk, and whether there is an owner. The Foundation's Usage Optimization describes the same weighing of expected benefit against effort, risk and disruption under one consistent ranking.
| Saving | Effort and risk | Owner | Decision |
|---|---|---|---|
| high | low, reversible | known | implement this round |
| high | high, or no way back | known | schedule with a date, a test and a rollback |
| low | low | known | collect and implement together, for instance as a rule |
| low | high | known | reject and record the reason |
| any | any | unknown | allocate first, then decide |
Before amounts are compared, every estimate stands on the same basis: an Advisor estimate at retail rates and a hub estimate after discounts are not the same number. Accepted actions belong in the forecast from their planned implementation date; only what the invoice proves is reported as a saving. How an action travels that path, and where verification can fail, is covered in savings estimated, accepted, implemented and verified. What the rate levers deliver together is measured by the effective savings rate. The cadence comes from the monthly cloud cost review.
Where it goes wrong
- Estimates added up. Symptom: the sum of savings opportunities exceeds what the resources concerned cost in the first place. Cause: deleting and downsizing the same instance, or rightsizing and a Savings Plan on the same usage, were both counted; Cost Optimization Hub and FinOps hub remove such overlaps from their totals.
- Rate before usage. Symptom: after rightsizing, a commitment's utilisation drops and the invoice barely moves. Cause: the commitment was bought on the old usage, so the rate lever came before the usage lever.
- A retail estimate as the target. Symptom: the saving on the invoice stays well below the recommendation. Cause: Advisor calculates at retail rates without discounts and reservations; the invoice uses the prices actually paid.
- A recommendation without an owner. Symptom: the same findings sit on the list month after month. Cause: nobody with change rights accepted them, and the loop stalls at identify.
- The tool says completed. Symptom: the recommendation is closed, the cost line unchanged. Cause: Advisor also marks a recommendation completed when it no longer applies; completed does not mean the invoice falls.
- One round instead of a loop. Symptom: a year after the clean-up project, cost is back at its old level. Cause: after implementation nobody verified or identified again, and new resources repeated the old patterns.
Sources
Read on 2026-10-16. FinOps Foundation phases, the 2026 FinOps Framework, Usage Optimization and Rate Optimization (CC BY 4.0); AWS Cost Optimization Hub, estimating monthly savings, Cost Optimization Hub preferences, viewing your savings opportunities and understanding your cost efficiency metric; Microsoft VM and scale set cost recommendations and manage recommendation state; Google Cloud what is Active Assist, how cost savings are calculated in recommendations, Recommender key concepts and optimize costs with FinOps hub.