How to forecast your 2027 Azure budget, line by line

Build the 2027 Azure budget from five lines you can defend: a clean baseline run rate in amortized cost, the changes you already know about, your commitment purchases and expiries, growth tied to a business driver, and a buffer sized from past forecast error. Add them month by month. The portal forecast is a cross-check, not the budget. Present the total with its assumptions on one page.

Why "this year plus 15%" does not hold up

The cloud budget we see most often in mid-market companies is last September's bill times twelve, plus a growth percentage someone found reasonable. It produces a number. It does not produce a number anyone can explain in March when spend is 18% over and the CFO asks which part was wrong.

The problem is that a single run rate mixes things that behave differently. A migration that double-runs two environments until December. A reservation bought upfront in May that shows up as one huge month. A new region that starts in April. Fixed platform cost that will not grow with customers, next to variable cost that will. Pull them apart and each one becomes a small, checkable estimate.

What does the Azure Cost Management forecast actually do?

Cost analysis shows a forecast on area and stacked column charts. Per Microsoft Learn, as of October 2026:

• It uses a time series linear regression on your historical usage.

• It projects up to a year ahead.

• The lookback is capped: 28 days for short forecasts, the same as the forecast duration above that, and 90 days for anything longer than 90 days.

• Microsoft recommends at least 90 days of history for an annual forecast.

• It is calculated for the total, not per service, even when you group by service.

So a 12-month forecast in the portal is the last quarter extended in a straight line. It is a good check on your baseline. It has no idea that you are launching in Europe in April or retiring a SQL Managed Instance in March, and it will happily extrapolate a one-off spike unless you filter it out.

Step 1: Build a clean baseline

Microsoft's own FinOps guidance describes the procedure, and it works. In Cost analysis:

1. Switch the metric to Amortized cost, so commitment purchases are spread across their term. (Cost analysis does not show amortized reservation costs for pay-as-you-go MS-AZR-0003P subscriptions; both views show the same numbers there.)

2. Look back as far as you plan to look forward. For a 12-month budget, take the last 12 months at monthly granularity.

3. Filter out purchases (Charge type = Purchase) and note them; you will add commitments back in Step 3.

4. Group by subscription and resource group. Remove anything deleted. Remove anything new or reconfigured during the period and note it separately.

5. Investigate every spike or dip before deciding whether it belongs. If a month jumped and nobody knows why, that is worth an hour on its own: our 30-minute diagnosis for a rising Azure bill is a good starting point.

What remains is the run rate of things that will still exist next year in roughly their current form. Take the average of the last three clean months as your baseline per month. The FinOps Foundation's maturity model makes the same choice: at its most mature level, forecasts are tracked against discount-adjusted, amortized usage.

Step 2: List the changes you already know about

Ask each engineering lead one question: what will you start, stop, move or resize in 2027? Write each answer as a line with a monthly amount and a start month. Price new things with the Azure pricing calculator, and price removals from the actual cost of the resources being removed.

Keep the list short and named. "New EU region, from April, owner Priya" is a forecast line. "Infrastructure growth" is not.

Step 3: Put commitments in their own line

Commitments distort budgets in three ways, and each needs a decision written down.

Expiries. Reservations renew automatically by default, with the same SKU, region, scope and quantity, at a renewal price Azure shows 30 days before expiry. A three-year reservation bought in 2024 for a workload you have since rebuilt will renew itself in 2027 unless someone turns renewal off. List every reservation and savings plan that expires in 2027 and mark it renew, resize or let lapse.

Purchases. New commitments lower amortized cost from the month they start. If you plan to buy, put the saving in from that month, not from January. For reservations on services that savings plans cover, note that purchases made after February 1, 2027 can't be exchanged, which may change what and when you buy. We went through the trade-offs in reservations versus savings plans.

Cash timing. Upfront and monthly payment cost the same in total for reservations and savings plans. Upfront creates a cash spike and, in actual cost, one enormous month. Unless finance wants the cash out early, monthly payment keeps the budget, the invoice and the amortized view aligned. If you are billed under a Microsoft Customer Agreement in a currency other than US dollars, monthly commitment payments can vary with the exchange rate, which is worth a sentence in the assumptions.

Step 4: Tie growth to a driver

Split the baseline into the part that scales with the business and the part that does not. Shared platform cost (networking, monitoring, CI runners, identity, the minimum footprint of each environment) tends to be flat. Compute and storage behind customer workloads tends to move with customers, transactions or data volume.

Grow only the variable part, and grow it with the same driver the business plan uses. If sales is planning for 25% more customers by December, use that, phased across the year. If the plan has a launch, use the launch date. That way the cloud budget and the revenue plan rise and fall together, and a miss on one explains a miss on the other.

Step 5: Count savings honestly and add a buffer

Planned optimization belongs in the forecast only when it has an owner and a date. Even then, discount it. Projects slip and savings come in late. Counting half of identified savings is a defensible default until your team has a record of delivering them. If you have no list yet, the Azure cost optimization checklist is a place to build one.

Then add the buffer as a visible line, never hidden inside the other numbers. Size it from your own history: compare last year's monthly budget with actual spend and look at the usual gap. Microsoft's FinOps guidance sets a target of under 12% variance between cost and forecast when there are no anomalies. If you have no history, start with 5 to 10% and say so.

Worked example: a $1.1M forecast in eight lines

Example. A company spends about $88,000 a month on Azure in amortized cost in September 2026. $5,000 of that is an old App Service environment double-running until December, so the clean baseline is $83,000 a month. About $50,000 of the baseline is variable with customer count.

The naive method for the same company, $88,000 times twelve plus 15%, gives $1,214,400. That is about $107,000 higher, and nobody can say which part of it is real. The line-by-line version is lower and, more usefully, every line has an owner who can be asked about it in June.

One line not in the table: a three-year VM reservation that expires in June 2027 with renewal switched on. In this example the decision is to renew at the same quantity, so it changes nothing, but it is written in the assumptions with a date to review it.

How to present it to the CFO

One page. Finance does not need the Cost analysis screenshots; they need to know what would make the number wrong.

1. The number and a range. Expected $1.11M, low case without the EU launch, high case with growth at 40%.

2. The eight lines, exactly as in the table, each with an owner.

3. Monthly phasing, because the run rate in December will be well above January and finance will plan cash by month.

4. Amortized and cash views side by side if any commitment is paid upfront.

5. Three assumptions that matter most and the date each will be confirmed.

6. Re-forecast triggers: a launch date moving, a commitment bought or lapsing, customer growth off plan by more than a set amount.

Then make the portal enforce it. Create a Cost Management budget for 2027 with both actual and forecasted alerts. Two details catch people. Budgets evaluate actual cost, so an upfront purchase can trip a monthly alert; add filters for Publisher type: Azure and Charge type: Usage if you want the budget to track consumption only. And a quarterly or annual budget is spread evenly across its months, so a budget that rises through the year needs separate monthly or quarterly budgets with different amounts. Cost data typically arrives within 8 to 24 hours and budgets are evaluated every 24 hours, so alerts are a day behind at best.

Most of the work in this method is in Step 1 and Step 3, which is where we usually start with a new tenant: a clean amortized baseline and a list of every commitment with its expiry date.

Frequently asked questions

How accurate is the Azure Cost Management forecast?

It is a time series linear regression on your own history. Microsoft documents a lookback of at most 90 days, a horizon of up to a year, and recommends at least 90 days of history for an annual forecast. It projects totals only, not each service. It is a useful sanity check for next quarter, but it knows nothing about launches, migrations or commitments you are planning.

Should an Azure budget use actual or amortized cost?

Forecast in amortized cost, so reservation and savings plan purchases are spread over their term and months stay comparable. Keep a separate cash view for finance if you pay commitments upfront. Cost Management budgets evaluate actual cost, not amortized, so an upfront purchase lands in a single month and can trip a monthly budget alert.

How big should the buffer be in a cloud budget?

Size it from your own track record. Compare last year's monthly forecast or budget with what you actually spent and use the typical gap. Microsoft's FinOps guidance targets forecast variance under 12% for workloads without anomalies. If you have never forecast before, a buffer in the 5 to 10% range, shown as its own line, is a reasonable start.

When should we re-forecast Azure spend?

Quarterly at minimum, and whenever one of the stated assumptions changes: a launch date moves, a migration slips, a commitment is bought or expires, or customer growth departs from plan. Set a Cost Management budget with a forecasted alert so the portal tells you when the run rate drifts above the plan.

Sources

• Start using Cost Analysis: forecasting costs (Microsoft Learn)

• Forecasting, FinOps Framework in the Microsoft Cloud (Microsoft Learn)

• Create and manage budgets (Microsoft Learn)

• Common cost analysis uses: amortized and actual cost (Microsoft Learn)

• Automatically renew Azure reservations (Microsoft Learn)

• Forecasting capability (FinOps Foundation)