Choosing Azure Managed Disk Types for Production Workloads

Overview and What You Will Learn

In this lab, you will create VMs with two different Managed Disk types, compare their performance characteristics directly, and understand exactly which workload each disk type is actually built for - so the choice is based on real requirements rather than defaulting to whatever the Portal suggests first.

Why This Matters in Production

A team at a trading platform like Zerodha runs their production database on a Standard HDD because it was the cheapest option shown during setup, and every query during peak trading hours becomes noticeably slower than expected. The database itself was never the problem - the underlying disk simply could not deliver the IOPS a transaction-heavy workload actually needs.

Core Principles

Azure offers four Managed Disk types, and the right choice depends on the workload's actual performance requirements, not a general sense of "production needs the best option."

Every VM has an OS Disk (created automatically, holding the operating system) and can optionally have one or more Data Disks attached separately - keeping application data on its own Data Disk, rather than the OS Disk, makes resizing and replacing the VM itself far cleaner later.

Detailed Step-by-Step Practical Lab

1. Create a Resource Group:

2. Create a VM using a Standard SSD OS disk - a reasonable default for a general-purpose workload:

3. Attach a separate Premium SSD Data Disk to the same VM, simulating a scenario where application data needs stronger performance than the OS disk itself:

4. SSH into the VM and confirm the new disk is visible at the OS level:

5. Format and mount the new Premium SSD disk as a dedicated location for application data:

6. Check the disk's configured performance tier and compare it against the Standard SSD OS disk:

Note

diskIOPSReadWrite shows the guaranteed performance ceiling for this specific disk - Premium SSD guarantees meaningfully higher and more consistent values than Standard SSD at the same size, which is exactly the trade-off being paid for.

7. Clean up:

Production Best Practices & Common Pitfalls

Common Mistake

Choosing Standard HDD or Standard SSD for a production database purely to minimize cost, without checking whether the workload's actual IOPS and latency requirements can be met by that disk tier. A database can look correctly configured in every other way and still perform poorly simply because the underlying disk cannot keep up.

Tip

Keep application data on a separate Data Disk from the OS Disk. This makes it possible to resize, snapshot, or even swap out the underlying VM entirely later, without the data's lifecycle being tied to the OS disk's lifecycle.

• Ultra Disk is the exception, not the default "best" choice. Its configurable, independently tunable IOPS and throughput are genuinely valuable for workloads like SAP HANA or the most demanding databases, but its cost and complexity are unnecessary for a typical web application.
• Disk performance is also affected by VM size, not just disk SKU. Some VM sizes cap the total achievable IOPS across all attached disks - pairing a Premium SSD with an undersized VM can still leave performance on the table.

Quick Reference & Troubleshooting Commands