Why cloud forecasting is difficult — and how to make it useful

Finance asks for next quarter's cloud forecast. The current run rate is $1.5 million per month, so the simplest answer would be to extend that trend forward.

But Technology knows several things are about to change. A new product is launching. A migration will move workloads into the cloud. Engineering expects to complete a major optimisation. Customer volumes are forecast to grow. And a new commitment may reduce effective rates.

Suddenly, last month's spend is no longer a particularly good predictor of next month's bill.

This is the challenge of cloud forecasting.

Traditional financial planning often starts with relatively stable cost structures and known commitments. Cloud consumption is different. It responds continuously to business demand, engineering decisions, architecture, pricing and optimisation.

That does not make cloud impossible to forecast. It means a useful forecast needs to explain more than a number.

A run rate is not a forecast

Suppose cloud spend for the last three months was: May $1.42m, June $1.47m, July $1.51m.

A simple trend might suggest August will land somewhere around $1.55m. That can be a useful starting point. But it assumes the future will behave broadly like the recent past.

Now imagine the organisation knows that in August a new customer platform will launch, a legacy data environment will be decommissioned, traffic is expected to increase 15%, a Savings Plan will become effective, and several development environments will begin automated scheduling.

The historical trend contains none of that information. A forecast based only on extrapolation may therefore be mathematically reasonable and operationally wrong.

Historical spend tells you where you have been. A forecast needs a view of what is about to change.

Cloud cost has multiple drivers

One reason cloud forecasting is difficult is that there is rarely a single cost driver. Spend can move because of changes in:

Business demandMore customers, transactions, orders or data can increase consumption.

Engineering activityNew services, environments and features can introduce additional resources.

ArchitectureMigrations, modernisation or changes in resilience can materially alter the cost profile.

OptimisationRightsizing, scheduling and resource elimination can reduce expected consumption.

Commercial structureCommitments, discounts and pricing changes can alter the rate paid for the same usage.

TimingProjects can launch later than expected. Migrations can slip. Optimisation can take longer to implement.

A useful forecast therefore needs to distinguish between these drivers rather than treating cloud cost as one homogeneous line item.

Start with the baseline, then model known changes

A practical forecast can begin with current consumption. Call this the baseline. The organisation can then layer material expected changes onto it. For example:

• Current monthly baseline: $1.50m

• Expected business growth: +$90k

• New product launch: +$120k

• Planned migration: +$160k

• Optimisation expected to take effect: −$70k

• New commitment benefit: −$40k

This creates an indicative monthly forecast of:

$1.76m

The point is not that every cloud forecast should be built with exactly this formula. The important shift is from "we expect spend to be $1.76m" to "we expect spend to be approximately $1.76m, and these are the changes driving that expectation."

That makes the forecast explainable. It also makes it easier to update. If the migration moves by two months, Finance does not need to wonder why the forecast changed. The assumption changed.

Separate baseline consumption from planned change

This distinction can significantly improve forecasting conversations.

Baseline consumption represents the expected cost of continuing broadly as the organisation operates today. Planned change represents known events expected to alter that baseline — migrations, product launches, customer growth, decommissioning, major architecture changes, optimisation initiatives or commitment purchases.

This creates a bridge between Finance and Technology. Finance can see the expected financial impact. Technology can see the operational assumptions behind it. And when actual spend differs from forecast, the organisation has somewhere useful to investigate.

Forecast at the level where decisions are made

Forecasting every cloud resource individually may create enormous effort without improving decision quality. Forecasting only the total cloud bill may be too high-level to explain anything.

The right level sits somewhere between the two. For one organisation, that may be business unit. For another: product, application, platform, cloud account or subscription, or major service category.

The objective is to forecast at a level where meaningful ownership and cost drivers exist.

If a platform team owns a large shared data environment, forecasting that platform may be useful. If thousands of short-lived resources appear and disappear underneath it, forecasting each one probably is not.

Granularity should serve the decision, not become the objective.

Business forecasts and cloud forecasts need to connect

One of the strongest improvements an organisation can make is connecting cloud forecasts with relevant business expectations.

Suppose a digital platform expects transaction volume to increase 30%. That should inform the cloud forecast. But it does not necessarily mean cloud cost should also increase 30%.

Some infrastructure may be fixed. Some services may scale with demand. Engineering may improve efficiency. Pricing may change with commitments.

The relationship between business activity and cloud consumption needs to be understood. This is where FinOps can help answer a more useful question: if the business grows as expected, what should happen to our cloud cost?

That is much stronger than simply assuming historical cloud growth continues.

Do not treat optimisation as guaranteed savings

Forecasting becomes particularly dangerous when potential optimisation is automatically deducted from future spend.

Imagine an organisation has identified $2 million of annual savings opportunities. Finance may be tempted to reduce next year's cloud budget by $2 million.

But some opportunities may still require technical validation. Others may need engineering capacity. Some may be rejected. Some may take months to implement.

The forecast should therefore reflect the confidence and expected timing of optimisation outcomes. An action already implemented is very different from an opportunity that has only been identified.

Likewise, an optimisation expected in March should not reduce the January forecast.

This sounds simple, but it is a common source of unrealistic cloud budgets.

Commitments need to be forecast too

Commitments add another layer.

A new commitment can reduce the effective rate paid for eligible usage. But the forecast also needs to consider whether the committed usage will actually be consumed.

If demand falls or architecture changes, part of the commitment may become underutilised. So the forecast should not simply assume commitment equals discount. It should consider expected consumption, commitment coverage, expected utilisation, timing and known workload changes.

Cloud forecasting is therefore both a usage forecast and, increasingly, a rate forecast.

Variance is not just a Finance problem

Once actual spend arrives, the useful question is not simply whether the forecast was wrong. It is: why was it wrong?

Suppose forecast spend was $1.8m and actual spend was $1.95m. The $150k variance could come from very different causes: customer demand exceeded expectations, a migration happened earlier, an optimisation was delayed, a new workload was not included, a commitment delivered less benefit than expected, or an anomaly occurred.

Each explanation requires a different response.

This is why forecast variance should become a learning mechanism. Over time, the organisation begins to understand which assumptions are reliable, which cost drivers are difficult to predict, where teams consistently underestimate demand, and which planned savings tend to slip.

A good forecasting process should become more useful because of its previous errors.

Accuracy should not be the only measure of forecast quality

A forecast that lands within 1% of actual spend sounds excellent. But accuracy alone can be misleading.

Perhaps the organisation simply has stable consumption. Or perhaps several incorrect assumptions happened to offset each other.

A more useful assessment also considers:

ExplainabilityCan we explain the forecast and the variance?

TimelinessIs it updated when material assumptions change?

OwnershipDo the teams closest to the cost contribute to relevant assumptions?

Decision usefulnessDoes the forecast help Finance and Technology make better decisions?

ConfidenceDo stakeholders understand where uncertainty exists?

The purpose of forecasting is not to win an accuracy competition. It is to reduce financial surprise and improve planning.

A range can be more useful than false precision

Cloud forecasts are often presented as a single number. Q4 forecast: $5,438,217.

That level of precision can imply confidence that does not exist.

For volatile environments, scenarios or ranges may be more useful. For example:

• Expected case: $5.4m

• Lower-demand case: $5.1m

• Higher-demand case: $5.8m

The scenarios might reflect uncertainty around a migration, customer growth or product adoption. This allows Finance to understand the financial exposure rather than receiving one number that will inevitably move.

Not every organisation needs formal scenario modelling. But where uncertainty is material, being explicit about it is better than hiding it behind precision.

Forecasting should be a rolling conversation

Cloud forecasting works poorly as a once-a-year budgeting exercise. The environment changes too quickly.

A forecast should evolve as new information becomes available. A product launch moves. A migration completes. Demand exceeds expectations. An optimisation goes live. A commitment is purchased.

The forecast changes because the underlying reality changed. That is not a failure of forecasting. It is the purpose of a rolling forecast.

The important thing is that changes are visible, explainable and incorporated early enough to support decisions.

Finance should not forecast cloud alone

Finance has the financial view. But many of the strongest signals about future cloud cost sit elsewhere.

Engineering knows about architecture changes. Product understands launches and expected adoption. Business teams understand demand. Procurement may know about commercial changes. FinOps can connect those signals with cost and usage data.

This makes cloud forecasting a cross-functional capability. Finance should own the financial planning process. But it should not be expected to predict technical consumption without input from the teams creating it.

A useful forecast tells a story

At executive level, a cloud forecast should ultimately be able to explain: where are we now? Where do we expect spend to go? What is driving the change? Which assumptions matter most? Where is uncertainty? What changed since the previous forecast? What decisions might change the outcome?

That is much more valuable than a single projected number.

Because when the forecast changes — and it will — the organisation understands why.

Key takeaway. Cloud forecasting is not difficult because cloud is impossible to predict. It is difficult because cloud cost responds to many changing business, technical and commercial drivers.

Start with a credible baseline. Layer in material known changes. Connect demand with consumption. Reflect the timing and confidence of optimisation. Include commitment economics. Track variance back to its drivers. And update the forecast when assumptions change.

The goal is not perfect prediction. It is fewer financial surprises and better decisions.

Nooven helps organisations connect cloud cost, technology plans and business demand to build more explainable forecasts — giving Finance and Technology a clearer view of expected spend, uncertainty and the decisions that can change the outcome.