Cloud cost forecasting: methods, budgets and variance finance can use

Cloud cost forecasting is the practice of predicting what the cloud bill will be, at the level the organization budgets at, from its own usage history and the changes it knows are coming. A useful forecast is per department, product or cloud rather than one total; it shows a range rather than a single number; it separates committed spend from on-demand; and it sits next to the budget so the variance is visible before the invoice arrives. Most of the accuracy comes from allocation and from knowing what is planned, not from the model.

Why cloud forecasts miss

Flexera’s 2025 State of the Cloud report found organizations exceeding their public cloud budgets by 17% on average. The gap is rarely a modeling failure. It comes from four places: spend that nobody owned and therefore nobody forecast; growth that was planned by an engineering team and never reached finance; commitments bought or expiring without the forecast knowing; and a single organization-wide number that hid all three until the invoice.

Each of those is fixed upstream of the model. Allocation gives every dollar an owner who can be asked what is coming. A planning input turns known changes into the forecast before they happen. A commitment schedule makes the discount, and its expiry, part of the outlook. And forecasting at the level people budget at turns one wrong total into many small variances, each with someone who can explain it.

Forecast at the level you budget at

A forecast is useful in proportion to how closely it matches the thing someone is accountable for. Finance budgets by cost center and product. A business unit budgets its own P&L. Engineering budgets, if it budgets at all, by service and environment. A forecast that exists only as one total for the company can be compared to nothing anyone signs.

The practical consequence is that the forecast inherits the allocation. If the bill is allocated to cost centers, products and customers on one ledger, a forecast can be produced for each dimension from the same history, and each forecast can be compared to the budget that exists at that level. If the bill is not allocated, the only honest forecast is the total, and the only honest variance explanation is “somewhere in the cloud”.

Four forecasting methods, and when each works

In practice a forecast combines the first three for the run-rate and the fourth for known changes.
Method	How it works	Works when	Fails when
Run-rate	Takes recent daily or weekly spend and projects it forward.	Stable workloads; the next few weeks; a first forecast on day one.	Seasonality, migrations, launches, or anything that is not last month again.
Trend and seasonality	Fits growth and repeating patterns from months of history per consumer.	A year or more of allocated history; steady growth; predictable cycles such as month-end batch or retail seasons.	Young estates, structural changes, and any cost with less history than its cycle.
Driver-based	Models cost as a function of a business driver: transactions, customers, data volume, environments.	The driver is measured, the relationship is stable, and the business already forecasts the driver.	Costs that do not scale with the driver, such as fixed platform capacity or commitments.
Plan-based	Adds known future changes from the people who will cause them: a migration, a decommission, a new region, an expiring commitment.	Always, as an overlay; it is the only method that sees the future rather than the past.	Nobody asks, or the answers stay in a slide deck instead of the forecast.

The combination that holds up is a trend-and-seasonality run-rate per consumer, driver-based adjustments where a clean driver exists, and a plan-based overlay collected every month from budget owners. The overlay is where most of the accuracy lives, and it costs a conversation, not a data science team.

Committed and on-demand spend are two forecasts

Reserved capacity, savings plans and committed-use discounts are contracts with a known cost and a known end date. On-demand spend is whatever usage the commitments do not cover, priced at the list rate. Forecasting the two together as one line hides both the certainty of the first and the volatility of the second.

Kept separate, the committed line is a schedule: it is flat until a commitment expires or a new one starts, and the forecast can show the cliff when a large reservation ends. The on-demand line is where the growth and the risk are, and it is the one that responds to rightsizing, decommissioning and a launch. Coverage, the share of usage under commitment, becomes a forecast input in its own right rather than a surprise on the invoice.

Ranges, not points

A forecast of $412,300 for next month will be wrong. A forecast of $395,000 to $430,000, with the reasons the top and bottom differ, is a decision finance can plan around. The range comes from the uncertainty in the on-demand line, from the drivers, and from the plan-based overlay, where a migration may land this month or next.

A range also changes the conversation about variance. Landing inside the range is the forecast working. Landing outside it is a signal that something changed, and the allocated view says where. A single point makes every month a miss by some amount and teaches people to ignore the forecast.

Budget and variance on the same page

A forecast that lives in a different tool from the budget is compared once a quarter, by hand, after the fact. The view that gets used carries, per consumer and per period:

The budget for the period and the year to date.
Actual spend to date, allocated, with the committed and on-demand split.
The forecast for the rest of the period as a range, and the full-period outlook against budget.
The variance to budget in amount and percent, with the top contributing services and the planned changes that explain them.
The forecast made last period for this one, so the forecast’s own error is visible and improves.

A monthly forecasting cadence

Close the allocation. The forecast starts from allocated actuals; an unallocated remainder is forecast as its own line with an owner for shrinking it.
Refresh the run-rate per consumer from the allocated history, with the committed and on-demand split.
Collect the overlay. Ask each budget owner one question: what is changing in the next three months that the history cannot see? Record the answers as dated adjustments with an owner.
Update the commitment schedule: purchases, expiries, and coverage for the next quarter.
Publish the forecast as a range next to the budget, per consumer, and record it so next month’s error can be measured.
Review the largest variances with their owners, and feed what was learned back into the overlay for next month.

Measuring forecast quality

Error at the level of accountability: the absolute percentage error per consumer, not only for the total, because offsetting errors at the top hide real misses below.
Bias: whether the forecast runs consistently high or low. A persistent bias is a fixable input, usually a missing overlay.
Range hit rate: how often the actual landed inside the published range. Too often means the range is too wide to be useful; rarely means the uncertainty is understated.
Overlay coverage: the share of budget owners who supplied their planned changes this cycle.
Time to reforecast: how quickly a known change reaches the published forecast. Days, not the next quarter.

Common mistakes

One number for the whole company, compared to a budget that exists at a different level.
Forecasting the invoice total instead of allocated spend, so no variance has an owner.
Treating commitments as part of the run-rate, and being surprised by the expiry.
Skipping the overlay because “engineering never tells us”. Ask in the forecast review, with their statement in front of them.
Publishing a point instead of a range, and then arguing every month about a miss that was inside the noise.
Never scoring the forecast, so the same errors repeat.

How Runcost forecasts

Runcost forecasts from the same allocated ledger it reports from, so a forecast exists for every department, product, customer and cloud the statements exist for. Committed and on-demand spend are forecast separately with the commitment schedule in view, planned changes are recorded as dated adjustments with an owner, and the forecast is published as a range next to the budget with the variance and last period’s forecast error on the same page.

Questions

How do you forecast cloud costs?

Start from allocated actuals per department, product or cloud; project the run-rate with trend and seasonality per consumer; adjust by business drivers where a clean one exists; overlay the changes budget owners know are coming; keep committed and on-demand spend separate; and publish a range next to the budget every month, scoring last month’s forecast against what happened.

What is the most accurate way to forecast cloud spend?

Forecast at the level people are accountable for, from allocated history, and collect planned changes from those people every cycle. The plan-based overlay adds more accuracy than any change of statistical model, because it is the only input that sees the future rather than the past.

How far ahead should you forecast cloud costs?

A rolling twelve months for budgeting and commitment decisions, refreshed monthly, with the next quarter carried at consumer level as a range. Beyond a year, forecast the drivers and the commitment schedule rather than the bill; the estate will change too much for a spend forecast to mean anything.

What is forecast variance in cloud cost management?

The difference between what was forecast for a period and what was actually spent, per consumer, in amount and percent. Tracked alongside budget variance, it shows whether a miss came from the plan being wrong or the forecast being wrong, and a persistent variance in one direction points to a missing input.

Why do cloud budgets get exceeded?

Mostly because spend had no owner and therefore no forecast, growth planned by engineering never reached finance, commitments were bought or expired without the forecast knowing, and the budget existed at a level the forecast did not. Flexera’s 2025 survey put the average overshoot at 17%.

Sources

About the author

Faisal Saleem

Founder of Runcost, a multi-cloud cost management platform built so that finance can allocate, forecast and explain the cloud bill like any other financial document. Writes the guides here from the allocation and chargeback work behind the product.