Ephemeral OS Disks for VMs and AKS

Ephemeral OS disks are a type of OS disk for Azure VMs that are stored directly on the host machine's local SSD, rather than on Azure managed disks in Azure Storage. This means the OS disk is created on the same physical server that hosts the VM, providing significantly lower latency and higher IOPS compared to standard managed disks. However, because the disk is local, it is not durable—it is lost when the VM is stopped (deallocated) or deleted. Ephemeral OS disks are ideal for stateless workloads such as web servers, development/test environments, and AKS worker nodes, where any persistent data must be stored elsewhere (e.g., on separate data disks or in Azure Files).

When you create a VM with an ephemeral OS disk, Azure places the VM on a host that has a local SSD with enough free space to accommodate the OS disk size. The OS disk is carved from this local SSD and presented to the VM as a standard SCSI disk. The VM's operating system and all data on the C: drive (Windows) or root partition (Linux) reside on this local disk. Because the disk is local, read/write operations do not traverse the Azure Storage network, resulting in lower latency and higher throughput.

When the VM is stopped (deallocated) or deleted, Azure destroys the local OS disk. If the VM is restarted (not stopped and deallocated), the OS disk persists because the VM is simply rebooted on the same host. However, if the VM is stopped (deallocated) and then started again, Azure must provision a new host, and the original OS disk is gone. Similarly, if the underlying host fails, the OS disk is lost. Therefore, applications must be designed to handle this volatility.

To create a VM with an ephemeral OS disk using Azure CLI:

az vm create \
  --resource-group myResourceGroup \
  --name myVM \
  --image UbuntuLTS \
  --size Standard_DS2_v2 \
  --ephemeral-os-disk true \
  --ephemeral-os-disk-placement CacheDisk \
  --admin-username azureuser \
  --generate-ssh-keys

The --ephemeral-os-disk true flag enables the ephemeral OS disk. The --ephemeral-os-disk-placement can be CacheDisk (default) or ResourceDisk (temporary disk). Not all VM sizes support ResourceDisk placement.

To verify that a VM is using an ephemeral OS disk:

az vm show --resource-group myResourceGroup --name myVM --query 'storageProfile.osDisk' -o json

Look for "caching": "ReadOnly" or "caching": "None" and "createOption": "FromImage". The diffDiskSettings property will indicate option: "Local".

For PowerShell:

$vm = Get-AzVM -ResourceGroupName myResourceGroup -Name myVM
$vm.StorageProfile.OsDisk.DiffDiskSettings

If DiffDiskSettings.Option is Local, the OS disk is ephemeral.

Ephemeral OS disks offer consistent, low-latency performance because they are local to the host. For I/O-intensive workloads, this can significantly improve boot times and application responsiveness. However, the performance is limited by the local SSD's capabilities, which vary by VM size. For example, Standard_DS2_v2 provides up to 3200 IOPS and 48 MB/s throughput for the local cache. In contrast, a standard managed OS disk (Premium SSD) might offer 2300 IOPS and 75 MB/s for a P10 disk. The ephemeral disk can outperform managed disks for random I/O patterns.

A large e-commerce company runs a stateless web application on Azure VMs behind a load balancer. The application is designed to be stateless, with session data stored in Azure Redis Cache and user uploads in Azure Blob Storage. The company wants to reduce costs without sacrificing performance. By using ephemeral OS disks for all web VMs, they save approximately 20% on storage costs (the cost of the managed OS disk is eliminated). Additionally, boot times decrease by 30% because the OS disk is local. During a flash sale, the auto-scaling rule triggers new VMs quickly. However, they must ensure that the VM size (e.g., Standard_D2s_v3) has sufficient cache for the OS disk (they use a custom image with a 30 GiB OS). They also configure Azure Monitor to alert if any VM is accidentally deallocated, as that would destroy the OS disk and require a fresh deployment. The main challenge is that they cannot use Azure Backup for the OS disk, so they rely on infrastructure-as-code (ARM templates) to redeploy VMs if needed.

A SaaS provider runs a microservices architecture on AKS. To optimize cost, they use ephemeral OS disks for the agent nodes. They create a node pool with --enable-ephemeral-os-disk and choose a VM size like Standard_D4s_v3, which has 16 GiB of cache, sufficient for the default 30 GiB OS disk (they specify --node-osdisk-size 30). The ephemeral disks reduce node costs by 15% compared to managed disks. The application is designed with persistent volumes for stateful services (e.g., databases) and uses Azure Disks for persistent storage. The key consideration is that node OS updates require replacing nodes (since the OS disk is ephemeral), so they use AKS's node image upgrade feature to roll out new nodes. A common pitfall is forgetting that the OS disk is ephemeral and storing logs on the root partition; they redirect logs to a persistent volume. The exam may ask about the --enable-ephemeral-os-disk flag and the requirement that the node pool VM size supports ephemeral disks.

A software development team uses Azure VMs for daily builds and testing. They create and destroy dozens of VMs each day. Using ephemeral OS disks significantly reduces costs because they only pay for compute time and data disks (if any). They use a base image with a small OS disk (e.g., 30 GiB) to fit within the cache of a Standard_DS1_v2 (which has 7 GiB of cache? Actually DS1_v2 has 7 GiB cache, so they must use a smaller OS disk like 7 GiB or choose a larger size). They automate VM creation with Azure CLI scripts. The main issue is that if a build artifact is mistakenly saved to the OS disk, it is lost when the VM is deallocated. They enforce policies using Azure Policy to ensure that only ephemeral OS disks are used for dev VMs. This scenario is a classic exam example of cost optimization.