What’s the best way to forecast Azure costs for executive budgeting?

Do not treat subscription sprawl as only a reporting problem. If nobody can identify the owner of a subscription or workload, it is also a governance, security, and accountability problem. Define who owns each subscription, resource group, and shared service, then use that structure for cost allocation and access controls.

It may take time to clean up an existing environment, but a basic ownership registry and consistent naming and tagging standards can make forecasting much more reliable. Shared services such as firewalls should have an agreed allocation method rather than being left as unexplained central overhead.

For planned work, use the Azure pricing calculator or an equivalent estimate as a starting point. It will not predict usage perfectly, but it gives each project a documented baseline and makes it easier to investigate major differences later.

Tags and billing allocations can help with subscription and shared-resource costs, especially when applied consistently at the resource-group or workload level. I would avoid making every tag mandatory if that causes deployment failures, but ownership and cost-center metadata should still be governed and monitored. A dashboarding tool such as Power BI can present budget, actuals, trends, allocation, and savings more effectively than raw billing exports. Also track material environment changes regularly so cost increases can be connected to launches, scaling, or configuration changes before they become surprises.

I usually separate the forecast into four layers: continuing spend, planned net-new spend, planned removals, and shared overhead such as support plans, commitments, licensing, and administrative costs. Continuing spend can be adjusted for current pricing and usage, while planned projects should be estimated from a basic architecture or resource plan.

Roll those layers into a workbook or reporting model and add a clearly labeled contingency amount, often around 6–10% depending on risk tolerance. Keeping the components separate makes it easier to explain the forecast and later determine which assumptions were inaccurate. For team attribution, establish consistent ownership metadata through subscriptions, resource groups, tags, or another allocation structure. Give executives a concise summary first and keep the detailed breakdown available as an appendix or self-service report.

Treat the native forecast as a baseline, then maintain a change register for everything expected to alter spend. Include the owner, affected team or product, start date, estimated monthly impact, confidence level, and the assumptions behind the estimate. Product launches, migrations, reservations, and shutdowns can then be added as explicit adjustments rather than being hidden inside a historical trend.

For subscription sprawl, maintain a lightweight allocation table that maps each subscription to a team, product, or business unit. The executive view can stay simple: budget, actuals, forecast, variance, and the main changes driving the variance. Showing low, base, and high scenarios is useful when the timing or scale of a launch is uncertain.