Managed Disks in Azure
A complete, plain-English guide to Azure Managed Disks: the virtual hard drives behind every Azure virtual machine, how the different disk types perform, how they are sized, cached, encrypted, shared, protected and priced, and how to choose and operate them well.
Imagine a desk in an office. The desk itself is where you work, but everything you need sits inside its drawers: your documents, your tools, your notebooks. If the drawers are tiny and slow to open, your work suffers however good the desk is. If the drawers are huge and perfectly organised, you can find anything in seconds. A virtual machine in Azure is like that desk, and its disks are the drawers. Azure Managed Disks are drawers that Microsoft builds, locks, duplicates for safety and replaces when they wear out, so you only have to decide how big and how fast they should be.
This guide assumes you know nothing about the topic. Every new word is explained when it first appears, with an everyday comparison. By the end you will understand what disks are, how Azure stores and protects them, how the five disk types differ, how performance really works, how to size, cache, encrypt, share, back up and move disks, and how to control their cost.
1What a Disk Is and Why Computers Need One
Before Azure, we need to understand the simple idea underneath: a computer needs somewhere permanent to keep things.
Memory versus storage
A computer has two kinds of places to hold information. Memory, often called RAM, is very fast but forgetful: when the power goes off, everything in it vanishes. Storage is slower but permanent: files saved there are still present after a restart. The device that provides permanent storage is called a disk. The operating system, your programs and your data all live on disks when the computer is switched off.
Memory is the whiteboard on your desk: quick to write on and read, but wiped clean at the end of the day. A disk is the filing cabinet: slower to reach into, but your papers are still there tomorrow.
Block storage
Disks present themselves to the computer as block storage. A block is a fixed-size chunk of storage with an address, and the computer’s operating system reads and writes blocks directly, organising them into a file system with folders and files. To the operating system, a block disk looks like an empty hard drive that it formats and uses just like a physical one. This differs from file storage, which shares folders over a network, and from object storage, where items are fetched by name through web requests.
Physical disks and their problems
Physical disks wear out, fail without warning and have fixed sizes. A traditional server with its own disks risks losing everything if a disk or the whole machine dies. Companies protect against that with arrays of several disks, spare parts and regular backups, all of which cost time and money.
Disk
A device that stores data permanently so it survives power-off.
Block
A fixed-size chunk of storage that the operating system reads and writes directly.
File System
The organisation placed on a disk so that data appears as folders and files.
Volume
A formatted portion of storage that the operating system presents as a drive.
Provisioning
Reserving a chosen amount of storage or performance for your use.
A disk gives a computer permanent storage. In the cloud, that storage becomes a service: you request a size and a speed, and the provider supplies and protects it.
2Azure Managed Disks in Plain Words
Block storage volumes for Azure virtual machines, managed entirely by the platform.
The definition
An Azure managed disk is a virtual hard disk that Azure manages for you. You choose its type and size, attach it to a virtual machine, and Azure takes care of where it is physically stored, how many copies exist and how those copies are kept healthy. A virtual machine, often called a VM, is a software-defined computer running on Azure hardware, and nearly every VM needs at least one managed disk to hold its operating system.
What “managed” removes
In the early days of Azure, customers had to create storage accounts and place virtual hard disk files inside them, watching limits on how many disks one account could hold and spreading them out carefully. This was called unmanaged disk storage, and it created extra work and risk. Microsoft introduced managed disks to remove that burden, and unmanaged disks have been scheduled for retirement, so new designs should use managed disks only. Check Microsoft’s current announcements for exact dates.
| Concern | Old Unmanaged Approach | Managed Disks |
|---|---|---|
| Where data lives | In storage accounts you create and watch | Handled by Azure; you never see a storage account |
| Scaling limits | You track account limits and spread disks across accounts | Limits are per disk and per subscription, far simpler |
| Availability | You arrange spreading of disks across accounts | Azure places disks to suit availability sets and zones |
| Access control | Account-level keys | Role-based access control on each disk |
| Snapshots and images | Manual file copying | First-class resources with simple operations |
Unmanaged disks were like renting an empty warehouse and building your own shelving, labelling and security. Managed disks are like renting storage lockers from a company that handles the building, shelving and locks, so you only decide the locker size.
Key properties at a glance
A managed disk is not a physical disk and not a file inside a storage account you manage. It is an Azure resource in its own right, with its own name, size, type and permissions, which can exist even when no VM uses it.
3The Roles a Disk Can Play
A VM can have three kinds of storage, and confusing them is a classic source of lost data.
OS Disk
Holds the operating system. Every VM has exactly one, created from an image, and it persists as a managed disk.
Data Disk
Optional extra managed disks for applications, databases and files, kept separate so they can be resized, moved or protected on their own.
Temporary Disk
A scratch disk on the physical host for many VM sizes. It is fast but its contents can vanish when the VM moves or is redeployed, so it must never hold anything precious.
The OS disk
The OS disk contains the operating system and, by default, any software installed alongside it. It is created from an image, which is a template of a prepared disk. When the VM is deallocated or restarted, the OS disk persists. It has size and type choices, and its performance affects how quickly the machine boots and how responsive it feels.
Data disks
Data disks hold application data. A VM can have several, up to a limit set by its size. Separating data from the operating system is a good habit: you can rebuild or replace the OS disk without touching data, tune the performance of the data disk independently, snapshot it separately and move it to another VM when needed.
The temporary disk
Many VM sizes include a temporary disk that lives on the host server rather than in durable storage. It is useful for scratch files, caches and swap space, and it is fast and free of extra storage charge. But if the VM is redeployed, resized to another host or the host fails, its content is lost. Some VM sizes have no temporary disk at all.
flowchart TD
VM[Virtual Machine] --> OS[OS Managed Disk - persistent]
VM --> D1[Data Managed Disk 1 - persistent]
VM --> D2[Data Managed Disk 2 - persistent]
VM --> TMP[Temporary Disk - on host, not durable]
OS --> AZS[(Azure durable storage)]
D1 --> AZS
D2 --> AZS
The OS disk is the shelf holding your computer’s instruction manuals. Data disks are filing cabinets you can unplug and carry to another room. The temporary disk is a whiteboard: handy for quick notes, wiped whenever the cleaners come.
Placing database files, application data or important swap data on the temporary disk. When the VM is redeployed, that data is gone with no way to recover it. Persistent data belongs on managed data disks.
4How Azure Stores a Managed Disk Behind the Scenes
Understanding the hidden machinery explains durability, availability and some behaviours that seem odd.
Disks are network-attached
Unlike a disk plugged inside a physical server, an Azure managed disk lives in Azure’s storage system and is connected to the VM over a fast internal network. The VM issues read and write requests, they travel across the network to the storage service, and the response travels back. This design is what allows a disk to survive the death of the host server: the data was never on that server. The VM can simply be restarted on another host and reconnected to the same disk.
Keeping copies
The storage system stores several copies of each disk so that a failure of one drive or server does not lose data. How far apart those copies are kept depends on the redundancy option chosen for the disk.
| Redundancy | Where Copies Live | Protects Against | Notes |
|---|---|---|---|
| Locally redundant (LRS) | Three copies within one data centre | Drive and server failures | Available for all disk types; most common |
| Zone redundant (ZRS) | Copies across three availability zones in a region | Loss of an entire data centre in the region | Available for some disk types such as Premium SSD and Standard SSD, in supported regions |
Availability of zone-redundant storage depends on the disk type and region, so confirm in current documentation. Neither option protects against deletion or corruption caused by the VM itself, which is why snapshots and backup matter.
Zonal disks and VMs
In regions with availability zones, a VM can be placed in a specific zone, and its LRS disks are created in the same zone. A VM and its LRS disks must be in the same zone. Zone-redundant disks can be used with VMs in any of the zones, which helps recovery when a zone fails.
flowchart LR
VM[VM on host server] -->|storage network| ST[Azure Storage Service]
ST --> C1[Copy 1]
ST --> C2[Copy 2]
ST --> C3[Copy 3]
HF[Host fails] -.VM restarts elsewhere.-> VM2[VM on new host]
VM2 -->|reconnects to same disk| ST
A managed disk is like a safety deposit box in a bank vault, not a drawer inside your own desk. If your desk is destroyed, the box is still safe and you can reach it from a new desk. The bank keeps duplicate records in case a vault shelf fails.
Because disks are accessed over a network, their speed is limited both by the disk itself and by the VM’s own storage limits. Understanding both limits is the key to understanding performance, which we cover shortly.
5The Five Disk Types
Azure offers a ladder of disk types, trading price against speed and consistency.
Meet the family
Standard HDD
Lowest cost, based on spinning-disk technology, with variable performance. For backups, rarely used data and non-critical development.
Standard SSD
Solid-state storage with more consistent delay than HDD at modest cost. For web servers, light applications and test environments.
Premium SSD
High performance with low delay and fixed size-based performance tiers. The standard choice for production workloads.
Premium SSD v2
Capacity, IOPS and throughput are set independently, so you buy precisely the performance you need. For demanding production databases and flexible tuning.
Ultra Disk
The highest performance and lowest delay, adjustable while in use. For the most intense transactional workloads.
Comparing them side by side
| Type | Media | Performance Model | Typical Use |
|---|---|---|---|
| Standard HDD | Hard disk | Size-based, modest and variable | Backup, archive, infrequent access, dev and test |
| Standard SSD | Solid state | Size-based, consistent | Web servers, light databases, test environments |
| Premium SSD | Solid state | Size-based tiers with burst features | Production applications and databases |
| Premium SSD v2 | Solid state | Capacity, IOPS and throughput set separately | Databases and apps where tuning and cost precision matter |
| Ultra Disk | Solid state, top tier | Capacity, IOPS and throughput set separately and adjustable live | Largest transactional databases and latency-critical systems |
Standard HDD is a bicycle: cheap and fine for short, easy trips. Standard SSD is a motorbike. Premium SSD is a family car, dependable for daily work. Premium SSD v2 is a car whose engine, brakes and fuel tank you can tune separately. Ultra Disk is a racing car you adjust even while it is on the track.
Choosing a starting point
Development and test
Standard SSD usually gives a good balance, with Standard HDD only for very cost-sensitive or rarely used data.
General production workloads
Premium SSD is the common default for operating systems and application data where steady, low-delay performance is expected.
Performance-sensitive databases
Premium SSD v2 or Ultra Disk, chosen according to the required IOPS, throughput and delay, and to which VM sizes and regions support them.
Using Standard HDD for a production database because it looked cheap. Variable performance and higher delay can cause slow responses and unpredictable behaviour that cost far more in lost productivity than the saving.
6Understanding Disk Performance: IOPS, Throughput and Latency
Three measurements describe how fast a disk is. Knowing them turns guessing into engineering.
The three measurements
IOPS
Input and output operations per second: how many separate read or write requests can be served each second. Important for databases with many small operations.
Throughput
How many megabytes of data flow per second. Important for large sequential tasks such as backups, analytics and media processing.
Latency
The delay between a request and its first response. Important for anything where each operation waits for the previous one.
Think of a road. IOPS is how many cars pass a point per minute. Throughput is the total weight of cargo moved per minute: a few huge lorries move more than many tiny cars. Latency is how long a single car takes to start moving after the traffic light turns green.
Two ceilings, not one
Disk performance is limited at two places. The disk itself has IOPS and throughput limits according to its type and size, or according to what you provisioned. The VM also has its own limits on total storage IOPS and throughput across all its disks combined. Your achieved performance is the lower of the two. A very fast disk attached to a small VM will be held back by the VM’s limit, and a very large VM with a slow disk will be held back by the disk.
flowchart LR
APP[Application demand] --> VML[VM size storage limits]
VML --> DL[Disk limits]
DL --> RES[Actual performance = the lower ceiling]
Throttling
When demand exceeds either ceiling, Azure slows requests down rather than failing them. The visible symptom is rising latency and queues of waiting operations with no error messages. Teams often spend hours hunting application bugs before noticing that the disk or VM is throttled. Azure Monitor metrics show when a disk or VM is hitting its limits.
Striping for more performance
When one disk is not enough, several disks can be combined at the operating system level into a striped volume, spreading data across them so their performance adds up, up to the VM’s limit. This is a common technique for large databases, though it adds complexity: the combined volume is only as safe as the weakest disk, so striping improves speed, not protection.
Before choosing a disk, measure what the workload actually needs: peak IOPS, peak throughput and acceptable latency. Then check that both the disk and the VM size can deliver it. Guessing from capacity alone is the most common sizing error.
Upgrading to a faster disk type without checking the VM’s storage limits. The new disk’s speed is wasted if the VM caps total throughput below it.
7Sizes, Performance Tiers and Bursting
For Premium and Standard disks, size and performance are linked. Several features let you adjust that link.
Size tiers
Premium SSD, Standard SSD and Standard HDD are offered in fixed size steps, each with an identifying name such as P10 for a premium disk of a certain size, E10 for a standard SSD and S10 for a standard HDD. Each step has its own IOPS and throughput limits, and larger steps provide more performance. You pay by the step you choose, not by how full the disk is, so a mostly empty disk costs the same as a full one of the same step.
Performance tiers
Normally a small disk has small performance because performance rises with size. For Premium SSD, a feature called performance tiers lets you pick a higher performance level than the disk’s size would suggest without paying for extra capacity, and change it later. This helps with workloads that need short periods of higher speed, such as a monthly batch job, without permanently buying a larger disk.
Bursting
Bursting lets a disk temporarily exceed its normal limits to handle short spikes, such as a VM boot or a brief burst of activity.
Credit-based bursting
Smaller premium disks and some standard disks build up credits while idle and spend them during spikes. Once credits run out, the disk returns to its baseline. Free to use, suited to boot times and occasional peaks.
On-demand bursting
Larger premium disks can be configured to burst on demand beyond their baseline, for an extra charge when the burst is actually used. Suited to unpredictable spikes on large disks.
Credit-based bursting is a phone plan with rollover data: you save up during quiet months and spend it in a busy one. On-demand bursting is a pay-as-you-go top-up that you only pay for when you actually use it.
Independent performance on newer types
Premium SSD v2 and Ultra Disk drop the fixed steps entirely. You choose capacity, IOPS and throughput separately in fine increments, and pay for each. A small disk can have very high performance, and a huge disk can have modest performance, so you pay only for what the workload needs. Ultra Disk additionally lets you change performance while the disk is attached and running.
| Feature | Applies To | What It Does |
|---|---|---|
| Fixed size tiers | Standard HDD, Standard SSD, Premium SSD | Performance rises with the chosen size step |
| Performance tiers | Premium SSD | Raise performance without increasing size |
| Credit-based bursting | Smaller premium and standard disks | Temporary extra speed using accumulated credits |
| On-demand bursting | Larger premium disks that enable it | Paid extra speed during spikes |
| Independent IOPS and throughput | Premium SSD v2 and Ultra Disk | Pay separately for capacity, IOPS and throughput |
Specific size tiers, limits and prices are updated over time. Always check the current disk size and performance table in Microsoft’s documentation instead of relying on remembered numbers.
8Host Caching
A small, fast memory on the host can make some disks feel much faster, but it must be used with care.
What host caching is
Host caching keeps recently used disk data in memory or fast storage on the physical host running your VM. If the VM asks for the same data again, it can be answered from the cache without crossing the network to the disk. This reduces delay and can raise effective performance, particularly for reads.
The three settings
None
No caching. Every request goes to the disk. Typical for write-heavy data such as transaction logs.
Read-only
Reads may be served from cache; writes go straight to the disk. A safe, popular choice for database data files and read-heavy workloads.
Read/Write
Both reads and writes use the cache, which can improve speed but risks recent writes if the host fails before data reaches the disk. Common for OS disks, used carefully elsewhere.
VM requests data
The application reads a block from the disk.
Cache check
The host looks for that block in its cache first.
Hit or miss
On a hit the data returns immediately. On a miss the request travels to the disk and the result is stored in the cache for next time.
Rules and limits
Some disk types and very large disks do not support host caching. Ultra Disk and Premium SSD v2, for example, are used without it, and disks above a certain size cannot be cached. Caching is also limited by the VM size’s cache capacity. Always verify support for your disk type, size and VM series.
A cache is a notepad beside the phone where you jot down answers to questions you were just asked. If someone asks again, you read from the notepad instead of walking to the filing room. Useful for repeat questions, useless for brand new ones.
Enabling read/write caching on a database log disk. If the host fails, recently acknowledged writes held only in the cache may be lost, risking database corruption. Follow the database vendor’s guidance, which usually calls for no caching on log disks.
9Attaching, Detaching, Resizing and Moving Disks
Disks are independent resources, so they can be connected, disconnected and changed without recreating data.
Attaching and detaching
A data disk can be attached to a running VM, after which the operating system sees a new, unformatted device that must be initialised and formatted before use. A disk can also be detached and attached to another VM, which is a handy way to move data, recover a broken machine or inspect a disk. While attached to a VM, a standard disk is normally used by only that VM, unless it is a shared disk, which we discuss shortly.
Expanding
Disks can be made larger but not smaller. Expanding the disk in Azure enlarges the underlying volume, and then the operating system must be told to extend its partition and file system to use the new space. For many VM and disk combinations the expansion can be done without stopping the VM, though some require deallocation first, so check current support for your case. Shrinking requires creating a smaller disk and copying data across.
Changing the disk type
You can switch a disk from one type to another within the supported options, such as moving from Standard SSD to Premium SSD when a workload grows. This normally requires the VM to be deallocated, and the VM size must support the new disk type. Moving from a type to Ultra or Premium SSD v2 can be more restricted, and might require creating a new disk from a snapshot instead.
Snapshot first
Before any major change, take a snapshot so there is a safe point to return to.
Change in Azure
Resize the disk or change its type, deallocating the VM if required.
Adjust inside the OS
Extend the partition and file system so the operating system uses the extra space.
Verify
Check capacity, performance and application health, then clean up the snapshot when you are confident.
Moving across places
Between resource groups and subscriptions
Disks can be moved to different resource groups or subscriptions, which is useful for reorganising ownership and billing.
Between zones and regions
A disk cannot simply be dragged to another region. You create a snapshot, copy it to the target region and create a new disk there. Moving between zones in the same region works similarly through a snapshot.
Resizing a disk is like adding shelves to a cupboard: you can make it bigger, but you cannot make the wood shrink. If you want a smaller cupboard, you build a new one and move the contents.
Enlarging the disk in Azure and forgetting to extend the partition inside the operating system. Azure shows the new size, but the VM still sees only the old usable space until the volume is extended there too.
10Snapshots, Images and Restore Points
Copies of disks let you roll back mistakes, clone machines and build repeatable templates.
Snapshots
A snapshot is a read-only copy of a managed disk at a particular moment. Snapshots are often used before risky changes, such as software upgrades, so that you can return the disk to its earlier state if something goes wrong. Azure can create incremental snapshots, which store only the changes since the previous snapshot, making them much cheaper and faster than repeated full copies. A full snapshot stores everything.
Images
An image is a template made from a VM or disk, used to create many identical VMs. Images can be stored in a shared image gallery, which keeps versions, replicates them across regions and shares them across teams. Using prepared images ensures every new VM begins with the same tested software and settings.
Restore points
VM restore points capture the configuration of a VM together with point-in-time copies of all its attached disks, giving a consistent set from which the whole VM can be restored. They are useful when several disks must stay in step, such as a database whose data and log disks must be recovered together.
| Item | What It Is | Typical Use |
|---|---|---|
| Snapshot | Point-in-time read-only copy of one disk | Safety before changes, disk cloning, copying to other regions |
| Incremental snapshot | Snapshot storing only changes since the last one | Frequent, cheaper protection and cross-region copies |
| Image | Template for creating new VMs | Standard builds and scaling out fleets |
| Restore point | Consistent copy of VM configuration and all its disks | Recovering a whole multi-disk VM |
flowchart TD
D[Managed Disk] --> S1[Snapshot 1 full]
D --> S2[Snapshot 2 incremental]
D --> S3[Snapshot 3 incremental]
S3 --> ND[Create new disk]
S1 --> IMG[Image Version in Gallery]
IMG --> VM1[New VM]
IMG --> VM2[New VM]
S2 -.copy.-> R2[Snapshot in another region]
A snapshot is a photograph of your desk taken before you tidy up. If you throw away something important, you can look at the photograph and rebuild the desk exactly as it was. An image is a photograph used as instructions to arrange many identical desks.
A snapshot of a running disk is crash-consistent, like the state after sudden power loss, not necessarily consistent for applications such as databases. For application-consistent protection, use backup tools that coordinate with the operating system and applications.
Keeping snapshots forever. They are billed for the data they hold, and old forgotten snapshots quietly accumulate cost. Set retention rules and delete snapshots once they are no longer useful.
11Backup and Disaster Recovery for Disks
Redundancy protects against hardware failure. Backup and recovery protect against everything else.
Why redundancy is not backup
The multiple copies Azure keeps are designed to survive hardware failure. If someone deletes a file, ransomware encrypts a volume, or a faulty update corrupts data, every copy is deleted, encrypted or corrupted too. Backup keeps older, separate points in time that you can return to.
Key terms
Azure tools
Azure Backup for VMs and disks
Takes scheduled, policy-driven backups of VMs and their disks into a protected vault, with retention from days to years and options to restore a whole VM, individual disks or files. It also supports backup of individual managed disks using incremental snapshots.
Azure Site Recovery
Continuously replicates VMs and their disks to another region so that, if a region fails, you can fail over and run from the replica.
Zone-redundant disks
Where supported, they let a disk survive the loss of a zone and allow restart of a VM in another zone.
Snapshots copied across regions
A lightweight, manually orchestrated approach to keep a copy of important disks in a second region.
| Threat | Best Protection |
|---|---|
| Drive or server failure | Built-in redundancy (LRS or ZRS) |
| Data centre loss in a region | Zone-redundant disks and VMs spread across zones |
| Whole region disaster | Site Recovery or cross-region copies |
| Accidental deletion or bad change | Snapshots and Azure Backup |
| Ransomware or malicious deletion | Backup in a separate protected vault with soft delete and restricted access |
Never testing restores. Schedule regular recovery drills, measure how long they actually take and compare the results with your recovery targets.
12Encryption and Data Protection
Encryption turns stored data into unreadable text for anyone without the key. Azure offers several layers.
Server-side encryption by default
All managed disks are encrypted at rest by default using strong encryption applied by the storage service. This happens automatically with keys managed by Microsoft. No setup is needed, and there is no performance penalty noticeable to users.
Customer-managed keys
Organisations that must control their own encryption keys can use customer-managed keys stored in Azure Key Vault or a managed hardware security module. A resource called a disk encryption set links your disks to your key. You can rotate the key, restrict who may use it and revoke it, which would make the disks unreadable. With that control comes responsibility: losing or wrongly deleting the key can make data permanently unrecoverable, so protect and back up keys with care.
Encryption at host
Encryption at host extends encryption to the temporary disk and to disk caches on the physical host, and encrypts data flowing from the host to the storage service. This closes the gap where, with ordinary server-side encryption alone, some data on the host is not encrypted in the same way. It is often recommended for sensitive workloads and can be combined with customer-managed keys.
Azure Disk Encryption
Azure Disk Encryption uses tools inside the operating system, BitLocker on Windows and a Linux disk-encryption facility on Linux, to encrypt volumes with keys kept in Key Vault. It encrypts at the guest operating system level and is an older alternative to the options above, with certain limitations. Microsoft’s current guidance generally points new designs toward encryption at host and server-side encryption where they meet requirements, so check current recommendations.
Confidential disk encryption
For confidential VMs, confidential disk encryption can bind the OS disk’s encryption to the VM’s own trusted platform module, so the keys are released only to the VM itself, protecting data even from the cloud operator.
| Option | Where It Works | Who Manages Keys | Notes |
|---|---|---|---|
| Server-side encryption, platform keys | Storage service | Microsoft | Default, always on |
| Server-side encryption, customer keys | Storage service | You, via Key Vault or hardware security module | Needs disk encryption set and key care |
| Encryption at host | Host, covering temp disk and caches | Platform or customer keys | Needs VM size and region support |
| Azure Disk Encryption | Inside the guest operating system | You, via Key Vault | Guest-level; some limitations |
| Confidential disk encryption | Confidential VMs | Tied to VM’s secure hardware | For the strictest confidentiality needs |
Default encryption is a warehouse that locks all its shelves automatically. Customer-managed keys mean you hold the only key to your shelf. Encryption at host also locks the loading dock where goods wait before being moved in. Confidential encryption seals the goods in a box that even the warehouse staff cannot open.
Use customer-managed keys only when a requirement exists. Platform-managed encryption is strong and carries less operational risk. If you do adopt your own keys, turn on key vault protection features such as soft delete and purge protection, and plan rotation.
13Access Control, Network Exposure and Governance
A disk holds everything, so controlling who can touch it, copy it or export it is vital.
Role-based access control
Each managed disk is an Azure resource, so access can be controlled with role-based access control. You can grant someone permission to read a disk, to create snapshots, or to manage it fully, and you should assign these to groups and apply least privilege, meaning only the access really needed. Permission to create or delete disks and snapshots should be limited, since a disk copy is a copy of all the data on it.
Exporting and sharing disks
Disks and snapshots can be exported by generating a time-limited shared access signature, a web address that grants temporary read access to the data. This is useful for copying disks between environments, but it also creates a way for data to leave Azure. Azure provides settings to control whether disks and snapshots can be reached through public network access, and options for private access through private endpoints so that exports and imports stay on private routes.
Public Network Access Setting
Disable public access to disk export and import so that data can be moved only through private routes.
Private Endpoints
Use private links so disk upload and download happen inside your virtual network.
Data Access Authentication
Require identity-based sign-in for disk data operations instead of relying on bare shared links where supported.
Resource Locks
Prevent accidental deletion of critical disks and snapshots.
Azure Policy
Enforce rules such as mandatory encryption, allowed disk types and required tags across a subscription.
Governance with tags and policy
Tagging every disk with owner, project and environment makes cost attribution and cleanup possible. Policy can require encryption with customer keys for certain workloads, block disks with public access enabled and audit unattached disks. Together these controls keep many teams working safely in a shared environment.
Problem
Wide permissions to create snapshots and generate export links are granted to many people, and public network access for disks is left enabled.
Why It’s Harmful
A snapshot and export link is a complete copy of a disk’s data. Anyone with those permissions could take sensitive data out of the environment, deliberately or through a leaked link, bypassing application-level controls.
Correct Approach
Restrict snapshot and export permissions to a small trusted group, disable public network access for disks, use private endpoints where exports are needed, and monitor activity logs for exports.
14Shared Disks and Clustering
Normally one disk belongs to one VM. Shared disks let several VMs attach to the same disk at once.
The idea
A shared disk, sometimes described as multi-attach, can be attached to more than one VM simultaneously. This supports clustered applications such as failover clusters, where several machines need access to the same storage so that if one fails, another can take over quickly with the same data. Azure supports shared disks on certain disk types, including Premium SSD, Ultra Disk and some Standard SSD configurations, with limits on how many VMs may attach.
What a shared disk does and does not do
The platform lets several VMs attach to the same disk. It does not coordinate who may write what and when. That coordination must be provided by cluster software running inside the VMs, using a mechanism called persistent reservations, which lets cluster members declare who currently owns access. Without proper cluster software, several machines writing to the same disk will corrupt the data.
flowchart TD
VMA[Cluster Node A active] --> SD[(Shared Managed Disk)]
VMB[Cluster Node B standby] --> SD
CS[Cluster software with persistent reservations] -.coordinates.-> VMA
CS -.coordinates.-> VMB
VMA -->|fails| FO[Node B takes over disk ownership]
A shared disk is a single whiteboard in a room with two teachers. If they have agreed rules about who writes when, it works beautifully. If both write at once without agreement, the board becomes unreadable.
Typical use
Failover cluster instances
Clustered databases and file services that rely on shared storage for quick takeover.
Legacy clustered applications
Older enterprise software built around the idea of shared storage can be moved to Azure with its cluster design intact.
Shared disks are not a general-purpose way to share files between VMs. For shared folders accessible by many machines, a file share service is the right tool. Shared disks exist for cluster software that is designed to manage them.
15Ephemeral OS Disks
Sometimes a VM does not need a durable operating system disk at all.
What they are
An ephemeral OS disk is an operating system disk stored on the local storage of the host, on the VM cache or the temporary disk, rather than in durable managed storage. Because it is local, it is very fast, has very low delay and incurs no separate storage charge for the OS disk. The trade-off is that its contents are not preserved if the VM is redeployed, moved, or deallocated; it is reset to the original image state.
Where they fit
Stateless workloads
Web servers, application servers and workers that keep no important data locally and can be rebuilt from an image at any time.
Scale sets and fleets
Large groups of identical machines that are created and removed automatically, benefiting from fast creation and reimaging.
Container and batch nodes
Nodes in container clusters and batch pools, where machines are disposable by design.
| Aspect | Managed OS Disk | Ephemeral OS Disk |
|---|---|---|
| Location | Durable Azure storage | Local host storage |
| Survives redeploy or host move | Yes | No; reset to image |
| Speed and delay | Network-attached | Local, usually faster |
| Storage charge for OS disk | Yes | No separate disk charge |
| Snapshots and backup of the OS disk | Supported | Not supported |
| Best for | Stateful or long-lived machines | Stateless, disposable machines |
A managed OS disk is your personal notebook, kept safe in a locker. An ephemeral OS disk is a fresh disposable worksheet handed out at the start of each class and thrown away afterwards. Perfect if nothing on it matters; disastrous if you wrote something valuable on it.
Choosing ephemeral OS disks for a machine whose operating system holds configuration or data that cannot be recreated from an image. Make sure every setting is applied automatically at start-up before relying on this option.
16Pricing and Cost Optimisation
Disk costs are easy to ignore and surprisingly large across many machines. Exact prices change and vary by region, so always check the current Azure pricing pages.
What you pay for
Provisioned Size
For most disk types, you pay for the size step you chose, whether or not the disk is full.
Performance
For Premium SSD v2 and Ultra Disk, extra charges apply for provisioned IOPS and throughput, and for performance tiers and on-demand bursting where used.
Transactions
Standard HDD and Standard SSD may include charges for the number of storage operations performed.
Snapshots
Charged for the data they hold, with incremental snapshots usually far cheaper than full copies.
Redundancy
Zone-redundant disks cost more than locally redundant ones.
Data Transfer
Copying disks or snapshots across regions incurs transfer charges.
Disks bill even when VMs do not
When a VM is deallocated, its compute charge stops, but its disks continue to bill because the data is still stored. A disk left behind after a VM is deleted, called an unattached or orphaned disk, also keeps billing until it is deleted. Many organisations discover hundreds of forgotten disks quietly costing money every month.
Optimisation habits
Right-size
Choose the smallest size and type that meets measured needs, and revisit as usage changes.
Use the cheapest suitable type
Keep production on Premium or higher where required, and place development and archive data on standard types.
Use performance features
Prefer performance tiers or independent performance settings over buying capacity just for speed.
Hunt orphaned disks and old snapshots
Regularly list unattached disks and aged snapshots and delete what is no longer needed.
Consider reservations
For steady Premium SSD capacity, reserved capacity for one year at certain sizes can reduce cost compared with pay-as-you-go, where offered.
Tag and alert
Tag disks with owners, set budgets and review cost reports to catch surprises early.
Deleting a VM and assuming everything related is gone. Disks, snapshots, public addresses and network cards may remain and keep billing. Delete the resource group, or choose to remove associated resources during deletion.
17Monitoring and Troubleshooting Disks
Slow disks cause slow applications. Good monitoring tells you quickly whether the disk, the VM or the application is to blame.
What to watch
IOPS and throughput
Compare achieved values with the disk’s and the VM’s limits to see how close you are to throttling.
Latency and queue depth
Rising delay and growing queues of waiting operations suggest the disk cannot keep up with demand.
Throttling indicators
Azure Monitor provides metrics showing the percentage of disk and VM limits consumed, and metrics reporting when requests were throttled.
Free space inside the file system
Platform metrics cannot see how full the file system is. A monitoring agent inside the VM is needed to alert before the disk fills.
Burst credits
For bursting disks, watch how many credits remain, since exhausting them drops performance to baseline.
A troubleshooting routine
Confirm the symptom
Is the application slow, are there long waits for storage, or are there errors? Measure rather than guess.
Check disk and VM limits
Look at percentage-of-limit metrics for both the disk and the VM to find which is saturated.
Check caching and layout
Verify host caching settings suit the workload and whether data and logs share a single disk unnecessarily.
Look inside the operating system
Examine file system fullness, fragmentation, antivirus scanning and background tasks that may generate heavy input and output.
Fix the right layer
Raise disk performance, change VM size, spread data across disks, adjust caching or tune the application, depending on what the evidence shows.
Set alerts at around eighty percent of disk and VM limits and at low free space in the file system. Early warnings give time to scale up before users feel the slowdown or the disk fills completely.
18Managed Disks Compared with Neighbouring Storage Options
Azure has several storage services. Choosing among them prevents mismatched designs.
| Option | Type of Storage | Best For | Key Point |
|---|---|---|---|
| Managed Disks | Block storage for VMs | Operating systems and databases on VMs | Low delay, normally one VM per disk unless shared |
| Azure Files | Managed network file shares | Shared folders accessed by many machines | Mounted over SMB or NFS; shared by design |
| Blob Storage | Object storage | Images, video, backups and data lakes | Accessed by web requests, very scalable, cost effective |
| Azure NetApp Files | High-performance managed file service | Demanding enterprise file workloads | Rich data management at higher cost |
| Azure Elastic SAN | Cloud storage area network | Consolidating block storage for many workloads with pooled performance | Pooled capacity and performance across volumes |
| Local temporary disk | Host-local scratch storage | Caches and temporary files | Fast but not durable |
Managed disks are drawers built into one desk. Azure Files is a shared cabinet in the corridor. Blob storage is a huge warehouse with catalogue numbers. Elastic SAN is a large pool of drawers that many desks draw from. The temporary disk is a whiteboard.
Rules of thumb
Start with managed disks for VM storage
They are the standard, simplest answer for operating systems and data attached to a single VM.
Use a file service for sharing folders
When many machines or users need the same folders, a file share is the natural tool, not a shared disk.
Use object storage for big unstructured data
Media, logs, backups and analytics data are usually cheaper and easier to scale in blob storage than on disks.
Consider Elastic SAN for large consolidated estates
Where many workloads need block storage with shared, pooled performance and simpler management at scale, it can be worth evaluating.
19Advantages, Limitations and Trade-offs
An honest view of both sides leads to better decisions.
Advantages
- Fully managed durable storage: no storage accounts or hardware to look after.
- Five disk types covering budget needs through to extreme performance.
- Disks survive host failure because data is stored separately from the host.
- Rich protection tools: snapshots, restore points, backup and replication.
- Strong encryption by default with options for customer keys and host-level protection.
- Flexible operations: attach, detach, expand, change type and share on supported disks.
Disadvantages / Trade-offs
- Disks bill for provisioned size, so unused capacity and orphaned disks waste money.
- Performance is capped by both disk and VM limits, which makes sizing subtle.
- Disks can grow but not shrink, and some changes require downtime.
- Network-attached storage has higher latency than local disks for some workloads.
- Zonal and regional placement rules complicate moving disks and designing resilience.
- Advanced types and features have restrictions on regions, VM sizes and combinations.
When managed disks are the right tool
Choose managed disks whenever a VM needs durable, block-level storage for its operating system, databases or application data, and whenever you want snapshots, backup and encryption integrated with the VM platform.
When another option fits better
Choose file shares when many machines need the same folders. Choose blob storage for large unstructured data and web-delivered content. Choose ephemeral OS disks for stateless, disposable machines. Choose Elastic SAN when you want pooled block performance across many workloads.
20Real-World Scenarios
Patterns become clearer when you see them applied. These are typical industry uses, described generally.
Transactional database for a retailer
A retailer runs its order database on a memory-optimised VM. Data files sit on Premium SSD v2 disks with read-only caching where supported by the design, while transaction logs use a separate disk with no caching. Disks are striped for throughput, encrypted at host, and snapshots plus backup protect against mistakes.
Web fleet with disposable machines
A media company runs hundreds of stateless web servers in a scale set using ephemeral OS disks. Machines start fast from a golden image, and any data lives in external services. Replacing a machine is routine.
Clustered enterprise application
A manufacturer migrating a failover-cluster application uses shared Premium SSD disks across two nodes in different fault domains, with cluster software managing reservations, and Site Recovery replicating the cluster to a second region.
Latency-critical financial platform
A trading platform places its busiest database on Ultra Disk, tunes IOPS and throughput live during market hours, and reduces them overnight to save cost.
Development and test environments
A software team keeps test VMs on Standard SSD, deallocates them outside working hours and uses snapshots to reset environments quickly after each test cycle.
Disk cleanup that saved real money
An operations team ran a monthly report of unattached disks and snapshots older than ninety days. Deleting forgotten resources reduced the storage bill noticeably with no impact on any application.
21A Reference Design for a Database VM
Let us combine the ideas into one sensible disk layout for an important database server.
Imagine a production database VM that needs fast data access, fast and safe transaction logging, protection against failures and mistakes, and controlled cost. The design below shows how the pieces fit.
flowchart TD
VM[Database VM in availability zone] --> OS[OS Disk Premium SSD read/write cache]
VM --> DATA[Data Disks Premium SSD v2 striped read-only cache where supported]
VM --> LOG[Log Disk no caching]
VM --> TMP[Temp Disk for tempdb or scratch only]
DATA --> ENC[Encryption at host with customer key]
LOG --> ENC
OS --> ENC
DATA --> SNAP[Incremental snapshots on schedule]
LOG --> SNAP
SNAP --> BKP[Azure Backup vault with soft delete]
VM --> ASR[Site Recovery to second region]
MON[Azure Monitor with disk and VM limit alerts] -.watches.-> VM
Walking through the design
Separate disks by role
Operating system, data files and transaction logs each get their own disk, so each can have the right type, size and caching setting.
Size to measured demand
Disk IOPS and throughput are chosen from measured peaks, and the VM size is checked to ensure its own limits are higher than the combined disk demand.
Encrypt end to end
Encryption at host with a customer-managed key covers disks, temporary storage and caches, with key vault protection enabled.
Layer the protection
Scheduled incremental snapshots handle quick rollbacks, Azure Backup holds long-term copies in a separate vault, and Site Recovery covers regional disaster.
Watch and govern
Alerts fire at eighty percent of disk and VM limits and on low free space, tags identify owners, and policy blocks unencrypted or publicly exposed disks.
Why this works
Each risk has a specific answer. Slowness is addressed by measured sizing and appropriate caching, hardware failure by built-in redundancy, human error by snapshots and backup, regional disaster by replication, data exposure by encryption and access controls, and cost by right-sizing and cleanup routines.
22Best Practices and Common Mistakes
Habits that separate smooth storage estates from slow, risky and expensive ones.
Measure before sizing
Base disk type and size on actual IOPS, throughput and latency needs, and check VM limits too.
Separate data from the OS
Put application data and logs on their own disks for tuning, protection and portability.
Use zones where it matters
Match VM and disk zones and consider zone-redundant disks for production resilience.
Layer protection
Combine redundancy, snapshots, backup and replication, and test restores.
Encrypt thoughtfully
Use encryption at host for sensitive workloads and customer keys only where required.
Restrict export and copy rights
Limit who can create snapshots and export disks, and disable unnecessary public access.
Monitor limits and space
Alert on throttling, burst credits, latency and free space inside the file system.
Clean up regularly
Remove orphaned disks and old snapshots, tag everything and review costs.
Common mistakes at a glance
| Mistake | Consequence | Better Habit |
|---|---|---|
| Data on the temporary disk | Data lost on redeploy or host move | Use managed data disks for anything persistent |
| Fast disk on a small VM | Performance held back by VM limits | Check VM storage limits against disk needs |
| Read/write cache on log disks | Risk of lost writes or corruption | No caching on log disks per vendor advice |
| Forgetting to extend the volume after resizing | No extra usable space | Extend partition and file system inside the OS |
| Treating redundancy as backup | Mistakes and attacks replicate | Snapshots and separate backup |
| Leaving orphaned disks and snapshots | Silent ongoing cost | Regular cleanup reports and tags |
| Wide snapshot and export permissions | Easy data exfiltration | Least privilege and private access only |
Problem
Every VM gets the largest Premium SSD available “to be safe”, regardless of what the workload needs.
Why It’s Harmful
Disk cost is paid on provisioned size, so most of the spend buys capacity and performance that are never used. Across hundreds of machines, the waste is substantial and nobody notices.
Correct Approach
Measure real demand, choose the smallest suitable size and type, use performance tiers or independent performance settings for spikes, and review utilisation regularly.
Problem
A single huge disk holds the operating system, database data, logs and backups together.
Why It’s Harmful
Different data needs different performance, caching and protection. One disk forces compromises, causes contention between logs and data, makes tuning impossible, and means one problem affects everything.
Correct Approach
Split by role: separate OS, data, log and backup storage, each with the type, size, caching and protection that suits it.
23Frequently Asked Questions
With managed disks, Azure handles the underlying storage and you simply choose type and size. Unmanaged disks required you to create and manage storage accounts yourself, and they have been scheduled for retirement. Use managed disks for all new work.
Standard HDD for archives and rarely used data, Standard SSD for light and test workloads, Premium SSD for most production, Premium SSD v2 for flexible high performance, and Ultra Disk for the most demanding, latency-critical systems. Measure first and check current supported combinations.
The VM size has its own storage limits, so achieved performance is capped by the lower of the disk limit and the VM limit. Caching settings, throttling and application behaviour may also be factors.
No. Disks can be made larger but not smaller. To use a smaller disk, create a new one and copy the data across.
Yes. Disks keep billing as long as they exist, even if the VM is deallocated. Only deleting the disk stops its charge.
Managed disk data is stored separately from the host, so the VM can restart on another host and reconnect to the same disk. Data on the temporary disk or an ephemeral OS disk is lost.
No. Redundancy guards against hardware failure only. Deletion, corruption and ransomware affect all copies, so use snapshots and a separate backup.
Yes, by default with platform-managed keys. You can add customer-managed keys, encryption at host and other options depending on your requirements.
A snapshot is a point-in-time copy of one disk, mainly for rollback and copying. An image is a template used to create many VMs with the same software and settings.
Read-only caching suits read-heavy data such as database data files, and read/write caching is common on OS disks. Use no caching for write-heavy log disks. Some disk types and sizes do not support caching.
Only with shared disks, available on certain disk types, and only safely with cluster software that coordinates access. Ordinary sharing of folders should use a file share service instead.
OS disks stored on the host’s local storage, offering speed and no separate disk charge but losing their contents if the VM moves or is deallocated. They suit stateless, disposable machines.
Not directly. Create a snapshot, copy it to the target region and create a new disk from it there.
Right-size, use the cheapest suitable type, delete orphaned disks and old snapshots, use performance features instead of extra capacity, consider reservations for steady capacity, and tag and monitor costs.
Azure Monitor metrics show the percentage of disk and VM limits used and report throttled operations. Rising latency with no errors is a typical symptom.
Consider Elastic SAN to pool block storage performance across many workloads. Use a file service when many machines need the same folders. Use blob storage for large unstructured data.
24Summary and Key Takeaways
Azure Managed Disks are the durable, network-attached block storage behind virtual machines. Azure keeps multiple copies of each disk, separate from the host server, so a VM can restart elsewhere and find its data intact. Five disk types, from Standard HDD to Ultra Disk, let you balance cost against performance, while sizing, performance tiers, bursting, caching and striping give further control. Snapshots, restore points, Azure Backup and Site Recovery protect against human error, attack and disaster, and layered encryption and access controls protect against exposure. Because performance is capped by both the disk and the VM, and because costs accrue on provisioned size whether or not a disk is full, the discipline that matters most is measuring real needs, separating data by role and cleaning up what you no longer use.
Key Takeaways
- A managed disk is a durable, independent Azure resource — it holds a VM’s operating system or data, is stored separately from the host and survives host failure.
- Know the three roles — OS disk, data disks and the non-durable temporary disk; never keep important data on the temporary disk.
- Choose among five types by measured need — Standard HDD, Standard SSD, Premium SSD, Premium SSD v2 and Ultra Disk trade cost against IOPS, throughput and latency.
- Performance has two ceilings — the disk and the VM both cap speed, so check both and watch for throttling, using caching and striping appropriately.
- Redundancy is not backup — combine zone-aware design, incremental snapshots, Azure Backup and Site Recovery, and test restores.
- Encrypt and restrict — rely on default encryption, add encryption at host or customer keys where required, and limit who can snapshot, export and copy disks.
- Control cost deliberately — disks bill on provisioned size even when idle, so right-size, remove orphaned disks and old snapshots, and use performance features instead of oversized capacity.