An annual cloud budget is the approved amount per scope for a fiscal year, phased into months; it is the source of the budgets set in the providers' tools and of the monthly comparison with actuals. It is built not from last year's total plus an uplift but from the current run rate, the drivers and the changes already known. Recording those assumptions alongside the amount is what later lets every variance be traced to one of them.
How it works
Eight building blocks, in this order, because each rests on the one before:
- Baseline from the run rate. The cost of the last closed months as a daily rate, on the cost basis the budget will later be measured on, cleaned of one-off items such as upfront payments and credits. Which basis produces which figure is set out in list, billed, effective and amortized cost; how run rate, averages and trend differ, in cloud cost forecasting methods.
- Drivers and planned changes. Per scope, the expected development of the cost driver times the unit cost, plus launches, migrations and shutdowns with their month.
- Commitments and their end dates. Every commitment with its end date and the decision whether to renew it. When it expires, the same usage pays the on-demand rate from then on; how each provider handles expiry and renewal is covered in exchange, cancellation and expiry of commitments. On billed cost, an upfront payment appears in the month it is paid.
- Announced price changes. What a provider has announced goes into the budget with its date; everything else is an assumption and is recorded as one. How much notice AWS and Google give before changing prices is covered in cloud procurement: routes, contracts and renewals, price protection under an Azure Enterprise Agreement in enterprise agreements and private pricing.
- Currency. A budget planned in euros or pounds for prices in dollars needs a fixed budget exchange rate, approved together with the amount.
- Monthly phasing. Monthly amount = daily rate × days in the month + dated changes in that month, plus seasonal patterns where the history shows them and upfront payments in the month they fall due.
- Scopes and owners. Every budget line has a scope the providers' tools can represent and a cost owner. The lines, together with shared and unallocated cost, add up to the total budget.
- Approval and reforecast. Approval fixes the amount, the assumptions and the rate. The forecast is then recalculated as data arrives, while the budget stands until it is explicitly approved again. In its Budgeting capability, the FinOps Foundation treats the budget cycle as a choice that shifts with maturity, from an annual cycle towards shorter, rolling ones.
Fiscal year and calendar months
Invoices mostly cover a calendar month, but the billing period of an Azure subscription on pay-as-you-go, MSDN or Visual Studio terms need not start on the first (billing periods, cut-off and late charges). A fiscal year that does not start in January meets different rules in the budget tools.
| AWS Budgets | Azure | Google Cloud | |
|---|---|---|---|
| Annual budget | annually, every 12 months from the chosen start, times in UTC | annually; per the documentation the amount is divided evenly among the 12 months of the calendar year | yearly from 1 January, starting at midnight US Pacific Time |
| Different amounts per period | planned budget, monthly or quarterly only, for up to 12 months or 4 quarters, then the last amount applies | no; each period resets to the same amount, different amounts need separate budgets | no; a fixed amount or the previous period's spend |
| Own period | custom period, such as a fiscal year, ending at most three years after the start, with no automatic renewal | start always on the first of a month | custom range, non-recurring, with no forecast thresholds |
On AWS, forecasting for a custom period begins only once its end is within 12 months. How budgets are then set per scope in the tools is covered in cloud budgets.
What it means for your cost
An annual budget changes no invoice. It sets what counts as a variance during the year, and so what each monthly review talks about. The monthly phasing decides whether those conversations are worth having: an amount divided by twelve reports a favourable variance in February and an unfavourable one in March at unchanged usage, and in the month of an upfront payment an overrun that was decided long ago. The providers' tools hold the phasing only in part: AWS through a planned budget, Azure and Google through one budget per amount or a monthly budget whose amount is updated at the turn of each month.
The assumptions are the real value of the exercise. A budget line with driver, unit cost, commitment end date, price assumption and rate can be split in variance analysis into volume, price, scope and exchange rate; a line that names only an amount cannot. The reforecast changes the forecast, not the budget: the gap between the two is the information finance and the owners need. The comparison happens every month in the monthly cloud cost review; a dated walkthrough with queries and a template for the coming year is cloud budget planning for 2027.
The cost basis stays the same all year, and actuals are measured on it. Which basis suits teams and which suits finance is covered in cloud budgets.
Where it goes wrong
- Divided by twelve. Symptom: at the same usage February is favourable and March unfavourable. Cause: the annual amount was spread over the months without regard to days per month.
- A commitment's end forgotten. Symptom: from one month on, the cost of an unchanged workload is above plan. Cause: the budget assumes the discount for the whole year, and the commitment ends earlier.
- Phasing expected in an Azure annual budget. Symptom: the Azure budget's monthly values depart from the phased plan. Cause: Azure spreads an annual amount evenly across the calendar months; different monthly amounts need separate budgets.
- A fiscal year set as a Google yearly budget. Symptom: the cost counted drops to zero in the middle of the fiscal year. Cause: Google's yearly period starts on 1 January; a fiscal year needs a custom range, which has no forecast thresholds.
- A planned AWS budget beyond twelve months. Symptom: from the thirteenth month the budget holds the same amount. Cause: a planned budget reaches up to 12 months or 4 quarters, after which the last amount stays.
- The budget replaced by the forecast. Symptom: there is never a variance. Cause: the reforecast overwrote the approved amount instead of standing beside it.
Sources
Read on 2026-10-16. AWS Creating a cost budget, Budget methods and Best practices for AWS Budgets; Microsoft Create and manage budgets and Budgets: Create Or Update in the REST API; Google Cloud Create, edit, or delete budgets and budget alerts; FinOps Foundation Budgeting (CC BY 4.0).