By David Smith, Founder and CEO, Atlas AVD, , updated
If your pooled Azure Virtual Desktop (AVD) session hosts run most of the day and keep user profiles in FSLogix, they're good candidates for ephemeral OS disks, and most of the reasons teams give for not switching no longer apply to hosts like that. An ephemeral OS disk puts Windows on the VM's local storage instead of on a managed disk in Azure Storage. Every write stays on the host, and so does every read of what was written there, the ephemeral disk itself isn't billed, and nothing written to it outlives a reimage. The cost is narrow but real: an ephemeral host can't be deallocated. You can only restart it, reimage it or delete it.
The short version: Use ephemeral OS disks for pooled hosts that would be running anyway: pools that work around the clock, the hosts you keep up all day, and hosts covered by a reservation. Keep managed disks for hosts that spend most of the day deallocated, and for personal desktops. Of the five usual objections, three (state on the host, backups, VM size) rarely apply to a pooled host built from an image. The other two (deallocation and Microsoft's support statement) need a decision, and this post gives you what you need to make it.
The Microsoft details below are from Microsoft Learn as of November 2026, with each source linked. For the full support matrix and the scaling settings, see our companion guide to ephemeral OS disks for Azure Virtual Desktop.
What an ephemeral OS disk gives a session host
| Managed OS disk | Ephemeral OS disk | |
|---|---|---|
| Where Windows runs from | A managed disk in Azure Storage | The VM's local storage (its cache, temp or NVMe disk), over a base disk in managed disks |
| OS disk reads and writes | Go to remote storage, within the disk tier's limits | Writes stay on the host. By default, reads of unchanged image files still come from the base disk |
| Windows page file | On the temp disk | On the OS disk, which is local |
| OS disk charge | Billed per disk, whether the host is running or deallocated | None for the ephemeral disk itself. A Standard SSD or Premium SSD base disk is billed |
| Returning to the image | Replace the host | Reimage in place, or replace the host |
| Stop and deallocate | Yes | No |
Microsoft describes ephemeral OS disks as "ideal for stateless workloads", with "lower read/write latency to the OS disk and faster VM reimage" (Ephemeral OS disks). Its AVD page lists "high input/output operations per second (IOPS) and low latency by performing read/write operations directly on the VM's local storage" (Ephemeral OS disks on Azure Virtual Desktop).
Why that matters on AVD. A multi-session host shares one OS disk between everyone signed in to it. Sign-ins, app launches and paging from every session land on that disk, and they land together when the working day starts. Moving the writes, the page file and every changed file from a remote disk to local storage is the main reason to switch. The disk charge you stop paying is the second.
Three limits on those claims. Not every read is local. The default mode is partial caching: "All writes occur on the diff disk, while the base disk serves read operations for original files." Full caching copies the whole OS disk to local storage and removes that dependency, but it needs local storage larger than twice the OS disk size plus 1 GiB, and Microsoft offers it on supported sizes with eight or more vCPUs. Check whether your deployment tooling exposes it. How fast the disk is depends on the VM size: Microsoft says the performance "is dependent upon the VM's local storage", and with temp disk placement the OS disk shares the temp disk's IOPS. The saving depends on the base disk: there's no charge for the ephemeral disk, but if you choose a Standard SSD or Premium SSD base disk, "you pay the applicable base disk charges". Measure sign-in times and cost on a pilot host before you move a pool.
Five reasons teams haven't switched, and whether they still hold
1. "Our hosts hold state"
On a pooled host with FSLogix, the user's profile lives in a container on a file share, and the apps come from the image or from app attach. What's left on the OS disk is Windows, the apps and whatever built up since the host was deployed.
A quick test: could you delete this host today and replace it from your image without anyone losing work? If yes, the host is stateless and the objection is gone. If no, find out what's on it that isn't in the image, and fix that first. It's a problem with or without ephemeral disks.
This objection does hold for personal desktops, where the user's changes live on the OS disk. See pooled vs personal host pools.
2. "We need backups and snapshots of our hosts"
Ephemeral OS disks don't support image capture, disk snapshots, Azure Backup, Azure Site Recovery, OS disk swaps or Azure Disk Encryption. Encryption at host works.
For a pooled host, the image is the backup. You recover a broken host by replacing it, and you protect the image and the profile share. If you capture images from a running production host, move that step to a dedicated image VM on a managed disk. Our guide to golden image management covers the workflow.
3. "Our VM size doesn't support it"
The image's OS disk has to fit on the VM's local storage. The Windows 11 Enterprise multi-session marketplace image is 127 GiB, so you need a size whose cache or temp disk is at least that large. Microsoft's example is Standard_D8s_v3: its 200 GiB temp disk holds the OS disk and leaves about 73 GiB.
Three things to check when you pick a size:
- The size needs local storage. On current series, that means a "d" in the name: Microsoft lists Ddsv5, Dadsv5, Edsv5 and similar as the sizes that support ephemeral OS disks.
- The smallest sizes often fall short. The local disk grows with the vCPU count. Standard_D2ads_v5, for example, has a 75 GiB temp disk, which can't hold a 127 GiB image.
- Trusted Launch reserves 1 GiB of the same local storage for the VM's guest state, so a disk that only just fits on paper won't deploy.
For Azure VMs in general, NVMe placement on v6 and later sizes is generally available. On AVD, the Learn page still says ephemeral OS disks "aren't supported with NVMe and premium SSD during preview". Our AVD sizing guide covers choosing a size.
4. "We save money by deallocating hosts"
This one is real. AVD's biggest saving is switching hosts off when nobody needs them, and an ephemeral host can't be switched off. So the question is what each host's day looks like.
| The host's day | Better OS disk | Why |
|---|---|---|
| Runs around the clock: shift work, follow-the-sun teams | Ephemeral | It's never deallocated, so you give up nothing |
| Covered by a reservation | Ephemeral | The compute is prepaid, so stopping it saves nothing |
| Up all working day, off nights and weekends | Either | Ephemeral if your scaling deletes and recreates hosts. Managed if it stops and starts them |
| Burst host that runs a few hours a day | Managed | Deallocate it, and drop its disk to a cheaper tier while it's off |
| Personal desktop | Managed | The user's changes live on the OS disk |
Ephemeral pools can still scale. They scale by deleting idle hosts and creating new ones. Microsoft recommends dynamic autoscaling with Minimum percentage of active hosts (%) set to 100%, so the scaling plan "only creates and deletes session hosts, rather than starting and deallocating". Deleting a host stops its compute charge just as deallocating does, and leaves no disk behind to pay for. The trade-off is time: creating and registering a host takes longer than starting a stopped one, so begin the morning ramp-up earlier.
If you haven't worked out which hosts run in nearly every hour of the week, Reserved Instances vs Savings Plans on AVD shows how to find that baseline. The same hosts are your first candidates for ephemeral disks.
5. "Microsoft doesn't support it"
Partly true, and worth reading closely. Microsoft's AVD page says: "Ephemeral OS disks in Azure Virtual Desktop are supported only in pooled host pools configured with session host configuration." Those are the automated host pools that come with enhanced host pool management.
| Host pool | In Microsoft's support statement? |
|---|---|
| Pooled, with a session host configuration (automated host pool) | Yes |
| Pooled, standard management (you or your tooling deploy and register the VMs) | No |
| Personal | No |
The same page still carries preview limits for automated pools: only Standard SSD as the OS disk type, no NVMe or Premium SSD, and "not supported in Azure Government". Microsoft's general AVD prerequisites still list ephemeral OS disks among the things that "aren't supported for session hosts", with no mention of the exception.
In a standard pool, Azure doesn't block the configuration: the VM deploys, joins its directory and registers with the host pool like any other. What you give up is the support statement. If you open a case about an ephemeral host in a standard pool, Microsoft can point to its documentation. How much that matters depends on how you use Microsoft support, and on how disposable your hosts really are. If the answer to most host problems is already "replace it from the image", it matters less.
When you shouldn't switch
- Personal host pools. Anything the user changed on the OS disk is lost at a reimage, a redeploy, a resize or a healing event.
- Pools that depend on Start VM on Connect. It starts deallocated hosts, and ephemeral hosts can't be deallocated.
- Small pools used a few hours a day. Deallocating a managed-disk host costs less than keeping an ephemeral one running.
- Hosts that hold keys sealed by the vTPM. For Trusted Launch VMs, Microsoft warns that such keys "might not be saved" and "could be lost during actions such as reimaging or service healing events".
- Estates that need every configuration inside Microsoft's support statement and don't use automated host pools.
- Azure Government automated host pools, while the preview limit stands.
How to switch
You can't convert a host in place. Either way, the hosts are redeployed.
Automated host pool. Edit the session host configuration to turn on the ephemeral OS disk, then schedule a session host update. Set every phase of the scaling plan to 100% minimum active hosts.
Standard host pool. Deploy new hosts on ephemeral disks next to the old ones, drain the old hosts, and delete them once they're empty. This is the same rollout as an image update; replace hosts vs staged rings compares the ways to run it.
Pilot first. Put one ephemeral host in the pool and compare sign-in time and app launch time against a managed-disk host of the same size. If the numbers don't move, your bottleneck is somewhere else, usually the profile share. Our guide to slow AVD logons walks through finding it.
How Atlas AVD handles ephemeral OS disks
Atlas AVD offers Ephemeral as an OS disk type when you deploy a host pool, next to Premium SSD, Standard SSD and Standard HDD.
- It checks the size first. Ephemeral is offered only on VM sizes that support it, and Atlas warns you when the OS disk won't fit the size's cache, temp or NVMe storage.
- It never tries to stop an ephemeral host. Autoscale doesn't send stop requests that Azure would reject, the power control shows Delete instead of Stop, and a bulk stop skips ephemeral hosts and tells you which ones it skipped.
- Smart Disk Tiering leaves them alone, because there's no managed OS disk to move.
- Always-on hosts. For a managed-disk pool with a reserved baseline, mark those hosts in the pool's Always-on hosts card and autoscale keeps them running.
- DrainGuard deletes drained hosts once they're empty, which is how an ephemeral host leaves a pool.
Atlas deploys and registers session hosts itself, in standard host pools, so an ephemeral pool built with Atlas sits outside the support statement Microsoft gives automated host pools. If you want hosts that deallocate, or a configuration inside that statement, use managed disks with Smart Disk Tiering: it moves the OS disk of a deallocated, empty host down to Standard HDD and back to the pool's performance tier before autoscale starts it again.
FAQ
Should I use ephemeral OS disks for AVD session hosts?
For pooled hosts that run most of the day and keep profiles in FSLogix, usually yes: writes and paging move to local storage, and you stop paying for the OS disk. For hosts you deallocate for most of the day, and for personal desktops, keep managed disks.
Is an ephemeral OS disk faster than a Premium SSD?
It depends on the VM size. An ephemeral OS disk runs at the speed of the VM's local storage, and with temp disk placement it shares the temp disk's IOPS. Writes and changed files never make the round trip to remote storage, but in the default caching mode unchanged image files are still read from the base disk. Compare sign-in times on a pilot host before you decide.
Do ephemeral OS disks cost anything?
There's no charge for the ephemeral OS disk itself. If you choose a Standard SSD or Premium SSD base disk, you pay the base disk charge. In automated host pools, Standard SSD is the only OS disk type while the preview limits stand.
Can I deallocate a session host with an ephemeral OS disk?
No. You can restart it, reimage it or delete it. To stop paying for the compute, delete the host and create a new one when you need it.
What happens to user data on an ephemeral host?
Profiles in FSLogix containers are on a file share and aren't affected. Anything written to the OS disk is lost when the VM is reimaged, redeployed, resized or healed after a host failure. Live migration keeps it.
Does Start VM on Connect work with ephemeral OS disks?
No. Start VM on Connect starts deallocated hosts, and ephemeral hosts can't be deallocated.
Are ephemeral OS disks supported for Azure Virtual Desktop?
Microsoft supports them only in pooled host pools that use a session host configuration, as of November 2026. In standard pooled host pools the configuration deploys and runs, but it's outside that support statement.
Last updated 11 November 2026. Microsoft details are drawn from Microsoft Learn as of November 2026: Ephemeral OS disks on Azure Virtual Desktop, Ephemeral OS disks for Azure VMs and Prerequisites for Azure Virtual Desktop. Microsoft's pages don't yet agree on the preview limits, so check them before you design a pool.