Azure Virtual Desktop: Designing the Right Desktop and Application Experience in Azure

Azure Virtual Desktop (AVD) is Microsoft’s desktop and application virtualization service on Azure. It can deliver a complete Windows desktop or individual applications through RemoteApp, while Windows multi-session lets organizations pool capacity instead of assigning a virtual machine to every user.

The real design question is not simply how to deploy virtual desktops. It is what experience each workload requires and how to provide it securely, reliably, efficiently, and at the right cost. That is where AVD and the Azure Well-Architected Framework fit together.

What Azure Virtual Desktop Actually Provides

AVD separates the user’s endpoint from the Windows workload, which runs on session hosts, typically Azure virtual machines (Azure Local is also supported for on-premises scenarios). A host pool groups those session hosts. Pooled host pools share capacity across users and distribute sessions according to load-balancing rules; personal host pools assign dedicated resources to individuals. The right model depends on application compatibility, user experience, isolation, and cost.

Application groups determine what users receive. Desktop application groups expose a complete Windows environment, while RemoteApp groups publish selected applications. Workspaces organize those application groups and present assigned resources to users.

Session-host sizing should reflect CPU, memory, storage performance, application behavior, concurrency, multimedia needs, and working patterns, not simply the largest available VM. In pooled environments, FSLogix commonly allows a user’s profile to follow them between hosts, reinforcing an important principle: critical user state should not live permanently on an individual session-host VM.

Full Desktop or RemoteApp?

Choosing between a full desktop and RemoteApp is one of the most important AVD decisions. A full desktop should not be the default when the requirement is only to deliver a specific application.

When a Full Desktop Makes Sense

A complete AVD desktop fits users who need an entire managed Windows workspace: contractors, developers, task workers using integrated application suites, secure administrators, BYOD users requiring corporate separation, or workloads whose dependencies make individual publishing impractical. It is especially useful when the desktop itself serves as the organization’s security or management boundary.

When a Full Desktop May Be Overkill

If a user already has a capable, Intune-managed endpoint and only needs one specialized or legacy Windows application, recreating the entire PC in Azure can add cost and complexity without much value. RemoteApp lets that application run on an AVD session host while appearing alongside local tools such as Word, Outlook, Teams, and a browser. This often creates a more natural experience and keeps centralized execution close to Azure-hosted data.

A Practical Decision Model

Designing AVD Around the Azure Well-Architected Framework

AVD design should extend beyond creating VMs and publishing desktops. The Azure Well-Architected Framework organizes decisions around five pillars: Reliability, Security, Cost Optimization, Operational Excellence, and Performance Efficiency. The first four are covered here; Operational Excellence gets its own section later, because it builds on the scaling, capacity, and landing-zone decisions that come in between.

Reliability

Reliability depends on the full service chain: identity, networking, profile storage, applications, session hosts, and dependent Azure services. A resilient architecture treats AVD as a system rather than a set of powered-on VMs and accounts for these dependencies in the underlying landing zone.

Microsoft operates the AVD control plane, but the organization remains responsible for the resilience of everything it deploys. Session hosts should be distributed across availability zones where the region supports them, so a single datacenter failure does not remove an entire host pool. Profile storage deserves the same attention. Azure Files with zone-redundant storage (ZRS), or Azure NetApp Files using its Elastic zone-redundant service level or cross-zone replication, protects FSLogix containers against a zone failure; standard Azure NetApp Files volumes are zonal and don’t provide this on their own. FSLogix Cloud Cache can also replicate profiles to more than one storage location.

For business-critical workloads, a recovery plan should define a secondary-region host pool, images replicated through Azure Compute Gallery, and the identity, DNS, and network paths that failover depends on. That plan should be tested regularly, not assumed.

Security

AVD should be integrated with the organization’s broader identity and security architecture, including Microsoft Entra ID, multifactor authentication, Conditional Access, role-based access control, endpoint management, monitoring, secure networking, image management, and patching. Hosting a desktop in Azure does not make it secure by default; the same Zero Trust principles used for endpoints and cloud workloads still apply.

AVD also has controls specific to remote sessions. RDP properties on each host pool govern clipboard, drive, printer, and USB redirection, so data movement between the session and the user’s device can be restricted to what each persona actually needs. Screen capture protection and watermarking help deter data leakage from sensitive sessions, and Azure Private Link can keep AVD connection traffic on private networks instead of the public internet. Session-host images should be hardened, patched on a defined cadence, and deployed with Trusted Launch where supported.

Cost Optimization

Cost optimization is one of AVD’s strongest opportunities because unused VMs do not need to remain running. AVD Autoscale can start and stop session hosts according to schedules and capacity thresholds; pooled host pools that use session host configuration can also create and delete hosts through dynamic autoscaling (in preview at the time of writing). Capacity planning should therefore ask how much capacity is needed throughout the working day, not only how many machines are required.

Performance Efficiency

Performance in AVD is ultimately measured by the user: logon time, application responsiveness, and session quality. Session hosts should be deployed in a region close to users and their data, and VM families should match each persona: general-purpose sizes for most knowledge workers, memory-optimized sizes for heavy applications, and GPU-enabled sizes for graphics-intensive work.

The load-balancing algorithm also matters. Breadth-first spreads sessions for better per-user performance, while depth-first fills hosts to improve density and cost. If a scaling plan is assigned to a pooled host pool, Autoscale applies the load-balancing algorithm configured for each schedule phase rather than the host pool’s own setting, so choose the algorithm in the scaling plan as well. RDP Shortpath and Microsoft Teams media optimization reduce latency and offload real-time traffic, and profile storage must deliver enough IOPS to keep logons fast at peak. Azure Virtual Desktop Insights provides the connection, logon, and host-performance data needed to validate these choices and adjust them as demand changes.

Scaling AVD for Real Usage

Microsoft scaling plans divide the day into ramp-up, peak, ramp-down, and off-peak periods. Capacity can rise as employees begin work, remain sufficient during peak demand, and fall as users leave, while retaining an appropriate overnight baseline. The goal is to balance cost, user experience, and resilience.

For pooled host pools, administrators should set an intentional maximum session limit rather than accept the default. Workload behavior must determine density.

Capacity Planning Should Begin with User Personas

Size AVD around workload personas, not user counts alone. Two organizations with 500 users can need very different architectures, and placing every persona in one host pool can undermine both efficiency and experience. The personas below are a simplified planning model; Microsoft’s session-host sizing guidance uses light, medium, heavy, and power workload types, with GPU-enabled sizes for graphics workloads.

Start with the Azure Landing Zone

For enterprise deployments, AVD should sit within an Azure landing zone that provides governance, security, networking, identity, and operational foundations.

The alternative, creating a VM, installing applications, and adding users, may work for a pilot but can quickly become technical debt. Microsoft’s AVD landing-zone guidance and reference architecture provide a starting point for deployments at scale.

Do Not Forget Operational Excellence

A well-designed environment still requires disciplined operation. Session hosts, applications, and images change; usage patterns evolve; and yesterday’s VM size or scaling plan may no longer fit.

Monitoring should reveal slow logons, host saturation, uneven session distribution, profile-storage issues, resource-heavy applications, excess powered-on capacity, and changing demand. Infrastructure as Code can make deployments repeatable and reviewable instead of allowing the environment to become an accumulation of portal changes. Microsoft recommends first-party AVD templates or deployment tooling for best results with Autoscale.

Where Sycomp Can Help

Disclosure: I work at Sycomp, and this section describes the company’s AVD services.

Sycomp’s AVD implementation approach extends beyond building host pools. It begins with discovery and assessment of users, devices, applications, identities, and infrastructure using available management, asset, and inventory data. The engagement then addresses identity and collaboration configuration, workspaces, host pools, application groups, Intune, application preparation and deployment, and FSLogix profile infrastructure.

Application delivery is treated as a workload in its own right, including endpoint-management integration and preparation for App Attach where appropriate. After deployment, post-assessment and remediation activities support stabilization, rationalization, optimization recommendations, and as-built documentation.

This lifecycle aligns closely with Well-Architected thinking: an environment should be measured, reviewed, documented, and optimized as real usage becomes visible. Sycomp can help guide organizations from discovery and design through implementation and ongoing improvement. The objective is not simply to place desktops in Azure, but to create an environment aligned with the organization’s users, applications, security requirements, operating model, and Azure strategy.

The Desktop Is Not Always the Answer

The Azure Well-Architected Framework keeps the decision focused on more than technical feasibility. The chosen model must also be reliable, secure, cost optimized, operationally sound, and performant.

AVD’s value is its flexibility. Organizations can decide where Windows applications and desktops execute, how they are delivered, how much capacity is available, and how the environment adapts as demand changes. Designed correctly, AVD provides exactly as much desktop as the workload requires.

Microsoft References

• Azure Virtual Desktop deployment guidance
• Azure Virtual Desktop terminology and architecture components
• Publishing applications with RemoteApp
• Azure Virtual Desktop Autoscale
• Azure Virtual Desktop Landing Zone Design Guide
• Azure Well-Architected Framework
• Well-Architected Framework: Azure Virtual Desktop workloads