Azure disk storage is the permanent, block-level storage that virtual machines use to keep their data.

Let us start with the basic words. Azure is Microsoft’s cloud platform, a giant collection of computers in buildings called data centers, which you can rent by the hour instead of buying your own. A virtual machine, often shortened to VM, is a computer that exists as software on one of those big computers. You can start it, stop it, and resize it whenever you like.

A disk is a place where a computer saves information so that the information is still there after the computer is switched off. In your laptop, the disk is a physical part inside the case. In Azure, the disk is a virtual disk: Microsoft stores the data across many physical drives in its data centers and shows it to your VM as if it were one ordinary drive. This service is officially called Azure Disk Storage, and the disks themselves are called Azure managed disks.

Azure disks are block storage. Block storage splits data into equal-sized pieces called blocks and gives each piece an address, much like numbered boxes in a warehouse. The operating system of your VM puts a file system on top of those blocks, and from then on you see folders and files like you would on any computer. This is different from object storage (such as Azure Blob Storage) where you save whole files through a web address, and from file storage (such as Azure Files) where many computers share folders over a network.

Every Azure VM can use up to three kinds of disk, and each one has a different job.

When you create a VM, Azure quietly attaches at least one disk. Understanding the three roles will save you from many beginner mistakes, so let us look at them one at a time.

The OS disk

The OS disk is where the computer’s brain lives. When the VM boots, it reads the operating system from this disk. Because it is so important, many teams keep the OS disk small and clean, and they never store business data on it. If you ever need to replace the operating system, a clean OS disk makes that job easy.

The data disks

Data disks are extra drives that you attach to the VM. A database server might have one data disk for its main files and another for its logs. Keeping them separate lets you give each disk the performance it needs and protect each in the way that suits it. You can add more data disks later without rebuilding the VM, which is one of the great advantages of the cloud.

The temporary disk

Many VM sizes also include a temporary disk. It sits on the same physical machine as your VM, so it is very fast and, for most sizes, costs nothing extra. The catch is in its name: it is temporary. If the VM is redeployed, resized, or moved because of maintenance, the data on it is lost. Use it only for things you can easily recreate, such as caches or swap files. Some VM sizes have no temporary disk at all.

Managed disks remove the need to look after storage accounts yourself.

In the early days of Azure, a virtual disk was a file saved inside a storage account that you created and watched over yourself. You had to worry about how many disks you put in one account, because the account had performance limits that all its disks shared. If you packed too many in, they slowed each other down. These older disks are called unmanaged disks, and Microsoft has retired them in favor of managed disks.

With managed disks, you only say what kind of disk you want and how big it should be. Azure chooses where to place it, spreads the load, and keeps it healthy. You are never asked to create or count storage accounts for disks. The disk becomes a normal Azure resource, like a VM or a network, which you can tag, secure with permissions, and manage with the same tools you use for everything else.

What managed disks give you

Azure offers five disk types so that you can match speed and price to your real needs.

Not every job needs the fastest storage. A website that stores a few pictures does not need the same disk as a bank’s transaction database. Azure therefore sells five types, arranged from the most powerful at the top to the most economical at the bottom.

Three numbers describe a disk’s speed: IOPS, throughput and latency.

Before comparing disks, you need to read the numbers on the price list. Beginners often see these words and feel lost, but each one has a simple meaning.

Two limits at once

A disk has its own limits, and so does the VM it is attached to. Each VM size can only push a certain amount of IOPS and throughput to all its disks combined. If you buy a very fast disk but attach it to a small VM, the VM becomes the bottleneck and you waste money. Always check both numbers together.

These two disk types let you tune performance separately from size.

With older disk types, performance came attached to size. If you wanted more speed, you had to buy a bigger disk, even if you did not need the space. Ultra Disk and Premium SSD v2 break that link. You decide the size, the IOPS and the throughput on their own, like choosing the engine and the fuel tank of a car separately.

Ultra Disk

Ultra Disk is the top of the range. It can be as large as 64 TiB (a tebibyte is a little more than a terabyte), and it can reach hundreds of thousands of IOPS and many thousands of MB/s on a single disk, with delay measured in fractions of a millisecond. You can change its speed settings while the VM keeps running. It suits workloads such as large transaction databases, where every millisecond counts. Ultra Disk cannot be used as an OS disk and does not support host caching.

Premium SSD v2

Premium SSD v2 sits just below. Every disk comes with a free baseline of 3,000 IOPS and 125 MB/s, no matter how small it is. If you need more, you raise IOPS and throughput in small steps and pay only for the extra. It can grow to 64 TiB and reach tens of thousands of IOPS. Like Ultra Disk, it is for data disks only and does not support host caching. For many database and application workloads, it offers the best balance of power and price.

These three types come in fixed size steps, and performance grows with the size you pick.

Premium SSD

Premium SSD is the classic production disk. Sizes come in named steps starting with P1 for a few gigabytes and rising through P10, P20, P30 and so on, up to P80 at roughly 32 TiB. Each step has a fixed number of IOPS and throughput, topping out at around 20,000 IOPS and 900 MB/s per disk. Premium SSD is also the type you will most often use for OS disks of important servers. It is the safe, familiar option when you want steady performance without much tuning.

Standard SSD

Standard SSD is made for workloads that need dependable but modest speed. Its sizes follow a similar ladder, named E1 to E80, with limits of up to about 6,000 IOPS and 750 MB/s. Think of web servers, small business applications and development or test machines. It costs less than Premium SSD and is far more consistent than a hard drive.

Standard HDD

Standard HDD uses spinning drives and is named S4 to S80. Its limits reach about 2,000 IOPS and 500 MB/s. Its low price makes it good for backups, archives and data that is read only occasionally. It is not a good home for an application that users wait on, because the delay between requests can vary.

Two features can make a disk feel faster without changing its type.

Bursting

Most servers are not busy all the time. They have quiet periods and short, sudden rushes, such as a computer starting up in the morning. Bursting lets a disk temporarily go faster than its normal limit during those rushes. There are two styles. Credit-based bursting works like a savings account: the disk saves unused speed while it is quiet and spends it during a spike, for a limited time. On-demand bursting is a paid option for larger Premium SSD disks that lets them exceed their normal limits whenever required, and you pay for the extra use.

Host caching

The physical computer that runs your VM, called the host, has its own memory and local drives. Host caching uses part of that fast local space to remember data recently read from or written to a disk. If your application asks for the same data again, it can be served from the nearby cache instead of travelling to the remote disk. There are three settings:

Azure keeps several copies of every disk so a single hardware failure does not lose your data.

A physical drive can break. Azure plans for this by storing extra copies of your disk’s data. The words you need here are durability, which means how unlikely it is that data is lost forever, and redundancy, which means how many copies exist and where they are kept. Managed disks come in two redundancy options.

flowchart LR
    VM["Virtual Machine"] --> D["Managed Disk"]
    D --> L["LRS: 3 copies in one zone"]
    D --> Z["ZRS: copies across 3 zones"]
    Z --> Z1["Zone 1"]
    Z --> Z2["Zone 2"]
    Z --> Z3["Zone 3"]
        

The diagram shows the VM talking to one disk. Behind that single disk, Azure quietly places the copies according to the redundancy you selected. Your VM never sees this; it simply keeps reading and writing as normal.

Azure scrambles your disk data automatically, and you can add stronger layers when rules demand it.

Encryption means turning readable data into scrambled data that can only be read with a secret key. If someone stole a physical drive from a data center, encryption would make its contents useless to them. Azure offers several layers, and understanding each one helps you pass security reviews.

Controlling who can touch a disk

Encryption protects data at rest, but you must also control who can manage the disk. Azure role-based access control lets you give each person only the permissions they need, for example allowing a support engineer to view a disk but not delete it. You can also use private networking options so that disk exports and uploads happen only over private connections instead of the public internet.

Snapshots and backups let you travel back in time, and disaster recovery lets you survive a regional outage.

Snapshots

A snapshot is a read-only picture of a disk at one moment. Think of taking a photo of your wardrobe: you can bring everything back to how it looked in the photo. Azure supports two styles. A full snapshot copies the whole disk. An incremental snapshot stores only the changes since the previous snapshot, which saves a great deal of space and money. Snapshots are not tied to the VM, so you can create a brand-new disk from one at any time, for example to clone a server or to recover from a bad change.

Azure Backup

Snapshots are manual tools. Azure Backup automates the work: you set a schedule and a retention period, such as daily backups kept for thirty days, and the service handles the rest. It is the recommended way to protect production VMs because it keeps recovery points organized and lets you restore a whole VM or a single disk.

Disaster recovery

If an entire Azure region has a serious problem, even backups in that region may be unreachable. Azure Site Recovery continuously copies your VM’s disks to a second region, so you can start the VM there when needed. The plan to follow in such an event is your disaster recovery plan, and it should be tested regularly so that nobody learns how it works in the middle of a crisis.

flowchart TD
    A["Managed Disk in use"] --> B["Snapshot: quick restore point"]
    A --> C["Azure Backup: scheduled restore points"]
    A --> D["Site Recovery: copy in another region"]
    B --> E["Restore to a new disk"]
    C --> F["Restore a disk or a full VM"]
    D --> G["Fail over to the second region"]
        

Shared disks let several VMs read and write the same disk at the same time, for clustered applications.

Normally a disk belongs to one VM at a time. A shared disk can be attached to several VMs together. This is important for clusters, which are groups of servers that work as a team so that if one server fails, another takes over immediately. In such a cluster, all the servers need access to the same storage, and a shared disk provides it.

Shared disks do not magically coordinate the servers. The cluster software running on the VMs, such as Windows Server Failover Clustering, must decide which server may write at a given moment. Azure supports this through a standard feature called persistent reservations, which acts like a polite “I am using this right now” sign that servers can place on the disk. Shared disks are available on several disk types, and the number of VMs that can share one disk depends on the disk’s size and type.

Your VM and its disk live on different machines and talk to each other over a very fast network.

Here is something that surprises many beginners: the disk is not inside the same machine as your VM. The VM runs on a compute server, while the disk’s data lives on a separate storage cluster. They are joined by a high-speed internal network. When your application asks to read a file, the operating system converts that request into a block request, the host sends it across the network, the storage cluster finds the blocks, and the answer travels back.

This design has big advantages. Because storage is separate, your disk survives even if the compute server fails: Azure can restart your VM on another server and attach the same disk. It also lets Azure keep multiple copies of your data on separate drives.

sequenceDiagram
    participant App as Application
    participant OS as Operating System
    participant Host as Azure Host
    participant Store as Storage Cluster
    App->>OS: Read a file
    OS->>Host: Block request
    Host->>Host: Check host cache
    Host->>Store: Fetch blocks over network
    Store-->>Host: Return data
    Host-->>OS: Deliver blocks
    OS-->>App: File contents
        

The life of a disk

The right choice depends on how important the workload is and how much speed it truly needs.

The most common beginner error is to pick the most expensive disk “to be safe”. The second most common error is the opposite, choosing the cheapest disk for a system that users depend on. A short list of questions will guide you to a sensible answer.

flowchart TD
    S["Start: what is the workload?"] --> Q1{"Is it business critical with very high speed needs?"}
    Q1 -- Yes --> Q2{"Need to change speed live or lowest delay?"}
    Q2 -- Yes --> U["Ultra Disk"]
    Q2 -- No --> P2["Premium SSD v2"]
    Q1 -- No --> Q3{"Is it a production system?"}
    Q3 -- Yes --> P["Premium SSD"]
    Q3 -- No --> Q4{"Is it accessed often?"}
    Q4 -- Yes --> SS["Standard SSD"]
    Q4 -- No --> H["Standard HDD"]
        

Matching disks to common workloads

You are billed for what you provision, so smart sizing is the biggest money saver.

Disk pricing follows a few simple ideas. For Premium SSD and Standard SSD, you pay a fixed monthly price for the size step you chose, such as P10 or E20, whether the disk is empty or full. If you need 100 GiB, you are billed for the next size step that fits it. Standard disks may also add a small charge per batch of read and write operations. For Premium SSD v2 and Ultra Disk, the bill has several parts: you pay for the capacity, and separately for the IOPS and throughput you configured above the free baseline.

Snapshots, backups, extra redundancy such as ZRS, and moving data between regions all add to the bill as well. None of these are large on their own, but together they can surprise a team that did not plan for them.

Watching a few key numbers will warn you about trouble long before users complain.

A disk that is quietly running out of speed or space can slow down a whole application. Azure Monitor collects metrics about your disks and VMs, and you can draw charts or set alerts on them. A metric is simply a number measured over time. Here are the ones that matter most for beginners.

Set alerts at sensible thresholds, such as eighty percent of the limit, so that you have time to react. Also remember the VM-level limits we discussed earlier: a VM can be capped even when the disk itself looks relaxed. Good monitoring looks at both.

Learn from the mistakes that many teams make so that you do not have to repeat them.

Seeing how disks fit real projects makes the choices easier to remember.

Azure disks are block storage attached to virtual machines, like a drive inside a computer. Blob Storage keeps whole files as objects reachable over the web, and Azure Files provides shared folders that many computers can open at once. Pick the one that matches how your application reads its data.

In many cases yes. You can often switch between supported disk types, for example from Standard SSD to Premium SSD, usually after stopping or deallocating the VM. Some types, such as Ultra Disk and Premium SSD v2, have special rules, so check the official guidance first.

Yes, you can increase a disk’s size, but you cannot shrink it. After growing the disk in Azure, you also need to extend the partition and file system inside the operating system. Because shrinking is impossible, avoid starting with a size far bigger than needed.

That depends on the delete settings chosen when the disk was attached. Disks can be kept or deleted along with the VM. Always check this setting for disks that hold important data, and keep a snapshot before deleting anything.

The limit is set by the VM size. Larger VM sizes allow more data disks and also higher combined IOPS and throughput. Check your VM size’s specifications before planning a design with many disks.

Yes. Every managed disk is encrypted at rest using platform-managed keys without any action on your part. You can add customer-managed keys, encryption at host, or Azure Disk Encryption if your company’s rules require more control.

Not exactly. A snapshot is a single point-in-time copy that you create and manage yourself. Azure Backup is a managed service that automates schedules, retention and restores. For production systems, backups are the more complete protection.

Usually not. Standard SSD is normally sufficient for development and test work, unless you are specifically testing performance against production-like conditions.

Azure disk storage is the foundation under almost every virtual machine you will ever run. It stores the operating system, your applications and your data as blocks, managed for you by Azure so you do not have to worry about the hardware beneath. You now know the three disk roles, the five disk types from Ultra Disk down to Standard HDD, and the three numbers that describe speed. You have also seen how bursting and caching add speed, how LRS and ZRS protect against failure, how encryption keeps data private, and how snapshots, backups and Site Recovery let you recover from mistakes and outages.

The best disk strategy is never about buying the most powerful option. It is about understanding your workload, choosing the smallest suitable disk type, protecting data with real backups, and cleaning up what you no longer need. With these habits, you will build storage that is fast enough, safe enough and affordable.