This chapter covers Azure VM storage options — the different disk types, caching, and configurations available for virtual machines. Understanding storage is critical for AZ-900 because it directly impacts performance, cost, and availability of your workloads, and questions on this topic appear in roughly 10-15% of the exam. By the end, you will know exactly which disk type to choose for a scenario and how to avoid common misconfigurations that lead to data loss or unnecessary costs.
Jump to a section
Imagine you're the facilities manager for a skyscraper. Your company's servers are like office workers — they need physical space, power, and cooling to function. In an on-premises data center, you own the whole building: you buy the land, pour the foundation, build floors, install elevators, and run wiring. Every new project means buying more floor space, even if you only need a few desks. Azure is like leasing space in a massive, pre-built skyscraper. The building owner (Microsoft) handles the foundation, structure, and utilities. You just rent floors (storage accounts) and rooms (disks) as needed. A 'managed disk' is like a fully furnished, pre-wired office room — you bring your workers (VMs) and the room is ready with power and network jacks. An 'unmanaged disk' is like an empty room where you must run your own cables and install light fixtures — you manage the storage account that holds the VHD files. 'Ephemeral disks' are like temporary meeting rooms that are cleared out after each session — perfect for short-term compute, but you lose everything when the meeting ends. 'Disk caching' is like a whiteboard in the room where you write frequently used numbers so you don't have to walk to the file cabinet every time. 'Disk striping' (Storage Spaces) is like spreading your files across multiple floors so you can access them faster, but if one floor has a fire, you lose partial data unless you have redundancy (mirroring). This analogy makes the mechanism of Azure storage for VMs clear: you choose the level of management, performance, and durability based on your workload needs.
What Are Azure VM Storage Options and Why Do They Matter?
When you create a virtual machine in Azure, it needs persistent storage for the operating system, applications, and data. Unlike a physical server where you plug in a hard drive, Azure VMs use virtual disks stored in the cloud. The choice of disk type and configuration directly affects performance (IOPS and throughput), cost, and durability. For AZ-900, you must understand the three main categories: managed disks, unmanaged disks, and ephemeral disks, plus the performance tiers (Standard HDD, Standard SSD, Premium SSD, and Ultra Disk).
How It Works: The Mechanism of Azure VM Disks
Every Azure VM has at least two disks: an OS disk (typically 127 GB or less, but can be larger) and a temporary disk (ephemeral). The OS disk is persistent — it survives VM reboots and deallocations. The temporary disk is for short-term data like page files or swap space; it is not persistent and data is lost when the VM is deallocated or redeployed. You can attach additional data disks (up to 64 per VM, depending on size) for application data.
Azure stores these disks as page blobs (VHD files) in Azure Storage accounts. A managed disk simplifies management by abstracting the storage account — you just specify the disk type and size, and Azure handles the underlying storage account, replication, and placement. An unmanaged disk requires you to create and manage a storage account, control replication (LRS, GRS, etc.), and place VHD files in containers. For AZ-900, know that managed disks are the default and recommended option.
Key Components: Disk Types, Tiers, and Pricing
Disk Types: - Managed Disk: Azure manages the storage account. You choose performance tier and size. Supports availability sets and availability zones. Billed per second for provisioned size, not usage. - Unmanaged Disk: You manage storage account. VHD files in blob containers. Older model, not recommended for new workloads. - Ephemeral OS Disk: The OS disk is created on the VM host's local SSD (temporary storage). It is not persistent — data is lost when the VM is deallocated or redeployed. Use for stateless workloads like cache nodes or VMs in a scale set where state is stored elsewhere. Lower cost and faster performance.
Performance Tiers (for managed disks): - Standard HDD: Magnetic drives. Lowest cost, low IOPS (up to 500). For dev/test, backup, or non-critical workloads. - Standard SSD: Solid-state drives, moderate cost, higher IOPS (up to 6,000). For web servers, light databases. - Premium SSD: High-performance SSDs, low latency, high IOPS (up to 20,000 per disk, more with bursting). For production databases, mission-critical apps. - Ultra Disk: Highest performance, sub-millisecond latency, configurable IOPS and throughput independently. For large databases, SAP HANA, real-time analytics. Only available in certain regions and VM sizes.
Pricing: Billed per GB per month for provisioned capacity (not used space). Premium SSD costs more per GB than Standard SSD, which costs more than Standard HDD. Ultra Disk also has a per-IOPS and per-MB/s charge. Managed disks include the cost of storage and management; unmanaged disks add storage account costs.
Comparison to On-Premises Equivalent
On-premises, you buy physical disks (HDD, SSD, NVMe) and connect them via SATA, SAS, or NVMe to a server. You must manage RAID for redundancy, backup, and replacement. In Azure, the storage is virtualized and replicated by the platform. Managed disks offer built-in redundancy (LRS, ZRS) without RAID configuration. The performance tiers correspond to physical drive types: Standard HDD ≈ 7,200 RPM HDD, Standard SSD ≈ SATA SSD, Premium SSD ≈ enterprise NVMe SSD, Ultra Disk ≈ dedicated NVMe with custom performance.
Azure Portal and CLI Touchpoints
Portal: When creating a VM, under the 'Disks' tab you can select OS disk type (Standard HDD, Standard SSD, Premium SSD, or Ephemeral OS Disk) and add data disks. You can also create a managed disk from the 'Disks' blade and attach it to a VM later.
CLI: Use az vm create with --storage-sku to set OS disk type. For example:
az vm create --resource-group myRG --name myVM --image UbuntuLTS --size Standard_DS2_v2 --storage-sku Premium_LRS --admin-username azureuser --generate-ssh-keysTo create and attach a data disk:
az vm disk attach --resource-group myRG --vm-name myVM --disk myDataDisk --new --size-gb 64 --sku Premium_LRSPowerShell: New-AzDisk and Add-AzVMDataDisk. Example:
$diskConfig = New-AzDiskConfig -Location eastus -CreateOption Empty -DiskSizeGB 64 -SkuName Premium_LRS -ResourceGroupName myRG
$disk = New-AzDisk -ResourceGroupName myRG -DiskName myDataDisk -Disk $diskConfig
$vm = Get-AzVM -ResourceGroupName myRG -Name myVM
$vm = Add-AzVMDataDisk -VM $vm -Name myDataDisk -CreateOption Attach -ManagedDiskId $disk.Id -Lun 0
Update-AzVM -ResourceGroupName myRG -VM $vmChoose a disk type
Decide between managed and unmanaged disks. For AZ-900, remember that managed disks are the modern, recommended approach. Managed disks simplify management by hiding storage account complexity, provide higher availability (99.999% with LRS), and support availability zones. Unmanaged disks require you to manage storage accounts and replication. In the portal, when creating a VM, you are using managed disks by default. If you need unmanaged disks, you must explicitly configure them via the 'Advanced' settings or use ARM templates that specify unmanaged VHDs.
Select performance tier
Based on workload requirements, choose Standard HDD (lowest cost, low IOPS), Standard SSD (balance of cost and performance), Premium SSD (high performance, low latency), or Ultra Disk (highest performance, independent IOPS/throughput). For the OS disk, Premium SSD is often used for production VMs. For data disks, match the tier to the application's needs. The exam expects you to know that Premium SSD requires a VM series that supports Premium Storage (e.g., DS-series, ES-series, FS-series). If you attach a Premium SSD to a non-premium-capable VM, it will still work but at Standard SSD performance.
Configure caching
Azure disk caching uses the VM's host local SSD to cache reads and writes. Options: None, ReadOnly, ReadWrite. ReadOnly caches reads from the disk to the host SSD for faster read performance. ReadWrite caches both reads and writes — writes are written to cache first and then flushed to disk. For OS disks, ReadWrite is default. For data disks used for databases (like SQL Server), use None to avoid write cache corruption. The exam may test that ReadWrite caching can cause data loss if the VM crashes before cache is flushed. Choose caching based on workload: ReadOnly for read-heavy, None for write-heavy transactional workloads.
Set disk size and performance
For managed disks, you provision a size in GB. The disk's baseline IOPS and throughput depend on the tier and size. For Premium SSD, larger disks provide higher IOPS and throughput. For example, a P30 (1024 GB) gives 5000 IOPS and 200 MB/s. You can also enable bursting (for Premium SSD P20 and smaller) for short bursts of up to 3500 IOPS. For Ultra Disk, you set IOPS and throughput independently. For Standard HDD/SSD, performance scales with size. The exam may ask about bursting and that it is automatic for eligible disks under 512 GB.
Attach and configure in OS
After attaching a data disk to a VM via portal or CLI, you must initialize and format the disk inside the VM OS. In Windows, use Disk Management or PowerShell (Initialize-Disk, New-Partition, Format-Volume). In Linux, use fdisk or parted, then mkfs to create a filesystem, and mount it. The exam does not test OS-level steps, but you should know that Azure does not automatically format the disk. A common mistake is attaching a disk and expecting it to appear ready — you must format it. Also, note that you can attach a disk to multiple VMs only if using shared disks (Azure Shared Disks), which is an advanced feature.
Scenario 1: E-commerce Web Application A company runs an e-commerce site on Azure VMs. They use Premium SSD for the OS and data disks to ensure fast page loads and database transactions. The web tier uses Standard SSD for cost savings, as it handles moderate traffic. They enable ReadOnly caching on data disks for product catalog reads. The database tier uses Premium SSD with no caching to avoid write cache issues. They also use managed disks for easier backup with Azure Backup. Problem: They initially used Standard HDD for the database, causing slow checkout and timeouts. After switching to Premium SSD, performance improved by 10x.
Scenario 2: Stateless Batch Processing A data analytics firm runs hundreds of batch processing jobs on Azure VM scale sets. Each job is stateless — data comes from Azure Blob Storage, and results are written back. They use Ephemeral OS disks to reduce costs and improve performance (local SSD). If a VM crashes, the scale set recreates it with a fresh OS. They save 20% on storage costs compared to persistent managed disks. Problem: They mistakenly used persistent OS disks, and after scaling down, orphaned disks accumulated costs. Switching to ephemeral disks eliminated that overhead.
Scenario 3: Disaster Recovery with Unmanaged Disks (Legacy) A company migrated from on-premises to Azure using unmanaged disks because their backup tool required direct access to VHD files. They have storage accounts with LRS replication. They must manually manage geo-replication for DR. After a regional outage, they failed over to a secondary region by copying VHDs. This took hours. They later moved to managed disks with geo-redundant storage (GRS) for automated DR. The lesson: unmanaged disks add operational complexity and slower recovery. Managed disks with built-in replication are simpler and faster.
Objective Code: AZ-900 Objective 2.2 – Describe core Azure architecture services (specifically, storage for VMs). The exam tests your ability to choose the right disk type and tier for given scenarios.
Common Wrong Answers and Why Candidates Choose Them: 1. "Ephemeral OS disks are persistent." – Candidates confuse them with managed disks because both are OS disks. Reality: Ephemeral disks are not persistent; they are stored on the host and lost on deallocation. 2. "Standard HDD is best for production databases." – Candidates think any disk works. Reality: Standard HDD is too slow; Premium SSD or Ultra Disk is required. 3. "Unmanaged disks are recommended for new workloads." – Candidates may have heard of them from older documentation. Reality: Managed disks are the default and recommended for all new VMs. 4. "Disk caching always improves performance." – Candidates assume caching is always good. Reality: Write caching can cause data loss for write-heavy workloads; use None for databases.
Specific Terms and Values That Appear Verbatim: - "Premium Storage" = VM series that support Premium SSDs (DS, ES, FS, GS, M series). - "LRS" = Locally Redundant Storage (3 copies within one datacenter). - "Bursting" = up to 3500 IOPS for Premium SSD disks under 512 GB. - "Max data disks per VM" = depends on VM size (e.g., Standard_DS2_v2 supports 8 data disks).
Edge Cases and Tricky Distinctions: - An ephemeral OS disk can only be used with certain VM sizes (marked with a 'd' suffix, e.g., Standard_D2s_v3). - Managed disks support both LRS and ZRS (Zone Redundant Storage) for Premium SSD; ZRS is not available for Standard HDD. - You can convert an unmanaged disk to managed disk without downtime using Azure portal or PowerShell.
Memory Trick / Decision Tree: - Is the workload stateless? → Use Ephemeral OS disk. - Is it a production database? → Use Premium SSD (or Ultra Disk for extreme performance). - Is it dev/test? → Use Standard HDD or Standard SSD. - Do you want simple management? → Use managed disks (always). - For caching: Read-heavy → ReadOnly; Write-heavy → None; OS disk → ReadWrite (default).
Managed disks are the default and recommended disk type for Azure VMs; they simplify management and provide higher availability.
Four performance tiers: Standard HDD (low cost, low IOPS), Standard SSD (balance), Premium SSD (high performance, low latency), Ultra Disk (highest performance, configurable IOPS/throughput).
Ephemeral OS disks are stored on the host local SSD and are not persistent; use for stateless workloads like VM scale sets.
Disk caching options: None, ReadOnly, ReadWrite. Use ReadOnly for read-heavy data disks, None for write-heavy transactional workloads (e.g., databases).
Premium SSD requires a VM series that supports Premium Storage (DS, ES, FS, GS, M series).
Bursting is available for Premium SSD disks under 512 GB, providing up to 3500 IOPS for short bursts.
Data disks attached to a VM must be initialized and formatted inside the OS before use.
Unmanaged disks require you to manage storage accounts; they are a legacy option not recommended for new deployments.
These come up on the exam all the time. Here's how to tell them apart.
Managed Disks
Azure manages the storage account automatically.
Higher availability (99.999% with LRS).
Supports availability zones and shared disks.
Simpler deployment and management.
Recommended for all new VMs.
Unmanaged Disks
You must create and manage storage accounts.
Availability depends on storage account replication.
No built-in availability zone support.
More complex to manage, especially at scale.
Legacy option; not recommended for new workloads.
Mistake
Ephemeral OS disks are persistent and survive VM deallocation.
Correct
Ephemeral OS disks are stored on the VM host's local SSD and are lost when the VM is deallocated, stopped, or redeployed. They are only suitable for stateless workloads.
Mistake
All Azure VMs can use Premium SSD disks.
Correct
Only VM series that support Premium Storage (e.g., DS, ES, FS, GS, M series) can use Premium SSD. If you attach a Premium SSD to a non-premium-capable VM, it will perform at Standard SSD speeds.
Mistake
Unmanaged disks are easier to manage than managed disks.
Correct
Unmanaged disks require you to create and manage storage accounts, monitor replication, and handle placement. Managed disks abstract all that, making them simpler and the recommended choice.
Mistake
Disk caching always improves performance and should always be enabled.
Correct
Read caching improves read performance, but write caching can cause data loss if the VM crashes before cache is flushed. For write-heavy workloads (e.g., databases), set caching to None.
Mistake
You can attach a data disk to multiple VMs simultaneously without any special configuration.
Correct
By default, a managed disk can only be attached to one VM. To share a disk across multiple VMs, you must use Azure Shared Disks (preview), which requires specific disk types and configurations.
Managed disks automatically handle the underlying storage account for you, simplifying management and improving reliability. Unmanaged disks require you to create and manage storage accounts and place VHD files in blob containers. Managed disks are the default and recommended option for all new VMs. The exam expects you to know that managed disks are the modern approach.
Use ephemeral OS disks for stateless workloads where the VM can be recreated without data loss, such as VM scale sets, cache nodes, or batch processing. They are cheaper and faster because the OS disk is on the host SSD. However, data is lost when the VM is deallocated or redeployed. The exam may test that ephemeral disks are not persistent.
Yes, you can change the disk type for both OS and data disks without downtime using the Azure portal, PowerShell, or CLI. For example, you can convert a Standard HDD to Premium SSD. However, you must ensure the VM series supports the new type (e.g., Premium SSD requires a Premium Storage-capable VM). The exam might ask about this conversion process.
Disk bursting allows Premium SSD disks under 512 GB to temporarily increase IOPS up to 3500 for short bursts (up to 30 minutes). It is automatic and uses accumulated burst credits. Larger disks have higher baseline IOPS and do not need bursting. The exam may test that bursting is available for disks 512 GB and smaller.
The maximum number of data disks depends on the VM size. For example, a Standard_DS2_v2 supports up to 8 data disks, while a Standard_DS15_v2 supports up to 40. Always check the VM size documentation. The exam does not require memorizing specific numbers but may test that it varies by VM size.
LRS (Locally Redundant Storage) replicates data three times within a single datacenter. ZRS (Zone Redundant Storage) replicates data across three availability zones in the same region, protecting against zone failures. ZRS is available for Premium SSD and Standard SSD, but not for Standard HDD. The exam may ask about redundancy options.
By default, a managed disk can only be attached to one VM. To share a disk across multiple VMs, you must use Azure Shared Disks (preview), which requires specific configurations and is typically used for clustered applications like SQL Server FCI. The exam may not cover shared disks in depth, but know that standard disks are single-attach.
You've just covered Azure VM Storage Options — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?