N100FN100F
Published on

Budget and forecast

In the cloud, spend is decided every time somebody deploys. Budgeting means estimating before deploying, forecasting from the real trend, and finding out about the variance before the bill arrives.

Service line FinOps Engineering

The annual budget is not enough

In traditional infrastructure, spend was decided when equipment was bought, once or twice a year. In the cloud it is decided every time somebody deploys or scales something. A budget set in January and reviewed in December arrives too late for almost every decision.

That is why, in FinOps, budgeting is not an annual figure: it is a short cycle that connects what is about to be deployed with what is being spent.

The cycle in four steps

Mid-month forecastActual accumulated spend to day 14, forecast with a band to day 30 and the budget: the alert arrives with 16 days to spare.FINOPS · BUDGETFinding out mid-month0k15k30k45k60kday 1day 8day 15day 22day 30Budget 48kAlert (day 14)58k forecastActual accumulated spendForecastBudgetThe forecast closes at 121% of budget.16 days left to act, not a bill to explain.Illustrative data; they do not correspond to any real caseN100F · n100f.com

  1. Estimate before deploying. Every relevant infrastructure change carries a cost estimate, just as it carries a technical review. With infrastructure as code, the estimate can be calculated automatically on the change itself.
  2. Set the budget. Per application or product, not just for the whole organisation, and expressed in unit metric terms too where possible: 'up to this much per customer' holds up better than a fixed figure if the business grows.
  3. Forecast from the trend. Project the close of the month or quarter from actual accumulated spend and its pace, not from the original budget. The forecast is updated with every new data point.
  4. Alert on variance. Raise the alert when the forecast exceeds the budget, not once it has already been exceeded. Arriving mid-month with an alert lets you correct course; arriving with the bill only lets you explain.

Forecasting: simple and explainable

A forecast does not need to be sophisticated to be useful. It needs four things:

  • Allocated, corrected data. The forecast starts from cost that is already clean and attributed, not from the raw total.
  • The stable separated from the variable. Commitments and fixed base on one side, variable consumption on the other.
  • What is already known. A planned launch, a migration or the end of a commitment goes into the forecast before it happens.
  • A one-sentence explanation. If nobody understands why the forecast says what it says, nobody will act on it.

The useful alert

A good alert has a recipient, context and an action: it reaches the owner of the application, says how much it is off by and why, and suggests where to look. A generic alert to a shared mailbox is ignored by the third time.

With estimation, budget and forecast running, the next question is what to move when cost has to come down. That is optimising.

How we apply it: FinOps Engineering.

If your cloud cost keeps growing and nobody knows why, or your architecture depends on whoever built it, let’s talk.

Let’s talk