Azure Managed Disks - Simply Explained

Most people think a virtual machine in Azure just needs a disk. You pick a size, you attach it, and you're done. But the wrong disk can cost you performance or money, sometimes both. And here's the thing, most beginners don't even know they have a choice. Before managed disks existed, the old way was a real hassle. You had to create a storage account yourself, then create a page blob inside it, then attach that blob to your VM. And you were responsible for everything. The storage account limits the performance, the replication, hit a limit, and your VM slowed down. If you didn't plan your storage accounts, right? You'd have to reshuffle everything. Managed disks fixed all of that. By the end of this episode, you'll understand what managed disks actually are, the five main types Azure offers, and how to choose the right one for your workload. So let's start with the simplest question. What exactly is a managed disk? What is a managed disk? The problem it solves. A managed disk is a block level storage volume that as your creates, manages, and replicates for you. That's the official definition. But what does it actually mean? Before managed disks, every time you wanted to attach storage to a virtual machine, you had to go through a whole process, you'd create a storage account, a separate Azure resource with its own limits, then you'd create a container inside it, then a page blob inside that container, then you'd attach that page blob to your VM, and you had to keep track of which storage account held, which disk because each account had caps on IOPS and throughput, go over those caps, and your application would throttle. So you'd end up spreading disks across multiple storage accounts just to avoid hitting limits. It was manual, error-prone, and it did not scale. Managed disks abstract all of that away. You don't create a storage account, a container, or a page blob. You just create a disk, pick a size, and a type, and Azure handles the rest. The storage account still exists behind the scenes, but you never see it, never manage it, and never worry about its limits. One of the biggest benefits is higher availability. When you create a managed disk, Azure places it on a storage scale unit. That's a cluster of storage service inside a data center. And it spreads your disks across different scale units automatically. So if one storage cluster has an issue, it doesn't take down all your disks. With unmanaged disks, if you put multiple VMs on the same storage account, a single failure could affect all of them. Managed disks prevent that. They also scale. You can have up to 50,000 managed disks per subscription per region. That's a lot of storage. Think of it like moving from managing your own file server to using a cloud file service. With the file server, you're responsible for the hardware, the drives, the backups, the network. With the cloud service, you just put your files there and it works. Managed disks are the same idea, less work, more reliability. Now that you know what they are, let's look at the different flavors Azure offers. The premium performance disks, ultra premium SSD V2 premium SSD. Azure gives you five disk types to choose from. Today, we're focusing on the fast ones, the premium performance disks. Let's start with ultra disk. It's the fastest disk Azure has. We're talking up to 400,000 IOPS and sub millisecond latency. That kind of speed is for extreme workloads, large databases, SAP HANA, anything that needs every bit of performance it can get. But here's the thing, there are trade-offs. Ultra disk only supports locally redundant storage or LRS. You can't get zone redundancy because the latency demands are so tight that replicating across zones would add too much delay. And you pay separately for capacity IOPS and throughput. That gives you fine-grained control, but you have to watch the cost. Next up is premium SSD V2, which is the sweet spot for most performance hungry applications. It goes up to 80,000 IOPS and 2,000 MB per second of throughput. But the real advantage is how performance works. It's decoupled from capacity. You can set each dial independently. One 10,000 IOPS on 100 gigabyte disk, no problem. One 50,000 IOPS on a 500 gigabyte disk, also fine. That means you don't have to over-provision storage just to get more IOPS. With older disk types, if you needed more performance, you had to buy a bigger disk. Even if you didn't need the extra space. Premium SSD V2 fixes that, and it's generally less expensive than the original premium SSD for the same performance. Then there's the original premium SSD. It's older but still widely used. Performance is tied to disk size. Bigger disk means more IOPS in throughput. So if you need 5,000 IOPS, you might have to buy a 500 gigabyte disk, even if you only need 100 gigabytes of space. That's the main downside. But here's a neat trick. You can change the performance tier without changing the disk size. So if you need a temporary boost for a batch job, you can bump up the tier and then drop it back down when you're done, with no downtime. That's useful for enterprise apps that need predictable IOPS, but have occasional spikes. The big difference between these three is control. Ultra-disk and premium SSD V2 let you dial in exactly the performance you need. Premium SSD is simpler. Pick a size, get the performance that comes with it, but less flexible. But not every workload needs lightning speed. For everyday tasks, the standard disks are perfectly fine and much cheaper. The cost-effective disks, standard SSD and standard HDD. So what about the rest of us who aren't running SAP HANA? Azure has you covered with two cost-effective options. Standard SSD is like the SSD in your laptop. It's solid state. So it's fast up to 6000 IOPS and 750 Mbps, but it's significantly cheaper than any premium option. Use this for web servers, dev and test environments, or line-of-business apps that don't need sub-milly second response times. You get SSD speeds without the premium price tag, then there's standard HDD, a traditional spinning hard drive. It's the slowest option. Up to 2,000 IOPS and 500 Mbps, but it's also the cheapest. Use it for backups, archive storage, or any workload that doesn't need high input and output. If you're offering logs you access once a month, perfect, putting a database on it, you'll regret it. Both use consumption-based pricing. You pay for provisioned capacity. Each has a service level agreement. Standard HDD offers 95% uptime. Standard SSD offers 99.5%. Premium disks go up to 99.9%. Here's a simple rule of thumb. If your workload is latency-sensitive, meaning even a few milliseconds matter, go premium. If you just need cheap storage for things you rarely access, go standard HDD. If you're in the middle, standard SSD is the best all-rounder for budget-conscious production workloads. How do you know how many IOPS and how much throughput you need? That's coming up next. We'll break down how disk performance actually works. How disk performance works? IOPS, throughput, and latency. Let's talk about disk performance. Three numbers matter. IOPS, throughput, and latency. IOPS stands for input/output operations per second. It tells you how many small, read or write operations the disk can handle each second. This is what databases care about. When a database runs a query, it's doing lots of tiny random reads and writes. You need high IOPS for that kind of work. Thruput is different. It's measured in megabytes per second. How much data the disk can move in a given time? If you're streaming video, transferring large files, or doing any workload that reads or writes big chunks of data sequentially, you need high throughput. Then there's latency. That's the delay between sending a request and getting a response. Ultra disks give you under half a millisecond. Standard HDD can hit tens of milliseconds. That's a huge difference. Here's a detail that trips people up. With premium SSD V2 and ultra disks, you set IOPS and throughput independently. You decide exactly what you need and pay only for that. But with older premium SSD and standard disks, IOPS and throughput scale with disk size, bigger disk means more performance built in. Now a lot of people miss this. Some disks can burst. If you normally run at a lower performance level but need a short spike, say during a monthly report, the disk can temporarily deliver higher IOPS or throughput. It's built into certain disk sizes, no configuration needed. It just happens. But here's the most important thing. The VM itself has IOPS and throughput limits too. You can attach 10 ultra disks to a small VM but the VM can only push so much data. The disks will be waiting. So always check your VM size limits before adding disks. Don't attach more than the VM can handle. Performance is one thing, but durability is another. Let's see how Azure protects your data. Redundancy options. LRS, ZRS and what they mean for your data. Every managed disk lives on an Azure storage cluster, a group of servers inside a data center that work together to store your data. Azure automatically keeps three copies of your data in that same data center. We call that locally redundant storage, or LRS. It protects you against a single disk failure or a single server failure. Microsoft guarantees 99.99999% durability. Practically speaking, your data is not going to disappear. But what if the entire data center goes down? That's where zone redundant storage or ZRS comes in. And ZRS, as your keeps three copies of your data spread across different availability zones in the same region, each zone is a physically separate data center with its own power cooling and network. So if one zone fails, your data is still safe in the other two. That gives you 12 nines of durability. There's a catch. Ultra disks and premium SSDV2 only support LRS. The reason is latency. To replicate data across availability zones, you need to send it over fiber between data centers. That adds a few milliseconds of delay for ultra disks, which promise sub millisecond latency, that's a deal breaker. So choosing between LRS and ZRS comes down to cost versus availability. ZRS costs more, but it keeps you running even if an entire zone goes down. For most workloads, LRS is fine. For mission critical systems, ZRS is worth the extra cost. One more thing. There's no georedundancy for managed disks. Azure doesn't automatically replicate your disk data to another region. If you need disaster recovery across regions, say your primary region goes down and you want to spin up VMs in a secondary region, you have to handle that yourself. You can replicate snapshots to another region or use Azure backup to store copies in a recovery services vault. But it's not automatic. Now let's look at the roles disks play inside a virtual machine. OS disk, data disk, and temporary disk. What's the difference? Every virtual machine in Azure comes with at least one disk, the OS disk. That's where Windows or Linux lives. On Windows, it's the C drive. On Linux, it's our dev SDA. You can't remove it while the VM is running because it's the disk the machine boots from. But you can add more storage with data disks, attach them for applications, databases, files, anything you want separate from the operating system. Depending on your VM size, you can attach up to 64 data disks. That's a lot of storage. Then there's the temporary disk and this one trips people up. On Windows, it's usually the D drive. On Linux, it's flash dev such as DB1. Think of it like a whiteboard. Fast to write on, but everything wipes clean when the VM stops. The temporary disk lives on the host server itself, the physical machine running your VM, so it's incredibly fast because it's local. But it's not persistent. When you stop or redeploy your VM, everything on that temporary disk disappears as your uses it for swap files. You can use it for page files or SQL server temp DB, but never store anything important there. If your VM moves to a different host, that data is gone. There's also a special option called a femoral OS disks. Normally, your OS disk is a managed disk that persists. But for workloads like Azure Kubernetes service nodes or virtual machine scale sets, you're constantly creating and destroying VMs. You don't care about the OS state. So you can use an a femoral OS disk that lives on temporary storage instead. Fast to deploy cheaper because there's no managed disk charge. And when the VM goes away, the OS disk goes with it perfect for stateless workloads. Now how does Azure protect your managed disks? Let's talk security, security and encryption. Here's the good news. All managed disks are encrypted, addressed by default. Azure uses server-side encryption with platform managed keys. You don't have to turn it on or configure anything. Every new disk you create is automatically encrypted. It covers the basic requirement for most organizations. But what if you need more control? Maybe your compliance team wants you to manage your own encryption keys. In that case, you can use customer managed keys with Azure Key Vault. Create a disk encryption set, point it to a key in your vault and assign that set to your disks. Azure uses your key to encrypt and decrypt. You control rotation, you control access, revoke the key and the data becomes inaccessible. That's a lot of power, so be careful. For even stricter requirements, enable encryption at host. This adds another layer. It encrypts data as it travels between the VM host and the storage cluster. It also encrypts the temporary disk and any cached data. If you're running workloads with strict compliance standards like healthcare or finance, this is worth looking into. Then there's Azure disk encryption. This is different from the default server-side encryption. It uses Bitlocker on Windows and DM-crypt on Linux to encrypt the OS and data disks from inside the VM. It's an extra layer of protection. If someone somehow gets access to the underlying storage, they still can't read the data without the keys. And finally, network security. Private endpoints let you access managed disks from within your virtual network without exposing them to the internet. Traffic never leaves the Microsoft backbone. If you're serious about security, use private endpoints for your storage. Now, how do you protect your data from accidental deletion or corruption? Backups and snapshots, protecting your data. Let's talk about protecting your data. You have two main options here. Snapshots and Azure backup. Think of a snapshot as a read-only copy of a disk captured at a specific moment. The first snapshot grabs the entire disk, but every snapshot after that only stores the changes since the last one. That's what makes them fast and cheap. You take a snapshot before making a risky change to a VM, like installing a patch or updating an application. If something goes wrong, you just create a new disk from the snapshot and attach it, and your back where you started. Snapshots are also great for cloning disks or moving them to another region. But they do have limits. Snapshots aren't a full backup solution. You have to manage them yourself, remember to take them and clean up the old ones. And by default, they're not georedundant. They live in the same storage as the original disk, so if you need protection across regions, you have to copy them manually. That's where Azure backup steps in. It's a managed service. You set up a backup policy. How often and how long to keep backups. And Azure handles the rest. It automates the snapshot process, handles retention and stores everything in a recovery services vault. You can configure that vault to replicate to a secondary region. It even supports file-level restore, so you can recover individual files without restoring the whole disk. So here's the simple rule. Use snapshots for quick rollbacks before deployment or patch. Use Azure backup for long term protection and compliance. If you need to show an auditor backups going back three years, Azure backup gives you that. Snapshots alone won't. Now let's talk about money. How do you avoid overpaying for disks? Cost optimization tips. Here's a number that might surprise you. Use your bills you for the provision size of a disk, not the space you're actually using. So if you have a one terabyte disk with only a hundred gigabytes of data, you're paying for that full terabyte every single month. That's the single biggest waste in most environments. So step one is right sizing. Use premium SSD V2 or ultra disk when you need performance. They let you dial up IOPS without buying extra capacity you don't need. With the older premium SSD, if you wanted more IOPS, you had to buy a bigger disk. With V2, you just adjust the IOPS setting that alone can save a lot. You can use it to delete unattached disks. If you delete a VM but leave the disks behind, you're still paying for them. They sit there unused, generating charges. Use automation to fine and clean them up. Azure has tools for that. Use standard HDD for things that don't need speed. Backups, archives, logs you access once a quarter. Don't put those on premium disks. You're just burning money. If you have predictable workloads, look into reserved capacity. For blob storage, reservations can save up to 38% on the hot tier. Same idea applies to manage disks, commit to a certain amount of storage for one or three years and you get a discount. Here's another easy one. Reduce redundancy for non-critical data. LRS costs about half of what's the RIS costs. If your dev environment doesn't need zone level protection, use LRS and save that ZRS budget for production. Monitor your costs. Azure cost management shows you exactly what you're spending on disks. Set budgets, set alerts. If costs, spike, you'll know why. So now you have the big picture of Azure manage disks and how to protect and optimize them. So here's the big picture. Manage disks are Azure's answer to the old storage headache. Before them, you had to juggle storage accounts yourself. Now you just pick a size and a type and Azure handles everything behind the scenes. Think of it like choosing the right tool for the job. There are five disk flavors to pick from. Ultra disk for lightning speed. Premium SSD V2 for flexible high performance workloads. Premium SSD for your predictable enterprise apps. Standard SSD gives you the best balance of cost and speed. And standard HDD is your cheap slow option for low stakes data. Each one has its place. Now here's your task. Open the Azure portal and look at the disks attached to your VMs. Ask yourself one question. Am I using the right type and size? Chances are, you'll find at least one disk you can optimize. That's a win. If you want to go deeper, check out Azure disk encryption next. It shows how to secure those disks even further. And if this helped, subscribe on your favorite podcast platform. Share this knowledge nugget with someone starting their Azure journey.