Azure disk types, explained: pick a type and size, Azure does the rest
Every VM needs a disk, and Azure gives you five managed disk types, from bargain spinning platter to blistering SSD. Choose the wrong end and you either overpay for speed you never use or throttle the workload you were trying to run.
New to cloud? CAMPUX is a free, build-first course. Start here →
Azure has five managed disk types. Ultra Disk reaches 400,000 IOPS per disk, Premium SSD v2 reaches 80,000, Premium SSD 20,000, Standard SSD 6,000 and Standard HDD 2,000. Only Premium SSD, Standard SSD and Standard HDD can serve as an OS disk. Ultra and Premium SSD v2 are data disks only — the detail most comparison posts leave out.
A virtual machine is not much without storage attached, and on Azure that storage is a managed disk. Microsoft's description captures why they are pleasant to use: they are "block-level storage volumes managed by Azure... like physical disks in an on-premises server, but they're virtualized. With managed disks, you only have to specify the disk type and the disk size, then provision the disk. After you provision the disk, Azure handles the rest." You do not manage a storage account, replication, or placement — you pick a type and a size, and the platform does the plumbing.
Azure disk types compared: the five, side by side
There are five disk types, and they trade performance against cost. These are the per-disk ceilings, taken from Microsoft's disk-types reference and checked in September 2026:
| Disk type | Media | Max IOPS / disk | Max throughput | Max size | OS disk? | Pick this when |
|---|---|---|---|---|---|---|
| Ultra Disk | SSD | 400,000 | 10,000 MB/s | 65,536 GiB | No | SAP HANA, top-tier SQL Server or Oracle, transaction-heavy workloads that need submillisecond latency |
| Premium SSD v2 | SSD | 80,000 | 2,000 MB/s | 65,536 GiB | No | Production workloads that need consistent low latency, and where you want to buy IOPS separately from capacity |
| Premium SSD | SSD | 20,000 | 900 MB/s | 32,767 GiB | Yes | Production workloads that need high performance and low latency, including most databases and any Ultra Disk VM's OS disk |
| Standard SSD | SSD | 6,000 | 750 MB/s | 32,767 GiB | Yes | Web servers, lightly used enterprise applications, development and test |
| Standard HDD | HDD | 2,000 (3,000 with performance plus) | 500 MB/s | 32,767 GiB | Yes, until 8 Sept 2028 | Backup and other noncritical, infrequently accessed data |
Figures are per-disk maximums from learn.microsoft.com — Select a disk type for Azure IaaS VMs, checked September 2026. They are ceilings, not guarantees, and they scale with disk size: a small Premium SSD does not do 20,000 IOPS. Your VM size caps disk performance too, so a fast disk on a small VM is throttled at the VM. Microsoft has announced that Standard HDD stops being usable as an OS disk on 8 September 2028; existing data disks are unaffected. Check the current docs before you size anything for production.
The mental model: SSD types for anything latency-sensitive or production, HDD for cheap and cold. Reach up the ladder only when you have measured a need — paying for Ultra to run a low-traffic web server is money on fire, just as running a busy database on Standard HDD is a self-inflicted bottleneck.
The two surprises in that table are the ones interviews ask about. Ultra Disk and Premium SSD v2 cannot be OS disks. They attach as data disks only, so an Ultra Disk VM boots from a Premium SSD and keeps its hot data on Ultra. Ultra also has no disk caching, no availability-set support, and no zone-redundant storage — it is locally redundant only.
Premium SSD vs Premium SSD v2: what actually changed
Premium SSD sells you a fixed SKU. You buy a P30 and you get 1,024 GiB, 5,000 IOPS and 200 MB/s together, whether you wanted all three or not. Premium SSD v2 breaks the bundle: you set capacity, IOPS and throughput independently, and you can change them without downtime.
- Every Premium SSD v2 disk starts at 3,000 IOPS and 125 MB/s at no extra charge. Above 6 GiB, the IOPS ceiling rises 500 per GiB, to a maximum of 80,000 — so a disk needs at least 160 GiB before it can be set to 80,000 IOPS.
- Throughput on Premium SSD v2 tracks IOPS at 0.25 MB/s per provisioned IOPS, capped at 2,000 MB/s, which you reach at 8,000 IOPS.
- Ultra Disk uses the same idea with bigger numbers: 1,000 IOPS per GiB up to 400,000, and 0.25 MB/s per provisioned IOPS up to 10,000 MB/s. Both types allow four performance changes in any 24-hour window.
- Premium SSD v2 does not support host caching, and in most regions with availability zones you can only attach it to a zonal VM — pick the zone when you create the VM, before you add the disk.
Microsoft's own line is that Premium SSD v2 offers higher performance than Premium SSD while also generally being less costly. If you are choosing today for a new production data disk and the region supports it, v2 is usually the right default. The reason people still run Premium SSD is the OS disk, which v2 cannot be.
Azure disk sizes: what P30, E10 and S20 mean
Premium SSD, Standard SSD and Standard HDD are sold as fixed sizes with letter-and-number names. P is Premium SSD, E is Standard SSD, S is Standard HDD, and the number is a position on the size ladder, not a size in gigabytes. Same number, same capacity across the three families:
| SKU | Size | Premium SSD (P) | Standard SSD (E) | Standard HDD (S) |
|---|---|---|---|---|
| 10 | 128 GiB | 500 IOPS · 100 MB/s | up to 500 IOPS · up to 100 MB/s | up to 500 IOPS · up to 60 MB/s |
| 20 | 512 GiB | 2,300 IOPS · 150 MB/s | up to 500 IOPS · up to 100 MB/s | up to 500 IOPS · up to 60 MB/s |
| 30 | 1,024 GiB | 5,000 IOPS · 200 MB/s | up to 500 IOPS · up to 100 MB/s | up to 500 IOPS · up to 60 MB/s |
| 40 | 2,048 GiB | 7,500 IOPS · 250 MB/s | up to 500 IOPS · up to 100 MB/s | up to 500 IOPS · up to 60 MB/s |
| 80 | 32,767 GiB | 20,000 IOPS · 900 MB/s | up to 6,000 IOPS · up to 750 MB/s | up to 2,000 IOPS · up to 500 MB/s |
Base provisioned figures, checked September 2026. Ladders run P1–P80, E1–E80 and S4–S80. Read the columns across and the point of Premium becomes obvious: on Standard, buying more capacity buys you almost no extra IOPS until the very top of the ladder. Ultra Disk and Premium SSD v2 have no SKU names — you set any size from 4 GiB and 1 GiB respectively up to 64 TiB, in 1 GiB increments.
Two size limits are worth memorising because they show up in real designs. An OS disk maxes out at 4,095 GiB, and if the guest is partitioned with an MBR the usable size stops at 2 TiB — put anything larger on a data disk, or convert the disk to GPT. And the number of data disks you can attach is set by the VM size, not by the disk: check the size's own page before you plan a striped volume, because a small size runs out of disk slots long before it runs out of capacity.
The three roles a disk plays
Every VM has disks in up to three roles, and mixing them up causes real problems:
- OS disk — every VM has exactly one; it holds the operating system and boot volume. Keep it for the OS, not your data.
- Data disk — where your applications and data belong. Microsoft is explicit that you should store apps and data on data disks, not the OS disk, for better backup, performance isolation, and flexibility. You attach as many as the VM size allows.
- Temporary disk — short-term scratch space (page files, swap). The catch that bites people: it is not a managed disk, and its data can be lost on a maintenance event, redeploy, or stop. Never put anything you need to keep on it.
The OS disk boots the machine; the data disk holds what matters; the temporary disk forgets everything the moment the VM does. Put your data on the right one.
Managed disks are designed for 99.999% availability by keeping three replicas of your data, so a failed replica does not lose it. They integrate with availability sets and zones to spread a VM fleet's disks across isolated hardware and datacenters, and everything is encrypted at rest by default. You did not configure any of that — it comes with "managed."
Managed vs unmanaged disks in Azure
An unmanaged disk is a VHD file you store as a page blob in a storage account you create and run yourself. A managed disk is the same virtual disk with the storage account taken away from you. With unmanaged disks you owned the account, its capacity, its IOPS ceiling, and the job of spreading disks across accounts so one busy VM did not throttle its neighbours. With managed disks you name a type and a size and Azure places, replicates and scales the storage underneath.
This is now history rather than a decision. Microsoft announced the retirement in September 2022 and unmanaged disks were fully retired on 31 March 2026, extended from an earlier date of 30 September 2025. Since then you cannot start an IaaS VM that uses unmanaged disks; any that were running were stopped and deallocated. The retirement covers page blobs attached to a VM as virtual disks, not page blobs you read and write through the storage REST APIs — those are unaffected.
You still need the distinction for two reasons. It is a standing exam question on AZ-104 and AZ-900, and old Azure tutorials, ARM templates and Stack Overflow answers are full of vhd: { uri: ... } storage-account syntax that no longer deploys. If a template you copied asks you for a storage account to hold a VM disk, the template predates 2017 and needs the managedDisk form instead.
How managed disk storage works underneath
The word "managed" hides three jobs Azure does for you, and knowing them is the difference between using disks and understanding them.
- Placement. You never choose a storage account or a scale unit. Azure picks the stamp, and it deliberately spreads the disks of VMs in the same availability set across different stamps, so one stamp failure does not take out every instance of your application.
- Replication. Every managed disk is stored as three replicas. That is what gets it to a 99.999% availability design target: one or two replicas can fail and the data is still there. Microsoft reports a 0% annualised failure rate for these disks, with locally redundant storage rated at eleven nines of durability over a year and zone-redundant storage at twelve.
- Scale. You can create up to 50,000 disks of each type per region per subscription, which is why nobody plans storage-account layouts for VM fleets any more.
Encryption at rest is on by default with platform-managed keys, and you can move to customer-managed keys, encryption at host, or confidential disk encryption without changing the disk type. None of that is something you switch on to get the baseline.
What you actually pay for
Disk billing catches people out because you pay for the size you provisioned, not the data you wrote, and Azure rounds the provisioned size up to the next SKU on the ladder. Ask for a 200 GiB Standard SSD and you are billed for an E15 at 256 GiB. Charges are prorated hourly, so a disk deleted after 20 hours costs 20 hours of that SKU.
- Transactions are billed on Standard SSD and Standard HDD on top of capacity. Premium SSD, Premium SSD v2 and Ultra do not bill per transaction.
- Snapshots are billed on used data, not provisioned size — a snapshot of a 64 GiB disk holding 10 GiB is billed at 10 GiB.
- Premium SSD v2 and Ultra bill capacity, IOPS and throughput as three separate lines. The free baseline is 3,000 IOPS and 125 MB/s on v2; going above either raises the bill.
- Ultra Disk carries a VM reservation fee per vCPU if you flag a VM as Ultra-capable and then do not attach an Ultra Disk. Enable the capability when you are ready to use it.
- Reservations cut the price of Premium SSD SKUs from P30 up to P80 on a one-year commitment.
Prices move and vary by region, so read them off the managed disk pricing page rather than from any blog, this one included. The billing model above is the part that stays put.
Snapshots: a point-in-time copy
One feature worth knowing: a snapshot is a read-only, point-in-time copy of a managed disk that exists independently of the source, so you can back up a disk before a risky change and create a fresh disk from it later. It is the quick "save game" before you do something you might regret — distinct from a full image, which captures a whole generalized VM.
The takeaway
Managed disks make VM storage a two-decision problem: type (match SSD-vs-HDD and tier to the workload's real IO needs, not its aspirations) and size. Keep the OS disk for the OS, put applications and data on data disks, and never trust the temporary disk with anything you cannot lose. Lean on the three-replica durability and zone integration you get for free, and take a snapshot before anything risky. Say "Premium SSD data disks for the database, Standard for the web tier, nothing important on the temp disk" and you are sizing infrastructure like an engineer, not clicking the default and hoping.
Questions people also ask
What are the disk types in Azure?
Azure offers five managed disk types: Ultra Disk, Premium SSD v2, Premium SSD, Standard SSD and Standard HDD. Ultra Disk tops out at 400,000 IOPS and 10,000 MB/s per disk, Premium SSD v2 at 80,000 IOPS, Premium SSD at 20,000, Standard SSD at 6,000 and Standard HDD at 2,000. Figures checked against Microsoft's disk-types documentation in September 2026.
Which Azure disk type should I use?
Standard HDD for backup and infrequently accessed data, Standard SSD for web servers and dev/test, Premium SSD for production workloads that need low latency, Premium SSD v2 when you want to buy IOPS separately from capacity, and Ultra Disk for SAP HANA and top-tier databases. Start one rung lower than you think and measure before you climb.
What is the difference between Premium SSD and Premium SSD v2?
Premium SSD sells fixed SKUs that bundle capacity, IOPS and throughput together, so a P30 is always 1,024 GiB at 5,000 IOPS. Premium SSD v2 lets you set all three independently and change them without downtime, starting from a free baseline of 3,000 IOPS and 125 MB/s. Premium SSD v2 cannot be used as an OS disk and does not support host caching.
What does P30 mean on an Azure disk?
P is the Premium SSD family, and 30 is a rung on the size ladder rather than a size in gigabytes. A P30 is 1,024 GiB with 5,000 provisioned IOPS and 200 MB/s of throughput. The same numbering runs across Standard SSD as E and Standard HDD as S, so E30 and S30 are also 1,024 GiB but with much lower performance.
What is the maximum size of an Azure managed disk?
Ultra Disk and Premium SSD v2 go up to 65,536 GiB, which is 64 TiB. Premium SSD, Standard SSD and Standard HDD stop at 32,767 GiB, about 32 TiB. An OS disk is capped lower at 4,095 GiB, and a guest partitioned with an MBR can only use 2 TiB of it unless you convert the disk to GPT.
Can Standard HDD be used as an Azure OS disk?
Yes for now, but not for much longer. Microsoft has announced that using Standard HDDs as OS disks will be retired on 8 September 2028, so new builds should boot from Standard SSD or Premium SSD. Ultra Disk and Premium SSD v2 have never been usable as OS disks — they attach as data disks only.
What is the difference between managed and unmanaged disks in Azure?
Unmanaged disks store VHD files in a storage account you create and manage yourself, so you handle capacity and IOPS limits on that account. Managed disks remove the storage account entirely — you pick a type and size and Azure places and replicates the underlying storage. Unmanaged disks were fully retired on 31 March 2026, so this is now a historical distinction.
Can I resize a managed disk in Azure?
Yes. You can increase a managed disk's size and change its type after creation, though growing an OS or data disk usually requires stopping the VM first and extending the partition inside the guest OS afterward. Some SSD-to-SSD type changes and Premium SSD v2 resizes can happen without downtime.
What happens to data on a temporary disk during a VM reboot?
A planned reboot from inside the guest OS usually preserves temporary disk data, but you should not rely on that. A maintenance event, redeploy, resize, or stop/deallocate can wipe it, because the temporary disk is not a managed disk and is not replicated. Treat it strictly as scratch space for page files and swap.
How many replicas does an Azure managed disk keep?
Three. Managed disks keep three replicas of your data within the storage cluster to reach a 99.999% availability target, so one failed replica does not cost you the disk. That replication is automatic and included — you do not configure it, and it is separate from availability sets or zones, which spread VM hardware placement rather than disk replicas.