An Azure cost management setup that sticks rests on three controls that work together. Azure budgets set a spending line for a scope and fire alerts as actual or forecasted cost approaches it. Azure cost alerts, including anomaly alerts, notify the right people when spend crosses a threshold or moves in an unexpected way. Tags attach business context, owner, environment, workload and cost centre, to each resource so the bill can be split and attributed rather than read as one anonymous total. Budgets tell you when spend is drifting, alerts make sure someone hears about it, and tags tell you whose spend it is. Configured carelessly, each rots into noise; configured deliberately, together they turn a cloud bill into something you can govern.
This is a practical setup guide: the scopes to attach controls to, how to build budgets with actual and forecasted thresholds, where anomaly alerts fit, an Azure tagging strategy that holds up, how to enforce it with Azure Policy, and the weekly ritual that stops the whole thing rotting. The savings are directional, because they follow the actions the controls surface, but the structure is the same for almost any estate.
Start with the scopes
Microsoft Cost Management is available at every level of the Azure hierarchy, and where you attach a control decides who it serves. There are three scopes worth knowing.
- Management group. Rolls up many subscriptions, so it suits organisation-wide or business-unit budgets and reporting across everything beneath it.
- Subscription. The most common budgeting unit. Estates often use subscriptions to separate production from non-production, or one business unit from another.
- Resource group. The finest scope, ideal for a single workload, project or team that owns its own resources.
Scopes nest, so a management group sees the cost of the subscriptions and resource groups inside it. Pick the scope that matches who actually owns the spend, then attach the budget there. One caveat to carry forward: budgets work at all three scopes, but anomaly alerts are a subscription-only feature, and action-group automation on a budget is supported only at subscription and resource group scopes.
Scopes nest from management group down to resource; tags flow down for attribution, and budgets and alerts attach at each level.
Create budgets with actual and forecasted alerts
A budget is a spending line for a scope plus the alert thresholds that watch it. In the portal, go to Cost Management, select the scope, choose Budgets, then Add. For a resource group, the path is Cost Management + Billing then Subscriptions, select the subscription, Resource groups, select the group, Budgets, then Add.
Set the amount and a reset period. You can align to the calendar with Monthly, Quarterly or Annually, or to your invoice with Billing month, Billing quarter or Billing year. Then configure two kinds of alert:
- Actual cost alerts fire on cost already accrued. A budget needs at least one threshold, expressed as a percentage of the budget, and one email address. You can add up to five thresholds and five email recipients, and notifications are normally sent within an hour of the evaluation.
- Forecasted alerts give advance warning by using Azure's cost forecast, firing when the projection is set to exceed a threshold before the money is actually spent. Switch a threshold to forecasted with the Type field. Thresholds accept a wide range, from 0.01 per cent to 1000 per cent of the budget.
A good default is a forecasted alert around 90 to 100 per cent for early warning, plus actual alerts at, say, 50, 90 and 100 per cent so you see the trend rather than just the breach. For subscription and resource group budgets you can also wire in an Azure Monitor action group with Manage action group during setup, so a threshold can post to Teams, raise a ticket, or trigger automation such as stopping non-production machines. Action groups are not supported at management group scope. To keep emails out of junk folders, add azure-noreply@microsoft.com to your approved senders.
Layer on anomaly alerts
Budgets catch the lines you thought to set. Anomaly alerts catch the surprise you did not. Cost Management runs anomaly detection daily against your normalised usage and flags an unexpected change, a spike or a dip, without you defining a threshold.
Create one under Cost Management then Cost alerts, select + Add, and choose Anomaly as the alert type. A few facts shape how you use them. Anomaly alerts can only be created at subscription scope, they require the Cost Management Contributor role or greater, and there is a limit of five anomaly alert rules per subscription. The email is sent once, at detection, and summarises the change in resource group count and cost along with the top resource group movements for the day compared with the previous 60 days. Treat budgets and anomaly alerts as complementary: one watches a known spending line, the other watches for the change nobody planned.
Build a tagging strategy that holds up
None of this attributes cleanly without tags, and here is the detail that trips teams up. In Cost Management a cost record only carries a tag if that tag was applied directly to the resource. Tags are not implicitly inherited from the parent resource group in cost data, and some resources do not emit tags at all. Untagged spend is therefore unattributable: it shows up in the total but cannot be split by team, environment or project.
A workable minimum set of cost allocation tags is small and enforced rather than large and ignored:
- owner, the accountable person or team.
- environment, such as production, non-production, development or test.
- workload or application, so cost maps to the thing it supports.
- cost centre, for chargeback or showback to finance.
Agree the allowed values up front so you do not end up with Prod, prod and PROD splitting the same spend three ways. A tag nobody can rely on is worse than no tag, because it looks like attribution while quietly misreporting.
Enforce the tags with Azure Policy
A tagging strategy only holds if it is enforced, and Azure Policy provides the built-in definitions to do it. Three effects matter.
- Require, using the deny effect. Definitions such as Require a tag and its value on resource groups block creation or update of anything missing the required tag, so new resources cannot arrive untagged.
- Inherit, using the modify effect. Inherit a tag from the resource group adds or replaces a tag from the parent resource group when a resource is created or updated, and an "if missing" variant only adds the tag when it is absent. There are equivalent definitions that inherit from the subscription. Because these use the modify effect, existing resources can be brought into line by running a remediation task.
- Append, using the append effect. Append a tag and its value to resources stamps a default value when a resource is created without the tag. Note that append does not modify resources that already existed until they are changed, and does not apply to resource groups.
A durable pattern is to require the key tags at the resource group, then use an inherit or modify policy so child resources are born tagged and existing gaps can be remediated. That combination is what keeps attribution complete as the estate grows.
View and allocate cost by tag
Once resources are tagged, the payoff shows up in reporting. In Cost Management open Cost analysis, select a scope, and use Group by to break spend down by any tag, so you can read cost by owner, environment or workload rather than as one figure.
There is also a Cost Management feature that closes the gap left by resources that never carried a tag. The Tag inheritance setting, under Cost Management, Settings, then Manage subscription, applies subscription and resource group tags to child resource usage records. Crucially, it changes only the cost data, not the resources themselves, and it is separate from Azure Policy inheritance, which changes the resource. It is available for Enterprise Agreement, Microsoft Customer Agreement and Microsoft Partner Agreement accounts, takes 8 to 24 hours to apply, and works for the current month. After it is on, you can even filter budgets on the inherited tags.
Make it a weekly ritual
Controls rot when nobody reads them. The habit that keeps this setup alive is a short weekly review, around 15 minutes: open cost analysis grouped by tag, check each budget's burn against its forecast, triage any anomaly emails, and confirm every notable movement has a named owner. That cadence is the difference between governance and decoration, because monthly totals alone tend to leave spend unchallenged, as we argue in why monthly cloud reporting leaves spend unchallenged.
Where EtherInsights fits
Standing this up across one subscription is straightforward. Keeping it healthy across many subscriptions, or across many customers for a managed-service provider, is where it becomes real work, and that is where EtherInsights helps. It reads the estate with read-only visibility, surfaces where spend has drifted or lost an owner, and frames each finding as an action a team can assess, so budgets, alerts and tags produce decisions rather than a backlog of unread emails.
Budgets, alerts and tags are the governance layer; the savings come from acting on what they reveal. Bring them together with the wider cloud cost optimisation programme so the same tags that attribute spend also point to the fixes, whether that is retiring idle resources or Azure VM right-sizing the machines the environment tag shows are oversized. Well-tagged cost is what turns a right-sizing hunch into an owner-backed action.
A cost management setup sticks when it is built to be read, not just switched on. Scope the controls to who owns the spend, set budgets with actual and forecasted thresholds, add anomaly alerts where they are available, enforce a small tag set with Azure Policy, and review it weekly. Do that and the bill stops being a monthly surprise and becomes something you steer.
Explore cloud cost optimisation to see how budgets, alerts and tags turn Azure spend into owner-backed decisions.