Separate access rights from Azure consumption
Microsoft’s current AVD licensing guidance distinguishes internal commercial use from external commercial use. Internal users generally need an eligible Windows or Microsoft 365 entitlement for the operating system scenario. Microsoft also offers per-user access pricing for external commercial purposes, but that is not a substitute for licensing internal employees or contractors who are using AVD for the organization’s own business.
Those access rights are separate from Azure infrastructure. Session-host VMs, storage, networking, profile services, monitoring, and other Azure components still create consumption charges. The estimate should show licensing assumptions and infrastructure assumptions in separate sections so finance can tell whether a future change is commercial or technical.
| Cost layer | Main driver | Planning question |
|---|---|---|
| User access rights | Eligible license or external per-user access model | Are users internal, contractors for internal purposes, or external customers? |
| Session hosts | VM family, size, number, hours running | How many concurrent sessions can each persona safely share? |
| OS/data disks | Disk type and capacity | What performance and image model is required? |
| FSLogix profiles | Capacity, transactions, redundancy, growth | How large are profiles and what storage/authentication fits? |
| Network | Egress, gateways, private connectivity, firewalls | Where are users and app dependencies? |
| Monitoring/security | Logs, Defender or other tools, retention | What operational and security evidence is required? |
| Operations | Image, patch, help desk, incident and vendor support | Who runs the service day to day? |
Cost rule: AVD becomes economical when the organization can match infrastructure to actual concurrency and shut down unnecessary capacity without degrading user experience.
Concurrency is the most important modeling input
Named-user count is not the same as concurrent-session count. A 1,000-user organization may have very different peak concurrency depending on shifts, part-time staff, geography, RemoteApp use, and work patterns. Pooled multi-session AVD can share session-host capacity, so the estimate should model peak and average concurrent users by persona.
Do not overpack hosts to reach a target cost. Application CPU, memory, browser use, multimedia, profile behavior, and supportability determine safe concurrency. Use pilot telemetry and load testing where risk is material. Month-end finance users, call-center shift changes, or a Monday morning sign-in storm can create peaks that do not appear in a daily average.
Model users as personas, not one average
Finance needs a unit model, but engineering needs realistic differences. Knowledge workers, call-center users, developers, graphics users, and task workers can have different VM, application, storage, and concurrency behavior. Build a small set of personas and estimate each separately before rolling them into one monthly forecast.
Uptime and scaling can move the compute line dramatically
Session-host VMs are a major variable cost because Azure charges for compute while VMs are allocated or running under the applicable meter. Native AVD Autoscale can power hosts on and off according to schedules and capacity thresholds. Current Microsoft guidance also describes dynamic autoscaling for certain pooled configurations; exact product status and prerequisites should be checked when the design is implemented.
The estimate should include ramp-up, peak, ramp-down, off-peak, weekends, holidays, disconnected sessions, and support requirements. A low-cost model that leaves no capacity for early users or after-hours incident response is not a production estimate. A global workforce may need multiple time-zone patterns, while a local workforce can use a simpler schedule.
FSLogix profile storage is part of the user experience and the bill
Microsoft recommends FSLogix profile containers for AVD and recommends Azure Files for most customers. Profile cost depends on total profile capacity, growth, transaction pattern, performance tier, redundancy, and storage architecture. Oversized profiles can increase both storage cost and sign-in complexity.
The estimate should account for backup or recovery requirements for profile data if the customer requires them. It should also distinguish the profile from business data. OneDrive, SharePoint, application databases, and file shares may hold authoritative business data; storing everything in the profile can create both cost and recovery problems.
Application delivery changes both density and operations
A simple standardized image can support high operational efficiency. Multiple images, application dependencies, per-user software, heavy browser extensions, specialized drivers, and licensed applications can reduce density or increase maintenance. RemoteApp can reduce desktop complexity for some use cases, but it does not eliminate the session-host infrastructure that runs the application.
Application licensing is separate from AVD pricing. Each software vendor’s rules must be checked for virtualized, shared, concurrent, or hosted use. If a vendor requires a dedicated server, dedicated user environment, or special support configuration, that requirement can change the technical and financial model.
Network and security architecture can create material supporting cost
AVD itself uses reverse-connect architecture, but the environment may still need private connectivity, firewalls, NAT, VPN or ExpressRoute, DNS, identity services, app connectivity, and egress. Security telemetry, Defender products, SIEM ingestion, and monitoring retention should also be included if they are part of the target service.
This is why an estimate built only from session-host VMs can look attractive and still understate the production platform. Shared Azure services should either be allocated to AVD or clearly listed as centrally funded so finance understands the full operating footprint.
Keep a cost model that finance can reconcile to actuals
Record the pricing date, region, VM SKU, expected running hours, sessions per host, profile assumptions, Azure components, licensing assumptions, and exclusions. After the pilot and after go-live, compare actual usage with those assumptions. Variance becomes useful evidence for resizing or updating the forecast.
A practical AVD cost model
| Variable | Low-demand scenario | Expected scenario | High-demand scenario |
|---|---|---|---|
| Concurrent users | Lower utilization period | Forecast peak pattern | Launch or seasonal peak |
| Sessions per host | Validated comfortable density | Target operational density | Reduced density if workload is heavier |
| Running hours | Aggressive off-hours shutdown | Business and support schedule | Extended hours or global coverage |
| Profile size/growth | Controlled profile baseline | Observed pilot growth | Higher data or app-cache growth |
| Monitoring/logs | Core operational telemetry | Target security and operations design | Higher incident or compliance retention |
| Network | Mostly Azure/Microsoft traffic | Hybrid app dependencies | High egress or cross-region use |
Use ranges rather than one exact monthly amount when the environment is still being designed. The expected scenario can drive the working budget, while the high scenario shows the financial consequence if concurrency, data, or running hours exceed plan. The low scenario shows how much of the estimate depends on optimization assumptions that may not be achievable immediately.
Optimization levers should be sequenced safely
- Validate persona and concurrency: avoid buying capacity for named users who are not concurrent.
- Rightsize session hosts: use performance evidence, not only CPU averages.
- Use autoscale: align capacity with business hours and disconnected-session behavior.
- Standardize images and apps: reduce operational overhead and unnecessary host fragmentation.
- Control profile growth: manage caches and user data intentionally.
- Review Azure rate options: only after the baseline is stable and current commercial terms are understood.
- Measure unit cost: cost per active user, session, or persona where the denominator is useful.
Budget for the first months of learning
A new AVD environment rarely operates at its final density on day one. Teams may start conservatively, keep extra hosts during rollout, retain old desktop infrastructure during coexistence, or increase logging while tuning. The business case should distinguish pilot and migration cost from steady-state cost so the first production invoice does not look like an unexplained failure.
Hypercare and support effort can also be higher in early waves. If the organization is migrating from Citrix, Horizon, physical desktops, or Remote Desktop Services, both environments may run at the same time. Licensing and infrastructure overlap should be explicit in the migration-year forecast.
Use actuals to reset the model
After the first production wave, replace assumptions with observed concurrency, sessions per host, average running hours, profile growth, network usage, and support demand. A living model helps finance see whether a higher bill is caused by more users, lower density, longer uptime, or an architecture change.
Do not use one month of data blindly. A holiday period, month-end close, seasonal campaign, or staged migration can distort the baseline. Combine observed telemetry with known business events and then update the forecast.
Windows 365 and AVD cost behave differently
Windows 365 Enterprise uses a per-user per-month Cloud PC model and assigns a dedicated Cloud PC to an individual user under the standard Enterprise experience. AVD uses Azure consumption and can share pooled multi-session capacity. Windows 365 can improve cost predictability; AVD can provide more infrastructure flexibility and sharing.
The cheaper option depends on user behavior, management model, required customization, and license context—not only list price. Stable users who need dedicated persistent capacity may value Windows 365 simplicity, while variable concurrent users may benefit from AVD pooling. A mixed strategy can be reasonable when the personas are truly different.
Pricing mistakes to avoid
- Using named users instead of concurrency.
- Assuming the eligible Microsoft license covers Azure infrastructure consumption.
- Ignoring nonproduction or pilot host pools.
- Leaving profile storage, monitoring, security, networking, backup, and support out of the estimate.
- Using a discount commitment to make an oversized baseline look efficient.
- Assuming every user fits the same VM and session-density model.
- Quoting application licensing without validating the software vendor’s current terms.
What to collect before requesting an AVD estimate
- User count and expected peak concurrency by persona.
- Applications, plugins, peripherals, multimedia and performance needs.
- Working hours, time zones and after-hours support expectations.
- Current eligible Microsoft licensing and any external-user scenario.
- Identity and network dependencies.
- Profile and data size plus retention expectations.
- Monitoring, security and recovery requirements.
- Migration or pilot duration and any overlap with the current desktop platform.
Governance keeps AVD cost from drifting
Once AVD is live, cost management should include monthly review of running session-host hours, average and peak sessions per host, idle capacity, profile growth, network changes, and new host pools or images. A new application that forces a separate pool can increase cost even if user count is unchanged.
Assign an owner who can connect finance and engineering. Finance can see variance; the AVD owner can explain whether it came from more users, lower density, scaling changes, a security requirement, or a platform issue. Without that bridge, optimization becomes a recurring argument about whether the bill is “too high.”
Per-user cost can be useful—but only with the right denominator
Executives often ask for an AVD cost per user. That can be useful if the model distinguishes named users from active or concurrent users. Dividing total monthly cost by every licensed user can make a lightly used environment look cheap, while dividing only by peak concurrent sessions can make it look expensive. Choose a denominator that matches the business question and keep the definition consistent.
For operational optimization, cost per active user or persona can reveal whether a specialized pool is becoming expensive. For budgeting, total platform cost plus a separate named-user license view may be clearer. The important point is to avoid a unit metric that hides unused assigned licenses or excess infrastructure capacity.
Rate optimization comes after workload optimization
Once the steady-state host pattern is understood, the organization can evaluate current Azure commercial options that may lower eligible compute rates. Do not start with a commitment purchase before confirming VM family, region, host uptime, and expected demand. A discount on a host that should have been shut down or resized is not the same as optimization.
Commitment decisions also reduce flexibility. An AVD environment may change VM families after a pilot, split into new host pools, move region, or shift users to Windows 365. Finance and engineering should review the same baseline before any long-term rate decision.
Cost ownership should include application decisions
Application requirements can create new host pools, larger VM sizes, premium storage, longer uptime, or special network services. Those changes should be visible as business decisions rather than appearing later as unexplained AVD cost growth. When an application owner requests a dedicated pool or higher-performance persona, include the cost consequence in the architecture decision.
This makes optimization more constructive. Instead of asking the AVD team to reduce the bill indiscriminately, leadership can see which cost is structural to user requirements and which cost is idle capacity, poor scaling, or outdated assumptions.
Estimate variance should have owners
When actual AVD cost differs from the estimate, classify the variance instead of simply resetting the budget. More users, higher concurrency, larger hosts, longer uptime, profile growth, network usage, a new security control, or a changed application architecture require different responses. Assign each major variance to the team that can explain and act on it.
Where BI Cloud Tech can help
BI Cloud Tech can combine Azure Virtual Desktop expertise with a Cost Optimization and FinOps Assessment and Licensing and Consumption Review to build a decision-ready AVD estimate. Final Microsoft and third-party licensing should be validated against current terms and the customer’s agreements.
A practical next step
Create a three-persona worksheet with named users, peak concurrency, business hours, application set, expected sessions per host, and profile size. Add low, expected, and high assumptions instead of one number. That model will explain far more than a generic “cost per virtual desktop.” Contact BI Cloud Tech to request an AVD cost estimate.