Azure disk types compared: which managed disk should you actually pick?

Azure gives you five managed disk types and a portal dropdown that makes them look interchangeable. They are not — and the right one is decided by three numbers, not by which name sounds fastest.

New to cloud? CAMPUX is a free, build-first course. Start here →

Use Standard HDD for cold, backup, and dev data; Standard SSD for light production; Premium SSD for most production workloads; and Premium SSD v2 or Ultra Disk for high-IOPS, low-latency databases. You pick by the required IOPS, throughput, and latency of the workload — not by the name — and the honest part the vendor pages skip is that the disk is rarely the bottleneck people assume it is.

This is a decision guide, not a glossary. If you want the underlying explanation of what a managed disk even is — the difference from the old unmanaged model, how snapshots and encryption work — read Azure managed disks, explained first and come back. Here we answer a narrower question: given a workload, which of the five do you choose, and where do people waste money getting it wrong.

The five types, and what each is really for

Azure managed disks come in five flavours, and only one of them spins. From slowest and cheapest to fastest and most expensive: Standard HDD, Standard SSD, Premium SSD, Premium SSD v2, and Ultra Disk. The names imply a simple ladder, and roughly they are one — but the two newest tiers, Premium SSD v2 and Ultra, break the pattern by letting you dial capacity, IOPS, and throughput independently instead of buying a fixed size that bundles all three.

Here is the comparison that the portal dropdown should show you and does not. Treat the exact numbers as a snapshot — Microsoft revises limits and prices, and your VM size caps disk performance regardless of what the disk can do — but the direction and the ordering are settled.

Source: Microsoft Learn, "Select a disk type for Azure IaaS VMs — managed disks," updated Nov 2025. Figures are per-disk maximums and change; verify current numbers and prices before you commit.

How to choose: match the numbers, not the name

The mistake almost everyone makes is picking a disk by its adjective. "Premium" sounds like the responsible production choice, so people default to it; "Ultra" sounds like the serious database tier, so it gets specced into designs that never needed it. Neither reasoning survives contact with the workload. The correct method is boring and it works: figure out the IOPS, throughput, and latency your application requires, then buy the cheapest disk that clears those numbers with a little headroom.

Three numbers, in plain terms. IOPS is how many separate read/write operations per second the workload issues — a transactional database with lots of small writes is IOPS-hungry. Throughput is how many megabytes per second move — a workload streaming large sequential files cares about this, not IOPS. Latency is how long each operation takes to come back, and it is the one that makes a database feel slow even when the other two look fine. A workload that needs 4,000 IOPS at sub-millisecond latency is a completely different order than one that needs 40 MB/s of sequential backup writes, even though both are "disk."

So the decision falls out naturally. Cold or sequential and latency-tolerant? Standard HDD. Light production that just wants SSD steadiness? Standard SSD. A normal production workload where you would rather not think hard about it? Premium SSD is the safe default, and it is your only SSD option that can also serve as the OS disk. A database where you want to tune performance without buying a bigger disk to get it? Premium SSD v2 — for most general-purpose production, it is now the best price-performance. And only when you have measured a genuine need for very high IOPS at the lowest latency do you reach for Ultra.

Buy the cheapest disk that clears your numbers with headroom. Everything above that line is money spent on comfort.

The cost trap: over-provisioning Premium and Ultra

Here is where real money leaks, and it is the section the vendor comparison pages will not write because it argues against the upsell. The dominant failure mode in the field is not buying too little disk — it is buying far too much. A team specs Premium SSD everywhere "to be safe," or drops an Ultra Disk under a database that peaks at 3,000 IOPS, and then pays every month for performance the workload never touches.

Premium SSD makes this easy to do because performance is bundled with size in fixed tiers — to get more IOPS you buy a bigger disk, so people size up for headroom they never use. Premium SSD v2 largely fixes that by letting you set IOPS and throughput separately from capacity, which is exactly why it is often cheaper for the same real performance. And Ultra Disk carries a quiet extra cost: enabling Ultra capability on a VM incurs a reservation fee per vCPU even before an Ultra Disk is attached. If you turned it on "just in case," you are paying for a door you never walked through.

The uncomfortable truth: the disk is rarely the bottleneck

Before you agonise over Premium versus Ultra, check whether the disk is even the thing slowing you down — because usually it is not. Three constraints bite first. The VM size caps disk performance: every VM has its own IOPS and throughput ceiling, and a fast disk attached to a small VM is throttled to the VM's limit no matter what the disk can do. The application is frequently the real culprit — an unindexed query hammering the database will look like a slow disk when the fix is a line of SQL. And the network or the caching layer often matters more than raw disk speed for the workloads people worry about.

The practical consequence: "our database is slow, let us buy Ultra Disk" is one of the most expensive wrong turns in cloud engineering. It sometimes works, which is the trap — throwing hardware at a problem can mask it for a while — but you have now locked in a permanent monthly cost to paper over a bug that a query plan would have fixed for free. Measure where the time goes before you spend. The disk tier is the last knob to turn, not the first.

Where disks sit in the wider storage picture

One clarification worth making, because it trips people up constantly: managed disks are block storage for VMs, and they are a different thing from Azure Storage accounts, which give you blobs, files, queues, and tables. If your question is really "blob vs file vs disk," you want the storage account types guide instead — disks are for attaching to a VM as a drive, storage accounts are for object and file data you reach over an API or a share.

The two do share one concept: redundancy. A managed disk can be locally redundant (LRS) or zone-redundant (ZRS) depending on type — Ultra, for instance, is LRS-only today — and that choice affects durability the same way it does for storage accounts. If the LRS-versus-ZRS-versus-GRS distinction is fuzzy, the redundancy field note untangles it. Pick your performance tier and your redundancy independently; they answer different questions.

The short version

Five types, one method. Standard HDD for cold and sequential. Standard SSD for light production. Premium SSD as the safe production default and your only SSD OS disk. Premium SSD v2 as the price-performance winner for tunable production databases. Ultra Disk only when you have measured a real need for very high IOPS at the lowest latency. Choose by IOPS, throughput, and latency; provision conservatively and resize after you measure; and check that the disk is your bottleneck before you pay to fix a problem that lives in the application. Get those habits right and the dropdown stops being intimidating — it becomes a two-minute decision you can defend.

Questions people also ask

What are the different Azure disk types?

Azure managed disks come in five types: Standard HDD, Standard SSD, Premium SSD, Premium SSD v2, and Ultra Disk. The first four besides Standard HDD are solid-state; only Standard HDD is a spinning disk. They differ mainly in the IOPS, throughput, and latency they can sustain, and in price. Standard HDD is the cheapest and slowest; Ultra Disk is the fastest and most expensive.

What is the difference between Standard SSD and Premium SSD in Azure?

Both are solid-state, but Premium SSD sustains far more IOPS and throughput and gives single-digit-millisecond latency with a performance guarantee, so Microsoft positions it for production and IO-intensive workloads. Standard SSD is tuned for consistent performance at lower IOPS — web servers, lightly used apps, and dev or test — at a lower price. If a workload is production and latency-sensitive, use Premium; if it is light and cost matters more than speed, Standard SSD is enough.

Which Azure disk type is best for a database?

For most production databases, Premium SSD v2 is the current sweet spot: it lets you set capacity, IOPS, and throughput independently, gives sub-millisecond latency, and is often cheaper than Premium SSD for the same performance. Premium SSD is a safe, simpler choice and is required if the disk must also be the OS disk. Reserve Ultra Disk for the heaviest transaction-heavy systems such as SAP HANA or top-tier SQL and Oracle that genuinely need very high IOPS and the lowest latency.

Is Ultra Disk worth it?

Only for workloads that genuinely need it. Ultra Disk offers the highest limits — up to 400,000 IOPS and 10,000 MB/s per disk with sub-millisecond latency — but it cannot be an OS disk, has region and feature limitations, and costs the most. If your database is not saturating a Premium SSD v2, you are paying for headroom you never use. Measure your real IOPS and latency first; most workloads never reach the point where Ultra earns its price.

How do I choose an Azure managed disk?

Choose by the numbers your workload needs, not by the name. Estimate the IOPS, throughput, and latency the application requires, then pick the cheapest disk that clears those numbers with a little headroom. Start with Standard SSD or Premium SSD for most cases, move to Premium SSD v2 when you want to tune IOPS and throughput independently, and go to Ultra only for the heaviest low-latency databases. Then measure actual usage and resize down if you over-provisioned.