Rightsizing or commitments first? Getting the optimisation sequence right

A cloud provider offers an attractive proposition: commit to a predictable level of usage and receive a lower rate. The potential saving can be substantial. So why not maximise commitments as quickly as possible?

Because there is a fundamental difference between two ways of reducing cloud cost: using less, and paying less for what you use.

Rightsizing, scheduling and removing unnecessary resources improve the efficiency of consumption. Commitments reduce the rate paid for eligible consumption in exchange for accepting some level of future usage obligation.

Both matter. But if you commit too early, you risk locking in today's inefficiency at tomorrow's discounted rate.

That is why optimisation sequence matters.

Rate optimisation and usage optimisation solve different problems

Consider a workload consuming $100,000 per month of eligible cloud resources. A commitment could reduce the effective cost by 20%. That looks like:

$100,000 → $80,000 — a $20,000 monthly benefit

Now imagine the environment is materially overprovisioned. After rightsizing, scheduling non-production resources and removing unnecessary capacity, the same workload could operate effectively on $75,000 of monthly consumption before any commitment discount.

Apply the same illustrative 20% rate reduction after that optimisation:

$75,000 → $60,000

The organisation has now improved both sides of the equation: consumption efficiency and rate efficiency.

The difference is significant. If the commitment had been sized against the original $100,000 consumption profile, the organisation might now be committed to usage it no longer needs.

The discount was real. The commitment decision was still poor.

A discount does not make inefficient usage efficient

This sounds obvious, but it is easy to lose sight of when commitment savings are visible and relatively straightforward to quantify.

Suppose a virtual machine is twice as large as the workload requires. Purchasing discounted capacity for that resource does not fix the underlying problem. It simply makes the oversized resource cheaper.

The same applies to idle compute, unnecessarily large databases, non-production environments running continuously, excessive storage, inefficient architectures and duplicated infrastructure.

Rate optimisation can reduce the financial impact of inefficiency. It does not remove the inefficiency itself.

That is why usage optimisation should generally be considered before making material commitments against the same consumption.

Start with the demand you actually need

Before committing spend, the organisation needs a credible view of its underlying demand. That means asking: what usage is genuinely required? Not: what did we happen to consume last month?

Historical consumption contains both productive demand and inefficiency. If you treat all historical consumption as future demand, you risk converting waste into a financial obligation.

A stronger approach is to understand the stable consumption that remains after obvious optimisation opportunities are considered. That might involve eliminating idle resources, rightsizing where technically appropriate, scheduling environments that do not need continuous operation, reviewing storage requirements, accounting for planned migrations or decommissioning, and understanding expected business growth or contraction.

Only then can the organisation form a more credible view of the usage it is comfortable committing to.

But "optimise everything first" is also too simplistic

There is an important caveat.

Cloud environments are never fully optimised. If an organisation waits until every resource is perfectly rightsized before making any commitment, it may spend months paying unnecessarily high on-demand rates for stable consumption. That is not good FinOps either.

Imagine an organisation has a large production estate with a highly predictable base level of usage. Some optimisation work remains. But a substantial portion of consumption is stable, well understood and unlikely to disappear.

There may be a strong economic case for committing part of that baseline while optimisation continues elsewhere.

The right principle is therefore not "never commit before optimisation is complete." It is "do not commit consumption you do not sufficiently understand." That is a much more useful rule.

Think in terms of confidence layers

One practical way to approach commitments is to separate consumption by confidence.

Imagine monthly eligible usage of $1 million. After reviewing the environment, the organisation might conclude:

$550,000 is highly stable base usageCore production workloads with strong historical consistency and no known major changes.

$250,000 is reasonably predictableUsage expected to continue, but with more variability or potential optimisation.

$200,000 is uncertainWorkloads facing migration, architectural change, demand uncertainty or significant optimisation.

Those three layers should not necessarily receive the same commitment treatment. The organisation may be comfortable committing strongly against the stable base. It may take a more conservative position on the second layer. And it may preserve flexibility around the uncertain portion.

This turns commitment management into a risk decision, rather than a race to maximise discount coverage.

Coverage and utilisation are not the same thing

Two metrics are particularly important in commitment management.

Coverage asks: how much eligible usage is receiving commitment-based pricing? Utilisation asks: how much of the commitment we purchased are we actually using?

High coverage can look attractive. But increasing coverage by purchasing excessive commitments can reduce utilisation.

For example, an organisation might achieve 95% commitment coverage but later discover that architectural changes or demand reductions leave a meaningful portion of those commitments unused.

Another organisation might deliberately maintain lower coverage because part of its usage is uncertain. Its on-demand rate may be higher on that portion, but it retains flexibility.

Neither metric should therefore be maximised in isolation. The objective is to find an economically appropriate balance between discount, utilisation, coverage and flexibility.

Architecture can change the commitment equation

Commitment decisions should not be made independently of the technology roadmap.

Suppose a company plans to migrate a major workload within nine months. Or move from virtual machines to containers. Or modernise a database platform. Or shift part of an estate between cloud services.

Current consumption may look highly predictable based on historical data. But the future architecture may be very different. A commitment based only on the previous twelve months could therefore be misleading.

This is why commitment planning needs input from Engineering and Technology leadership. Finance can understand the commercial obligation. FinOps can analyse usage and pricing. But Engineering may know that the underlying demand is about to change.

Historical stability is useful. Future relevance matters more.

Business growth does not automatically justify aggressive commitments

Expected growth can also create false confidence.

A business may forecast 30% growth and assume cloud consumption will increase accordingly. That does not necessarily mean the organisation should commit to 30% more infrastructure.

Cloud demand may not scale linearly with business activity. Engineering improvements may absorb some growth. Architecture may change. Customer mix may shift. The product roadmap may evolve.

Forecast growth should inform the commitment decision, but it should not replace evidence about how that growth actually translates into cloud consumption.

The stronger the commitment, the stronger the confidence should be.

Commitments have an opportunity cost

A commitment is not only about the discount obtained. It also reduces optionality.

Once the organisation has accepted a future consumption obligation, some future technology decisions may have different economics.

An engineering team might identify an architecture that reduces usage dramatically. That is technically attractive. But if the organisation is already committed to paying for much of the previous consumption, the near-term financial benefit may be reduced.

This does not mean commitments prevent optimisation. It means the commitment position becomes part of the optimisation context.

FinOps therefore needs visibility not only into resource usage, but also into the commercial structure sitting underneath it.

Sequence optimisation as a portfolio, not a checklist

There is no universal sequence that works for every resource. A practical approach is to think across the portfolio.

Obvious wasteRemove or address idle and unnecessary resources quickly.

Low-risk efficiencyRightsize or schedule workloads where the technical case is clear.

Stable base consumptionConsider commitment opportunities where future demand is sufficiently predictable.

Uncertain workloadsPreserve flexibility where migrations, architectural changes or demand uncertainty are material.

Complex architecture opportunitiesEvaluate them based on financial value, engineering effort and the existing commitment position.

This is more realistic than attempting to completely optimise an entire estate and only then thinking about rates. Usage optimisation and rate optimisation can happen in parallel. They simply need to be coordinated.

The cheapest rate is not always the lowest cost

This is the core economic point. Imagine two options.

Option AConsumption: $100,000. Discounted rate: 25%. Effective cost: $75,000.

Option BOptimised consumption: $75,000. Discounted rate: 15%. Effective cost: $63,750.

Option A achieved the better discount. Option B achieved the lower cost.

That distinction matters because FinOps can become overly focused on rate metrics: discount percentage, commitment coverage, effective savings rate.

Those metrics are useful. But the business ultimately cares about the economics of the workload. A high discount on unnecessary consumption is not a superior outcome.

The right sequence protects both savings and flexibility

The strongest commitment strategy is therefore not the one with the highest coverage. And the strongest optimisation strategy is not necessarily the one that refuses to commit until every workload has been perfected.

The objective is to understand: what consumption do we genuinely need? What can still be optimised? What demand is stable enough to commit? What is likely to change? How much flexibility is valuable to us? What risk are we accepting in exchange for the discount?

Those questions connect technical optimisation with financial decision-making. And that is exactly where FinOps should operate.

Key takeaway. Optimise the consumption you can. Commit the consumption you understand. Preserve flexibility where uncertainty remains.

Usage optimisation and rate optimisation are complementary, but they should not be treated independently. Committing too early can lock in unnecessary consumption. Waiting for perfect optimisation can leave valuable discounts unused.

The right approach is to coordinate both around the organisation's real demand, technology roadmap and confidence in future usage. The goal is not the largest discount. It is the best cloud economics.

Nooven helps organisations connect cloud optimisation with commitment strategy — reducing inefficient consumption, assessing demand confidence and balancing savings, utilisation and flexibility before longer-term financial decisions are made.