Virtual desktops earn their place for real scenarios: contractors on unmanaged devices, regulated data that must not leave the boundary, legacy Windows apps that die on modern endpoints, call centers on thin clients. Azure Virtual Desktop is the platform answer, and running it well is three disciplines: session host architecture, profile management, and relentless cost hygiene, because VDI is where cloud bills go to grow.

Architecture: The Control Plane Is Not Yours to Run

Microsoft runs the brokering, gateway, and web access; you run host pools of session VMs in your VNet, joined to Entra (native join with Intune enrollment is the modern default; hybrid join only when legacy auth to on premises resources forces it) and reached by users through reverse connect, no inbound ports open, which fits the network posture of this series perfectly. The pivotal design choice is pooled multi session versus personal: Windows 11 Enterprise multi session hosts many users per VM and is the economic engine of AVD, right for the task worker majority; personal desktops assign a VM per user and are reserved for the developers and specialists whose workload or admin rights genuinely demand isolation. Size pooled hosts against measured concurrency, not headcount, with the D and E series general purpose sizes and a users per vCPU ratio validated by your own monitoring rather than vendor tables. RDP Shortpath over UDP where the network allows cuts latency visibly and costs one setting.

FSLogix: The Profile Problem Solved, With Conditions

Pooled desktops mean any user lands on any host, so the profile must travel: FSLogix mounts each user’s profile as a VHDX from a share at sign in, and the desktop feels personal on interchangeable cattle. The conditions: the share is the performance choke point, Azure Files premium with the AD or Entra Kerberos authentication configured, or NetApp Files when the IOPS profile of hundreds of concurrent mounts demands it (a preview of tomorrow’s storage posts), sized on IOPS per user under login storm, not on capacity. Exclude the right things, OneDrive cache included, Teams optimization enabled, and profiles capped with size quotas plus a cleanup runbook from the Automation post, because unmanaged profile VHDs grow forever. The failure mode to design against is the login storm at 8:55 AM: profile share throttling shows up as hundreds of simultaneous slow logins, which is why the share gets its own dashboards and the autoscale below pre warms capacity before the herd arrives.

The Cost Reality and the Image Pipeline

An idle session host bills like any VM, so autoscale is not optional: the built in scaling plans ramp hosts up before business hours, drain and deallocate them after, and the difference between a scaled and unscaled pool is routinely half the compute bill, before the reservations from the FinOps posts cover the stable floor. Hosts are cattle, so no one patches them interactively: a golden image built by the Image Builder pipeline (the VMSS post’s discipline), applications layered by Intune or MSIX app attach so the image stays thin, and updates shipped by replacing hosts pool wide from the new image version, rolling, with drain mode respecting sessions. Monitoring closes the loop with AVD Insights: login duration percentiles, session host health, and the user experience metrics that decide whether the platform is working, because VDI is judged in milliseconds of input latency by people who will tell you. Evaluate Windows 365 Cloud PCs honestly for the per user predictable cost segment, and let AVD carry the multi session economics and custom image estate it is built for.

Cheers
Osama