Azure managed disks, explained: pick a type and size, Azure does the rest
Every VM needs a disk, and Azure gives you a spectrum 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.
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.
The five types, from fast to frugal
There are five disk types, and they trade performance against cost. Knowing roughly where each sits is enough to choose well:
| Type | Media | Best for |
|---|---|---|
| Ultra Disk | SSD | The most demanding IO — top-tier databases, SAP HANA |
| Premium SSD v2 | SSD | High performance with flexible, granular tuning |
| Premium SSD | SSD | Production workloads and most databases |
| Standard SSD | SSD | Web servers, light-use enterprise apps, dev/test |
| Standard HDD | HDD | Backup, infrequent access, lowest cost |
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 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."
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.