← Azure projects

Azure · Reference Architecture

Azure Virtual Desktop Enterprise Architecture

Deliver enterprise virtual desktops with disposable session-host compute, resilient user profiles, secure identity, predictable scaling, and an explicit recovery model.

PlatformAzure
DomainEnd User Computing
LevelAdvanced
Last reviewed2026-09-19
Use whenDeliver centrally managed virtual desktops with predictable profiles, secure access, operational visibility, and an explicit recovery strategy.
Key decisionSeparate profiles from compute
Primary servicesAzure Virtual Desktop · FSLogix · Azure Files
Cost focusSession host VM size and operating schedule
On this page

Building blocks

Azure Virtual DesktopFSLogixAzure FilesMicrosoft Entra IDAzure MonitorDefender for Cloud

Design goal

Keep the user experience recoverable and manageable by separating profile state from session-host compute and designing identity, storage, networking, and scaling together.

Success criteria

  • Separate user profile state from session host compute
  • Scale session hosts independently
  • Keep identity and profile services resilient
  • Design recovery around user experience, not only VM recovery

Architecture

Users authenticate through Azure Virtual Desktop, connect to pooled session hosts, and load profiles from FSLogix containers on Azure Files or another supported SMB storage platform.

Architecture flow

  • User authenticates with Microsoft Entra ID
  • AVD brokers the session
  • Session host starts user session
  • FSLogix mounts the user profile container
  • Monitoring and security telemetry flow to central operations
UsersAVD ServiceSession HostsFSLogix ProfilesIdentity / DNSMonitor / Protect
Users
AVD Service
Session Hosts
FSLogix Profiles
Identity / DNS
Monitor / Protect

Architecture decisions

Decision

Separate profiles from compute

Why

FSLogix profile containers allow session hosts to remain disposable and make host-pool scaling and replacement easier.

Trade-off

Disposable session hosts simplify scale and replacement, but profile storage becomes a critical shared dependency whose latency and recovery directly affect users.

Decision

Choose profile storage from concurrency and recovery requirements

Why

Azure Files is a common choice; performance tier, share count, and recovery design should be validated against concurrent user behavior.

Trade-off

Higher-performance and replicated storage improves user experience and recovery, but increases storage cost and operational design complexity.

Networking

Make the traffic path explicit. Keep session hosts private where possible, provide deterministic access to identity/DNS/profile storage, and validate latency to user populations.

Security

Protect the control and data paths deliberately. Use Entra identity controls, least-privilege administration, endpoint protection, private networking where appropriate, and centralized logging.

Availability

Design for the failure domain that must be survived. Distribute session hosts across failure domains supported by the region and avoid making a single profile share or domain controller the only dependency.

Disaster recovery

Treat regional recovery as a separate operating state. For multiregion AVD, align host pools, identity, images, application delivery, and profile replication. FSLogix Cloud Cache can be used for profile resiliency across storage locations when appropriate.

Cost drivers

  • Session host VM size and operating schedule
  • Profile storage tier/capacity
  • Image management
  • Monitoring/log ingestion
  • Secondary-region readiness

Design assumptions

  • User applications support AVD
  • Identity and DNS are reachable from session hosts
  • Profile sizing/concurrency are measured before production

Implementation plan

  1. Define user personas, application requirements, concurrency, image strategy, and profile-size assumptions before sizing host pools.
  2. Choose the Entra ID / Active Directory join model and make identity, DNS, and line-of-sight dependencies explicit.
  3. Design host pools and scaling plans around user concurrency while treating session hosts as replaceable compute.
  4. Place FSLogix profiles on storage sized for capacity, IOPS, throughput, and the required recovery model, with least-privilege access.
  5. Apply network, Defender, monitoring, and image-management controls, then test login storms, host replacement, profile recovery, and autoscaling.

Validate the design

  • Measure sign-in and desktop-ready time for representative user personas under expected concurrency.
  • Remove a session host and confirm the pool replaces capacity without affecting profile state.
  • Drive concurrency across an autoscale threshold and verify scale-out/scale-in follows the approved plan.
  • Recover or redirect the profile-storage dependency in a drill and confirm users can reconnect with the expected profile state.

Architecture basis