AVD Cost Anomaly Detection and AVD Cost Forecasting Models: Budgeting Azure Virtual Desktop Spend

Azure native cost anomaly detection runs at subscription scope only, compares each day against a forecast trained on the last 60 days, and evaluates 36 hours after the day ends. For an Azure Virtual Desktop estate that is usually too coarse and too late: AVD cost is driven by session behavior inside a host pool, and a runaway autoscale event can add hundreds of session host hours before a subscription-level total moves enough to trip an alert.

AVD is the workload where forecasting is hardest and anomaly detection matters most, for the same reason: the bill is driven by people, not by resources. A resource-based forecast assumes tomorrow looks like yesterday. An AVD estate does not work that way. Monday morning is not Friday afternoon, quarter end is not July, and one department onboarding 80 contractors changes the compute baseline without anybody touching infrastructure.

This is the practical guide to both halves: what Azure gives you natively, exactly where it stops, and how to build a forecast for a consumption model whose denominator keeps moving.

Why AVD costs are hard to forecast

Microsoft is explicit that Azure Virtual Desktop costs come from two sources, underlying Azure resource consumption and licensing, and that virtual machine instances usually cost the most. Those two halves behave in opposite ways when you try to project them forward.

Cost component	What drives it	Forecastability
Licensing	Entitled user count	High. Changes on a known schedule with headcount
Session host compute	Concurrent sessions and the autoscale plan	Low. Moves with behavior, not headcount
Managed disks	Provisioned capacity per host	High while the host count is stable, steps with scaling
FSLogix profile storage	Profile growth per user over time	Medium. Grows monotonically, rarely shrinks without intervention
Network egress	What users do inside the session	Very low. Spiky and behavior-driven
Log Analytics ingestion	Diagnostic settings and host count	Medium. Standard data storage charges apply and scale with hosts

The trap is forecasting the whole estate as one line. Licensing and disks project cleanly from a simple trend. Compute and egress do not, and they are the volatile part. A forecast that averages all six together looks stable right up to the month it is badly wrong.

Consumption does not track headcount

The single most common budgeting error in AVD is projecting cost from entitled users. A department with 200 licensed users and 40 peak concurrent sessions consumes a fraction of the compute of a department with 100 users who all log in at 8am. Your compute forecast has to be built on concurrency, not licenses, and concurrency is not in the billing data at all.

What Azure cost anomaly detection actually does

It is worth reading Microsoft's own description carefully, because the mechanics decide whether it is useful for AVD. From the Microsoft documentation on identifying anomalies and unexpected changes in cost:

• Scope. Anomaly detection is available in Cost Analysis smart views when you select a subscription scope. Anomaly alert rules can only be created at subscription scope.
• Baseline. Anomalies are evaluated for subscriptions daily, comparing the day's total usage to a forecasted total based on the last 60 days, which accounts for recurring patterns such as spikes every Monday.
• Timing. Detection runs 36 hours after the end of the day in UTC, to ensure a complete data set is available. New subscriptions start showing anomaly status within 24 hours of onboarding.
• Model. A univariate time-series, unsupervised prediction and reconstruction-based model trained on 60 days of historical usage, forecasting expected usage for the day. The forecasting uses a deep learning algorithm called WaveNet. Microsoft notes explicitly that it is different from the Cost Management forecast.
• Alerts. Creating one requires the Cost Management Contributor role or the Microsoft.CostManagement/scheduledActions/write permission. There is a limit of five alert rules per subscription, and an anomaly alert email is sent only once, at the time of detection.
• Availability. Cost anomaly alerts are not available for Azure Government, and anomaly alerts are only available in the Azure public cloud.

Two of those deserve emphasis because they are routinely misunderstood. The anomaly model is not the same engine as the Cost Management forecast you see in Cost Analysis, so the two can disagree and neither is wrong. And the alert fires once. If a runaway scale plan runs for six days, you get one email on day one and silence afterward.

Where that leaves an AVD estate

Most AVD deployments live in a resource group inside a subscription that also carries other workloads. Native anomaly detection sees the subscription total. If AVD is 20 percent of that subscription, a 40 percent AVD overrun is an 8 percent subscription movement, which a model trained on 60 days of normal variance may well consider unremarkable. The alert you needed never fires.

The anomaly alert email does include the top resource group changes for the day compared to the previous 60 days, so the resource group is visible once an alert triggers. But the trigger itself is computed on the subscription total. That distinction is the whole problem.

How do I detect AVD cost anomalies at host pool level?

Split the estate so that the thing you want alerts on is the thing being measured. Three approaches work, in ascending order of effort.

1. Give AVD its own subscription. The bluntest fix and the most effective. Anomaly detection then evaluates AVD in isolation, and a 40 percent overrun is a 40 percent movement. It also makes budgets, reservations, and reporting cleaner. The cost is subscription sprawl and a migration.
2. Add budget alerts scoped to the resource group. Microsoft Cost Management budgets can be set at resource group scope even though anomaly rules cannot, and they alert on both actual and forecasted cost. You get up to five thresholds and five email recipients per budget. This is a threshold, not a model, so it catches overruns but not a spike that stays inside budget.
3. Compute your own baseline from usage data. Export cost details, join them to session data, and alert on cost per session hour rather than on total cost. This is the only method that catches the dangerous case: cost rising while sessions do not, which is the signature of a scale plan misfiring.

That third approach needs a usage driver, and Azure has one. Azure Virtual Desktop Insights writes host pool diagnostics to a Log Analytics workspace, and the Connections table is the per-user session record that billing data lacks. Wiring it up requires a designated workspace, a Data Collection Rule, and the Azure Monitor Agent on every session host, plus Desktop Virtualization Reader and Log Analytics Reader. Two limits to plan around: standard Log Analytics data storage charges apply, and Microsoft states that automated deployment is limited to 1,000 session hosts or fewer.

What causes AVD cost spikes?

Knowing the failure modes tells you what to alert on. In practice, AVD overruns cluster into a handful of causes.

Cause	How it shows up in cost	Best signal to alert on
Autoscale plan misconfiguration	Session host hours climb with no matching session growth	Cost per session hour, not total cost
Scheduled task or batch job on session hosts	Overnight compute where concurrency is near zero	Host hours during off-peak windows
Session hosts left running after a maintenance window	A flat step up in daily compute that never comes back down	Minimum daily running host count
FSLogix profile container growth	Storage creeps up monthly and never falls	Provisioned GB per user, trended
Orphaned disks and snapshots after host rebuilds	Storage cost persists after the VM is gone	Disks with no attached VM
Egress from a misconfigured application	Bandwidth spikes unrelated to session count	Egress GB per session hour
SKU change on the host pool image	Per-hour rate rises while hours stay flat	Effective hourly rate per host

Notice how many of these are invisible to a total-cost alert but obvious in a ratio. That is the central design point: alert on cost per unit of work, not on cost.

AVD cost forecasting models that actually hold up

Forecast the two halves separately, then add them. Three models are worth knowing, and the right one depends on how mature your session data is.

Model	How it works	Use when	Weakness
Per named user run rate	Trailing 90-day cost divided by entitled users, multiplied by projected headcount	Personal desktops, stable workforce, first budget cycle	Ignores concurrency entirely, so it misprices any pooled estate
Concurrency-driven compute model	Forecast peak concurrent sessions per host pool, convert to session hosts via the scale plan ratio, price at the host hourly rate, then add licensing separately	Pooled multi-session estates with session data available	Needs the Connections table and a known scale plan; sensitive to the peak assumption
Scenario band	Three concurrency scenarios (base, peak season, contractor surge) producing a range rather than a point	Any estate with seasonal or project-driven demand	Finance has to accept a range, which some budget processes will not

For most estates the concurrency-driven model with a scenario band around it is the honest answer. A single point forecast for a consumption workload implies a precision the data does not support, and when it misses, the credibility cost lands on whoever presented it.

How do I budget for unpredictable user demand in an AVD consumption model?

Separate the floor from the variable. Reserved capacity or a savings plan on the baseline session hosts you always run turns the predictable part into a fixed line, and Microsoft names autoscale as the primary compute mitigation for the rest. Then budget the variable layer as a band with a named trigger: when concurrency exceeds X for five consecutive business days, capacity and budget both step up. That converts an unpredictable number into a decision with a threshold attached, which is what finance actually wants.

One caveat that catches people building the reservation side of this: Azure cost allocation rules do not support purchases, including reservations and savings plans. So if you are also splitting AVD cost across departments with allocation rules, the reservation discount will not flow through them.

Native tools versus third-party tools for monitoring AVD costs

The honest summary is that no single tool does all of it, and the split is predictable.

Capability	Native Azure	Third-party cost platforms
Anomaly detection	Yes, subscription scope only, 36-hour lag, five rules per subscription	Often finer scope and repeated alerting
Budget alerts	Yes, down to resource group, actual and forecasted	Yes, usually with more notification channels
Session-level usage data	Yes, via AVD Insights and the Connections table	Rarely, unless the tool is AVD-specific
Cost per user or per session	No, you build the join yourself	Only the AVD-specialist tools
Cost next to the rest of the cloud and SaaS bill	No	Yes, that is the category

The gap that matters is the fourth row. Billing data knows about virtual machines; AVD Insights knows about sessions; almost nothing joins them automatically. We went through which products actually do that join in our comparison of VDI showback and cost allocation tools, and the short version is that very few of them produce a real per-user dollar figure without you building the join.

For the anomaly half specifically, the trade is between scope and effort. Native detection is free and takes minutes to enable, but it watches the wrong unit for AVD. A platform that ingests Azure billing and alerts at resource group or tag scope catches AVD movements a subscription-level model misses, which is the same argument we make in the wider comparison of cloud cost anomaly detection tools. Either way, the ratio alerts described above are yours to build, because they depend on session data no billing-only tool has.

A practical setup, in order

1. Isolate the scope. Put AVD in its own subscription if you can, or accept that native anomaly detection will only catch large movements and compensate with resource-group budgets.
2. Turn on anomaly detection and one alert rule. It costs nothing, and the five-rule limit means you should spend those rules deliberately rather than filling them with duplicates.
3. Set budgets at resource group scope with forecasted thresholds. Forecasted alerts are the ones that give you time to act. Actual-cost alerts tell you it already happened.
4. Enable AVD Insights and keep the Connections table. This is the usage driver everything else depends on. Watch the Log Analytics ingestion cost, since it is a real line item.
5. Build two ratio alerts. Cost per session hour, and minimum daily running host count. Between them they catch autoscale misfires, forgotten hosts, and SKU changes.
6. Forecast compute and licensing separately, as a band. Reserve the baseline, autoscale the rest, and attach a concurrency trigger to the budget step.
7. Review the profile storage trend quarterly. FSLogix containers grow and do not shrink on their own. This is the slow leak nobody alerts on.

If you run this alongside other cloud workloads, the same discipline of separating a predictable baseline from a behavior-driven variable is what makes cloud cost forecasting tools useful rather than decorative, and it is the mechanism behind the wider case for Azure cost predictability for CFOs. Teams that also want a warning when something outside Azure moves, such as a session host that stops responding or a gateway that starts failing health checks, usually pair the cost alerts with continuous uptime and endpoint monitoring, because a broken component that keeps billing is the most expensive kind.

Questions people ask

Does Azure have built-in cost anomaly detection for Azure Virtual Desktop?

Not specifically for AVD. Azure Cost Management includes anomaly detection, but it operates at subscription scope, evaluating each day's total usage against a 60-day forecast. There is no host pool or AVD-aware detection. If your AVD estate shares a subscription with other workloads, an AVD-only overrun may be too small a share of the subscription total to trigger anything.

How long does Azure take to detect a cost anomaly?

Detection runs 36 hours after the end of the day in UTC, so the earliest you can hear about Monday's spike is Wednesday morning. Microsoft applies that delay to ensure a complete data set. For a runaway autoscale plan that can be hundreds of session host hours before the first email, which is why forecasted budget alerts and ratio-based monitoring are worth adding on top.

How many anomaly alert rules can you create in Azure?

Five per subscription. If you hit the limit, Microsoft's guidance is to edit an existing rule and add yourself as a recipient rather than create a new one. Each anomaly alert email is also sent only once, at the moment of detection, so a sustained overrun produces a single notification rather than a daily reminder.

Is the Azure anomaly model the same as the Cost Management forecast?

No, and Microsoft says so directly. Anomaly detection uses a univariate time-series, unsupervised prediction and reconstruction-based model trained on 60 days of history, with forecasting based on the WaveNet deep learning algorithm. The Cost Management forecast in Cost Analysis is a separate calculation. The two can show different expectations for the same period without either being broken.

What is the best way to forecast AVD costs?

Forecast licensing from entitled users and compute from projected peak concurrency, then add them, and present the result as a band rather than a point. Concurrency drives session host count through your scale plan, and session host compute is the largest and most volatile part of an AVD bill. Forecasting the whole estate from headcount alone consistently misprices pooled multi-session deployments.

Can you set a budget alert on just the AVD resource group?

Yes. Microsoft Cost Management budgets can be scoped to a resource group, unlike anomaly alert rules which are subscription-only. Budgets support monthly, quarterly, and annual resets, up to five thresholds and five email recipients each, and can alert on forecasted as well as actual cost. Note that budget evaluation uses actual cost rather than amortized, and no resource is stopped when a threshold is crossed.

Why did my AVD bill rise when user numbers did not?

Almost always compute hours rather than users. The common causes are an autoscale plan that scales up but not reliably down, session hosts left running after maintenance, a scheduled job keeping hosts awake overnight, or a host pool image moved to a larger SKU. All four raise cost per session hour while session count is flat, which is why that ratio is the single most useful metric to alert on.

If your estate has reached the point where you also need to split that bill across departments, the mechanics of doing it defensibly are covered in our guide to VDI cost allocation and chargeback models.