Azure Virtual Desktop Architecture Principles

Azure Virtual Desktop has matured since its initial release. What was once a complex, sprawling service requiring deep Azure networking expertise is now a viable enterprise VDI platform. But maturity in the product doesn't guarantee maturity in implementations. I've seen AVD deployments that replicate every anti-pattern from legacy Citrix environments, and others that embrace cloud-native principles and end up with a platform that costs less to run.

This post distils the architectural principles I apply when designing AVD solutions. It's not a step-by-step deployment guide; Microsoft's documentation covers that adequately. Instead, it focuses on the decisions that determine whether your AVD platform becomes an asset or a liability.

The fundamental shift: cloud-native, not lift-and-shift

The most common mistake in AVD design is treating it as "Citrix in Azure." Organisations take their existing VDI architecture (ExpressRoute backhaul, domain-joined hosts, on-premises file servers for profiles) and recreate it in Azure. This approach combines cloud costs with on-premises constraints.

A well-designed AVD platform should be cloud-native by default. This means Entra ID-joined session hosts (not hybrid-joined), Azure Files for profile storage (not on-premises file servers accessed over ExpressRoute), and connectivity that doesn't depend on your corporate WAN.

The cloud-native approach eliminates dependencies that create fragility. When your AVD platform doesn't need ExpressRoute to function, you've removed a significant failure domain. When authentication happens against Entra ID rather than domain controllers in a distant data centre, you've improved both resilience and user experience.

This doesn't mean zero connectivity to on-premises resources. Legacy applications still exist, and users need to access them. But that access should be application-level, through services like Zscaler Private Access or Azure Private Link, rather than network-level through broad VPN or ExpressRoute connectivity. The session host itself remains cloud-native; legacy access is an overlay, not a foundation.

Landing zone design: standardisation over flexibility

AVD landing zones often suffer from organic growth. Department A gets a subscription with their preferred configuration. Department B gets another with slightly different policies. Before long, you have a fragmented estate where every deployment is a special case.

The solution is to treat AVD landing zones as standardised patterns, enforced through Azure Policy at the management group level. Departments and regions may have separate subscriptions for billing and RBAC purposes, but the technical implementation should be identical and portable.

The management subscription hosts shared services: orchestration tooling, monitoring, secrets management, and image pipelines. AVD subscriptions consume these services but don't define their own patterns. Because of that separation, deploying AVD in a new region or for a new business unit means instantiating a known pattern, not designing from scratch.

Sizing: the PCU model

VDI capacity planning is hard to get right. Traditional approaches either overprovision, which wastes money, or underprovision, which degrades the user experience. The Peak Concurrent User (PCU) model gives you a structured framework instead.

The core formula is straightforward:

PCU = Headcount × ActivityFactor × OverlapFactor × PeakUplift

Once you have PCU, you need to map it to host pool capacity. This requires defining user personas based on workload intensity:

With personas defined, calculate base hosts for each, add a 15% buffer for drain/failover scenarios, and configure autoscale bands accordingly. The goal is three bands: minimum (off-peak), core (matches PCU), and peak (PCU plus buffer).

Pre-warm capacity 30-45 minutes before expected peaks. Users arriving at 9am shouldn't wait for VMs to spin up. The capacity should already be warm and ready.

Profile management: FSLogix done right

FSLogix profile containers are the standard approach for non-persistent AVD desktops, but implementation details matter. Poor FSLogix design manifests as slow logins, profile corruption, and frustrated users.

Storage selection

Azure Files Premium with Entra Kerberos authentication is the baseline recommendation. For cloud-only identities, it needs no domain controller at all. For hybrid identities, you still need network connectivity to an on-premises domain controller to set the Windows ACLs on the share. Either way, it delivers predictable performance and keeps traffic on the Azure backbone through Private Endpoints. Azure NetApp Files offers better raw performance, but it needs an Active Directory connection, either AD DS or Microsoft Entra Domain Services, which conflicts with a cloud-native identity strategy.

The April 2026 Windows Server update changed the default Kerberos encryption type from RC4 to AES-SHA1. Microsoft warns that file shares hosting FSLogix containers that haven't moved to AES-SHA1 might have access issues, so check yours.

Sizing for logon storms

Profile storage faces its worst case at 8:55am, when everyone logs in simultaneously, not during steady-state usage. Profile attach times should meet a p95 target of under 15 seconds and p99 of under 25 seconds. If your storage can't sustain this during peak logon, users will notice.

Container sizing

Standard users typically need 10-20GB; heavy Outlook or reporting users may need 20-40GB. Enable OneDrive Files On-Demand to reduce storage requirements, and configure exclusions for caches that don't need to roam.

Resilience

Enable soft delete on storage accounts to protect against accidental or malicious deletion. Configure Azure Backup with both snapshots (for fast operational recovery) and vaulted backups (for retention and regional DR). For mission-critical deployments, consider warm standby shares in a paired region with scheduled AzCopy synchronisation.

Application delivery: App Attach as default

Application delivery strategy determines how clean your golden images stay and how quickly you can respond to application changes. App Attach should be the default model for AVD. It delivers MSIX, Appx and App-V packages.

The principle is separation: the golden image holds the operating system, core productivity tools and mandatory agents. Everything else, the line-of-business applications, is delivered dynamically through App Attach. Each application sits in a disk image on Azure Files, in CimFS or VHDX format, and is mounted at user logon based on Entra ID group membership. VHD also works, but Microsoft advises against it.

The benefits compound over time. Image updates no longer require coordination with application owners; the OS and apps have independent lifecycles. Application updates can be staged alongside existing versions and cut over without host redeployment. The MSIX package you build for Intune deployment to physical devices can be reused here once you expand it into an App Attach disk image. Intune doesn't support App Attach, so Azure Virtual Desktop handles that delivery.

Not every application converts cleanly to MSIX. Applications with kernel drivers, complex licensing, or deep system integration may need to be baked into the golden image as exceptions. But these should be documented exceptions with justification, not the default approach.

One limitation: user-driven installs from Intune Company Portal don't work in pooled AVD. On multi-session hosts, Intune supports only the Required and Uninstall app assignment intents; the Available intent, which Company Portal's self-service install relies on, isn't supported. All application delivery must be either machine-assigned in the image or dynamically attached through App Attach.

Image lifecycle: rings and immutability

Treat golden images as immutable and versioned: once built and validated, never modify one in place. Changes result in new versions, and those versions flow through validation rings before reaching production.

A practical ring structure for AVD images:

Each month, a new image is built with cumulative updates, driver updates, and agent updates. This image enters the Insider ring for initial validation. If no blocking issues emerge after a week, it promotes to Pilot. After another week of stable operation with broader user representation, it promotes to Production.

The Insider ring deserves particular attention. Access should be controlled through Entra ID Access Packages, so only nominated testers can reach Insider hosts. That prevents accidental assignment and gives you auditable governance. Each user group added to AVD should nominate at least two members for Insider testing, which gives you test coverage while the blast radius stays small.

Azure Compute Gallery provides the versioning infrastructure. Images are stored with version numbers, and host pools reference specific versions. Rollback is straightforward: point the host pool back to the previous version and reimage hosts.

Orchestration: Nerdio as the operational layer

Azure gives you native tooling for AVD images, host pools, autoscaling and day-to-day operations, but that tooling is split across the Azure portal, PowerShell and various APIs. The fragmentation creates operational overhead and inconsistency.

Nerdio Manager for Enterprise consolidates these operations into a single interface while keeping Azure as the system of record. It orchestrates existing Azure constructs rather than replacing them. Host pools are still Azure resources; images still live in Azure Compute Gallery; autoscaling still uses Azure's native capabilities. Nerdio provides the workflow layer that makes operating these components manageable at scale.

The capabilities worth using day to day:

Treat Nerdio configuration as code. Export configurations regularly, store them in source control, and document the native Azure equivalents. That way you avoid lock-in, and you can rebuild the orchestration layer yourself if you ever need to.

Security: Zero Trust as foundation

AVD security should assume breach. Every component (session hosts, storage, management plane) should be secured independently, with no implicit trust based on network location.

Session hosts

Configure session hosts with no inbound ports exposed. AVD uses reverse connect: the host initiates the connection to Microsoft's control plane, and user traffic flows back through that established channel. There's no technical reason to allow RDP inbound to session hosts, and doing so creates unnecessary attack surface.

Storage

Access storage exclusively through Private Endpoints. This keeps traffic on the Azure backbone and eliminates exposure to the public internet. Authentication uses Entra Kerberos, which removes the need for a domain controller for cloud-only identities. As in Storage selection above, hybrid identities still need that domain controller connectivity to configure share permissions.

Secrets

Secrets belong in Key Vault with Private Endpoints. Automation should use Managed Identities rather than service principals with stored credentials. Never embed credentials in scripts, images or configuration.

Conditional Access

Conditional Access gates entry to the platform. Require MFA, enforce device compliance, block legacy authentication, and consider session controls for sensitive workloads. Entra ID-joined AVD session hosts may not satisfy compliance policies designed for user endpoints, so check any all-resources policy that requires device compliance.

Privileged access

Helpdesk staff don't need local admin on session hosts. They need scoped permissions to drain hosts and restart sessions, which is what least-privilege access looks like in practice for AVD. Administrative access to the management plane should also require PIM activation with justification and time limits.

Monitoring: observability that drives action

Monitoring should answer two questions: "Is the platform healthy?" and "Are users having a good experience?" The first is necessary but insufficient; the second is what actually matters.

Platform health

Platform health metrics include host availability, autoscale events, storage performance, and agent status. These belong in Azure Monitor with alerts configured for anomalies.

User experience

User experience metrics require more nuance. Track login times (target p95 under 30 seconds to interactive desktop), FSLogix attach times (target p95 under 15 seconds), and session reconnect success rates (target above 99%). These metrics should be visualised in dashboards that operations teams review daily.

The goal is proactive identification of degradation before users report it. If FSLogix attach times are trending upward over several days, you want to investigate before they breach SLA. If autoscale is consistently hitting peak capacity, you want to increase headroom before users experience session queuing.

Conclusion

AVD design is fundamentally about making deliberate choices rather than accepting defaults: cloud-native identity over domain join, standardised landing zones over organic growth, immutable images with ring-based promotion over ad hoc updates, and App Attach over image bloat. Each choice compounds the others: the platform becomes easier to run and more resilient, at a lower cost to operate.

The principles in this post aren't theoretical. They come from implementations where the alternative choices caused real pain: fragmented estates no one could govern consistently, login storms that stalled the platform, image updates that ate whole weekends of coordination, and security postures that assumed the network perimeter would cover for weak host configuration.

AVD done well gives you a desktop platform that adapts to business needs instead of constraining them. AVD done poorly is Citrix with a different logo and a larger bill. The difference lies in the design decisions made before the first host is deployed.

If you're planning an AVD implementation or migrating from legacy VDI, I'd be interested to hear about your constraints and challenges.