Microsoft has placed Ephemeral OS Disk support for Azure Virtual Desktop into public preview, giving pooled session hosts a new stateless option that promises faster provisioning, lower OS-disk latency, and dramatically quicker reimage cycles — with clear operational tradeoffs that make it ideal for pooled host pools and less suitable for persistent-desktop scenarios.
Ephemeral OS disks are not a new Azure concept, but their arrival inside Azure Virtual Desktop (AVD) is significant. Microsoft’s Ephemeral OS disk design places the OS layer on the VM’s local storage (cache, temp disk, or NVMe) rather than as a managed disk stored in Azure Storage. That shift reduces network hops and storage latency, enables much faster reimage and provisioning operations, and intentionally makes the VM non-persistent — the OS state is not retained after deletion or reprovisioning. Microsoft documents this capability and lists AVD support as a public preview feature.
This feature aligns with a broader Azure pattern: use ephemeral OS disks for scale-out, stateless workloads where rapid creation, reset and predictable clean state are more valuable than persistent OS-level data. Microsoft’s messaging frames it as an optimization for pooled environments (e.g., shift-work, kiosks, call centers) where session hosts can be created and destroyed rapidly without the need to persist OS-level changes.
However, the tradeoffs are material: the removal of core management capabilities (snapshots, backup, deallocation) and encryption/DR constraints make ephemeral OS disks unsuitable for persistent desktops, regulated workloads requiring disk-level artifacts, or estates that rely on stop-deallocated maintenance workflows. The preview stage further means restrictions (e.g., personal host pools excluded, NVMe/premium SSD restrictions) and possible changes to behavior before GA.
Recommended path:
Conclusion
Ephemeral OS disk support in AVD is an important new tool in the virtual desktop architect’s toolbox: powerful, cost-effective, and fast for stateless host pools — but explicitly not a drop-in replacement for persistent managed OS disks. Organizations should evaluate it as part of an image-driven, autoscale-first strategy and proceed cautiously for workloads with backup, encryption, or compliance requirements that depend on disk persistence.
Source: Petri IT Knowledgebase Azure Virtual Desktop Gets Ephemeral OS Disk Support
Background
Ephemeral OS disks are not a new Azure concept, but their arrival inside Azure Virtual Desktop (AVD) is significant. Microsoft’s Ephemeral OS disk design places the OS layer on the VM’s local storage (cache, temp disk, or NVMe) rather than as a managed disk stored in Azure Storage. That shift reduces network hops and storage latency, enables much faster reimage and provisioning operations, and intentionally makes the VM non-persistent — the OS state is not retained after deletion or reprovisioning. Microsoft documents this capability and lists AVD support as a public preview feature. This feature aligns with a broader Azure pattern: use ephemeral OS disks for scale-out, stateless workloads where rapid creation, reset and predictable clean state are more valuable than persistent OS-level data. Microsoft’s messaging frames it as an optimization for pooled environments (e.g., shift-work, kiosks, call centers) where session hosts can be created and destroyed rapidly without the need to persist OS-level changes.
What exactly is an Ephemeral OS Disk in AVD?
How it works (brief)
- Instead of a managed OS disk stored in Azure Storage, the OS image is combined with a local diff disk on the VM’s local storage (cache, temp disk, or NVMe). Reads may still come from a base managed disk, but writes and the runtime OS state are held on local storage.
- Because the OS is locally resident, boot and reimage are much faster, and I/O latency is lower than a remote managed disk.
- Ephemeral OS disks are intentionally non-persistent: when the VM is deleted or reimaged, any changes to the OS layer are lost. Microsoft explicitly warns that VMs using ephemeral OS disks cannot be deallocated; they can only be restarted, reimaged or deleted.
Supported placements and VM types
- Ephemeral placement options include OS cache, temp disk, and (for newer VM families) NVMe. NVMe placement reached GA for v6 VM series prior to this AVD preview. Placement is defined by the DiffDiskPlacement property and is constrained by the VM size’s local storage capacity.
- Not all VM SKUs are suitable; you must pick sizes that have sufficient local disk and meet image-size requirements (image OS size must fit within the chosen local placement). Microsoft provides size-specific guidance and capacity checks in the portal and documentation.
Key benefits for Azure Virtual Desktop
- Faster provisioning and reimage: Session-host creation and resets are dramatically quicker because the OS runs from local storage. This shortens scale-out windows and reduces user wait time after reprovisioning or image updates.
- Lower latency and higher IOPS: Local NVMe or temp-disk placement reduces read/write latency and increases effective OS-disk IOPS, improving perceived responsiveness for OS-bound operations. Microsoft’s compute team claims large improvements for v6 NVMe placements.
- Cost efficiency for stateless fleets: Since ephemeral OS disks avoid persistent managed OS disk storage for runtime state, they can reduce managed disk storage costs (the diff disk lives on local storage). Microsoft documents that ephemeral disks are free to use (the usual managed disk base cost applies only if you choose a non-default base disk SKU), with options to select a paid Premium base disk when needed for reads and SLA improvements.
- Cleaner image management: Because you expect to reset session hosts frequently, ephemeral OS disks align with image-driven fleet management: update images centrally (Azure Compute Gallery/custom/marketplace images), then reimage hosts quickly to push the change. This reduces configuration drift in pooled environments.
The hard tradeoffs and limitations
Ephemeral OS disks deliberately sacrifice persistence and many disk-management features. Microsoft’s documentation lists explicit limitations for AVD preview deployments that are operationally significant:- No deallocation / stop-deallocated: VMs using ephemeral OS disks cannot be stop-deallocated — they can only be restarted, reimaged, or deleted. This changes lifecycle operations and billing/maintenance flows compared to traditional persistent OS disks.
- No disk snapshots, no VM image capture: You cannot take OS-disk snapshots or capture images from ephemeral OS–backed VMs. Image capture workflows must be performed from traditional managed-disk VMs or from a centralized image pipeline.
- No Azure Backup / Azure Site Recovery: Ephemeral OS disks are not supported by Azure Backup or Site Recovery mechanisms for OS disks. That materially affects disaster-recovery and long-term restore strategies at the OS level.
- No Azure Disk Encryption & no OS-disk swap: These security and management operations are not available for ephemeral OS disks during preview on AVD. If you need OS-disk encryption tied to a managed OS disk, ephemeral is not a fit.
- Limited preview restrictions: The AVD preview initially restricts ephemeral OS disks to pooled host pools configured with session host configuration; personal host pools are not supported. NVMe and Premium SSD placements may be restricted during preview — check the documentation for the current allowed placements in your subscription and region.
Where ephemeral OS disks make sense (use cases)
- Pooled host pools (non-persistent): Large pooled AVD estates where users get a clean session on each connection and their profiles are handled via FSLogix (or cloud profile approaches) outside the OS layer. Ephemeral OS disks reduce provisioning time and simplify host lifecycle.
- Shift-based frontline workers: Retail, hospitality, and healthcare kiosks where quick reset to a known-good image between shifts is essential and no OS changes must be retained.
- High-churn test/dev fleets: Test or validation pools where hosts are created and destroyed frequently; ephemeral OS disks speed iteration and reduce managed-disk costs for OS persistence.
- Scale sets and autoscaling session hosts: Ephemeral OS disks pair well with automated dynamic autoscaling flows because the lifecycle model expects create/delete operations rather than stop/start. Microsoft recommends Dynamic Autoscaling plans for AVD session hosts using ephemeral disks.
Where to avoid ephemeral OS disks
- Personal host pools and dedicated Cloud PC equivalents that require persistence of OS-level changes.
- Workloads needing Azure Backup / ASR at the OS-disk level.
- Regulated or audited environments that require OS-disk-level snapshots or captures for compliance artifacts unless you implement an alternative imaging and audit trail.
- Environments that need OS Disk Encryption (via Azure Disk Encryption) unless an alternative platform-managed encryption approach fits the protection model — and note Microsoft flags limitations around CMK rotation for ephemeral setups.
Practical guidance: How to get started (step-by-step)
- Validate the workload profile.
- Confirm the host pool is a pooled host pool with session host configuration (ephemeral support is limited to this topology during preview).
- Choose VM SKUs carefully.
- Pick VM sizes that have the required cache/temp/NVMe capacity to hold your OS image. If the OS image is larger than the VM’s local placement, portal options will be disabled — Microsoft enforces this at creation time.
- Select placement.
- Decide between OS cache and temp disk placement (or NVMe where available). NVMe offers the highest performance but may have additional constraints.
- Prepare images centrally.
- Use Marketplace, custom managed images, or Azure Compute Gallery images sized to fit the local placement. Keep the image small if you want to use smaller VM SKUs.
- Use Dynamic Autoscaling.
- Microsoft recommends Dynamic Autoscaling plans so session hosts are created and deleted by policy rather than being stop-deallocated — which ephemeral OS disks don’t support. This reduces operational surprises and aligns with the stateless model.
- Test restart, reimage, and patch flows.
- Validate your patching process. With ephemeral OS disks you should plan image updates and test reimage-based patching, because the VM is expected to be replaced rather than deallocated and patched in place.
Performance and cost considerations — verify before you standardize
Microsoft’s performance claims are compelling: NVMe placements for v6 VMs show substantial OS-disk speed improvements (marketing materials referenced “up to 10x” improvements versus managed OS disks in some scenarios). Those numbers are vendor-provided and should be validated against your own workload profile — synthetic I/O compares differently to real user startup patterns. Conduct pilot tests measuring:- OS boot time and login duration under typical multi-user load
- App launch times for standard productivity workloads and heavy I/O apps
- Reimage time for scale-out events and expected autoscaling churn
- Effective cost per usable host when accounting for base disk SKU selection, instance runtime, and local storage tradeoffs.
Security, backup and compliance implications
- Ephemeral OS disks change backup and recovery models. You cannot rely on Azure Backup or Azure Site Recovery for OS-disk level recovery for ephemeral session hosts. Any continuity plan must use image-based provisioning and external backup of user data (OneDrive, FSLogix profile containers, Azure Files, or other cloud sync mechanisms).
- Azure Disk Encryption and OS-disk snapshot workflows are unavailable for ephemeral OS disks — that matters where OS-disk encryption using customer-managed keys is a compliance requirement. Microsoft provides limited CMK support patterns but notes you may have to delete and re-create VMs to rotate keys. Flag these operations as potential compliance blockers.
- For sensitive environments that require immutable OS-disk forensic snapshots, ephemeral is a poor choice unless you implement compensating controls in your image pipeline and audit logs.
Operational recommendations and best practices
- Pilot first: Run a small-scale pilot in a non-production tenant to validate image sizing, login experience, autoscaling, and reimage behavior. Measure boot, login, and app launch times under representative concurrency.
- Centralize images in Azure Compute Gallery and keep them small — smaller images increase the range of VM SKUs available for ephemeral placement and reduce placement failures.
- Rely on FSLogix or cloud profile storage for user state. Ephemeral OS disks only remove OS-disk persistence; user profiles and data must be preserved using cloud-backed profile containers or OneDrive/SharePoint.
- Use Dynamic Autoscaling plans and automated image reimaging to move away from stop/start VM maintenance workflows. Autoscaling should create/delete hosts as load changes, not rely on deallocation.
- Document recovery playbooks: Because OS-disk snapshots and backups are not available, create documented, tested runbooks for reprovisioning hosts, restoring user profile containers, and handling out-of-band failures.
- Test upgrades and key rotations: If you use customer-managed keys, validate key rotation workflows as Microsoft notes rotation may require VM deletion and re-creation for ephemeral-based VMs.
Verified claims and caveats
- Verified: Microsoft’s documentation confirms AVD support for Ephemeral OS disks is in public preview, constrained to pooled host pools with session host configuration and carrying the documented limitations (no deallocation, no snapshots, no Azure Backup, etc.). These details are explicitly shown in Microsoft Learn.
- Verified: Microsoft’s compute blog and docs indicate NVMe placement for ephemeral OS disks reached GA for v6 VM families, bringing NVMe performance to ephemeral workloads. However, AVD preview may restrict NVMe/premium SSD during the preview window — check the AVD doc for current restrictions.
- Caution: Performance uplifts such as “up to 10x faster” are vendor-sourced and depend heavily on VM family, placement, and workload. These numbers should be validated in the customer’s environment before committing to a rollout.
- Timing caveat: Preview features change; Microsoft’s preview notes and “What’s New” pages are the authoritative source for behavior and availability. Do not assume GA behavior or cross-region parity until Microsoft declares GA for the AVD-specific scenario.
Decision checklist for IT leaders (quick)
- Does the workload require OS-disk-level snapshots, Azure Backup, or Azure Site Recovery? If yes → avoid ephemeral OS disks.
- Are users’ profiles and data stored in FSLogix containers, OneDrive, or cloud storage (not dependent on local OS disk)? If yes → ephemeral may be a fit.
- Can your autoscaling and patching strategy be adjusted from stop/start operations to create/delete and reimage flows? If yes → ephemeral aligns with that model.
- Can you size images to fit into available VM local storage for your chosen SKUs? If not → you’ll be blocked at deployment time.
- Have you budgeted for potential Premium base-disk reads or NVMe SKU costs if you require higher SLA/performance? If yes → model TCO carefully.
Final analysis: strengths, risks, and recommended path
Ephemeral OS disks for Azure Virtual Desktop are a pragmatic and technically coherent fit for large, stateless pooled AVD estates where speed, predictable image state, and fast reprovisioning matter more than OS-level persistence. The feature brings genuine operational benefits — faster boot/reimage, reduced OS-disk latency, and alignment with image-driven fleet management — that can reduce help-desk churn and speed scale events.However, the tradeoffs are material: the removal of core management capabilities (snapshots, backup, deallocation) and encryption/DR constraints make ephemeral OS disks unsuitable for persistent desktops, regulated workloads requiring disk-level artifacts, or estates that rely on stop-deallocated maintenance workflows. The preview stage further means restrictions (e.g., personal host pools excluded, NVMe/premium SSD restrictions) and possible changes to behavior before GA.
Recommended path:
- Start with a targeted pilot of pooled host pools using ephemeral OS disks, focused on a representative frontline or pooled desktop group.
- Measure boot/login/app performance and reimage times against your baseline.
- Re-architect profile persistence to use FSLogix/OneDrive and finalize autoscaling rules to create/delete hosts rather than stop/start.
- Validate security and compliance controls (key rotation, encryption, and DR) and only expand once image and recovery playbooks are mature.
Conclusion
Ephemeral OS disk support in AVD is an important new tool in the virtual desktop architect’s toolbox: powerful, cost-effective, and fast for stateless host pools — but explicitly not a drop-in replacement for persistent managed OS disks. Organizations should evaluate it as part of an image-driven, autoscale-first strategy and proceed cautiously for workloads with backup, encryption, or compliance requirements that depend on disk persistence.
Source: Petri IT Knowledgebase Azure Virtual Desktop Gets Ephemeral OS Disk Support