A cloud cost forecast is an estimate of the cost at the end of a period, with a range, recomputed as each new day of data arrives; it is not a commitment. It decides whether a budget holds at month end, whether a commitment gets bought, and which figure finance accrues at the close. Which method produces the forecast, and what it is fed, determines how far it can be trusted.

How it works

Every method answers the same question from different inputs: what will this scope cost at the end of the period? The FinOps Foundation orders the methods by maturity in its FinOps Framework: manual models from history first, then rolling and trend-based models, and finally their combination with driver-based models on amortized data.

Run-rate extrapolation of the month to date. The cost so far, divided by the days elapsed, times the days in the month. It needs only the current month and is, for a new account, the only method without history. It fails as soon as the month is uneven: an upfront payment on the first, a batch run at month end, a weekend at the start.

Trailing average. The mean of the last three, six or twelve months as the expectation for the next. It smooths outliers and needs several closed months. It fails in growth and in wind-down, because it follows every change with a lag, and it carries an old outlier as long as the window reaches.

Trend with seasonality. A model over daily values that separates direction from recurring patterns: less usage at weekends, more at month end, more in the fourth quarter. It needs enough history for each pattern to recur, and it is what the provider consoles use. It fails at a structural break: after a migration, a price change or a commitment purchase, the history is no longer the future.

Driver-based. Planned usage times a unit cost: expected customers, requests or data volume, multiplied by the unit economics of recent months. It needs a plan for the driver and a stable relationship between driver and cost. It fails when the unit cost itself moves, say because a commitment expires or the architecture changes, and it is only as good as the plan that supplies the driver.

Bottom-up per team. Each team estimates its cost from its roadmap, and the sum is the forecast. It knows about plans that appear in no history. It fails when teams forget their shared cost, build in padding, or never compare the estimate with the outcome.

No method knows what is not yet in the data: a commitment bought next month, a workload going into production, a provider's price change, a currency move when the invoice arrives in a different currency from the budget. They are added to the forecast, not read out of it.

That is why a forecast is a range. A single number promises a precision the inputs do not have; the range says how wide the uncertainty is. A budget is held against the upper end, not the middle.

AWS

Cost Explorer forecasts from past usage with an 80 percent prediction interval, drawn as a band around the forecast on line and bar charts; the more volatile the history, the wider the band. When the history is not enough for that interval, Cost Explorer shows no forecast, which the documentation calls common for accounts with less than one full billing cycle. Discounts are included by default. AWS states the forecast reaches up to 18 months at monthly and 3 months at daily granularity. Forecast alerts in AWS Budgets need about five weeks of usage data.

Azure

Cost Analysis describes its model as a time series linear regression that projects up to a year ahead. A reservation purchase lifts the forecast temporarily and, per the documentation, it settles within a few days; filtering such spikes out is recommended. The lookback window depends on the horizon: 28 days for forecasts up to 28 days, the same as the horizon beyond that, and at most 90 days. For an annual forecast at least 90 days of history are recommended.

Google Cloud

The billing reports show a forecast up to twelve months ahead, as an approximation from the historical trend that, per the documentation, recognises daily, weekly and monthly cycles and draws on all the history that matches the filters, not only the selected range. It appears only for a range by usage date that ends in the future, not for a range by invoice month, and not with certain filters, such as product or spend-based committed use discounts. The documentation names no minimum history.

What it means for your cost

The monthly question is forecast against budget: not where the cost stands today, but where it will land and whether that is within the amount.

The cost basis decides what the forecast is good for. For teams it belongs on effective cost, because commitments are spread there over the usage they cover and the curve shows the team's behaviour. For the invoice it belongs on billed cost, because finance needs the amount that falls due, upfront payment included in the month it is paid. The same usage yields two forecasts, and both are right for their question.

A forecast per scope sums badly to a total when scopes move: a workload changes account, a tag is renamed, a team is split. The history per scope breaks; the total's does not. The gap between the total forecast and the sum of the partial forecasts points to moved allocation, not to extra cost.

Where it goes wrong

  • Simple scaling of a partial month. The first five days' cost times six. If the start holds an upfront payment or a weekend, the forecast is off by exactly the factor the rest of the month does not have.
  • Forecasting over a commitment purchase. An upfront payment in the history is carried forward as usage; Azure describes this effect explicitly. The forecast reports an overrun that never comes.
  • Trusting a forecast on three days of data. A new account, a new project, three data points. Cost Explorer shows no forecast in that position; a spreadsheet will.
  • One forecast for all scopes. The total looks stable while one team grows by half and another winds down. The forecast per owner shows both; the total shows neither.
  • A forecast nobody compares with the outcome. Without a comparison of forecast and actual at period end, the method stays as it is, however often it misses. The FinOps Framework carries this comparison as a metric of its own, the forecast accuracy rate.

Sources

Read on 2026-10-15. AWS: Forecasting with Cost Explorer, time ranges in Cost Explorer, Best practices for AWS Budgets; Microsoft: Start using Cost Analysis; Google Cloud: View forecasted costs; FinOps Foundation: Forecasting, FinOps Framework (CC BY 4.0); FOCUS: Effective Cost.