Azure managed disks pricing

Azure managed disks pricing is the provisioned size per disk type and month, plus transactions on Standard HDD and Standard SSD, plus separately provisioned capacity, IOPS and throughput per hour on Premium SSD v2 and Ultra Disk, plus snapshots by used size. On the bill, the Premium SSD tiers of OS and data disks usually dominate: they run with every VM and keep billing while the VM is deallocated or already deleted.

Pricing dimensions

For Premium SSD, Standard SSD and Standard HDD the provisioned size counts, not the used one: Azure rounds it up to the next offered tier and bills that tier, prorated by the hour. A 200 GiB Standard SSD becomes an E15 of 256 GiB; an E10 deleted after 20 hours is billed the monthly price prorated to 20 hours, whatever was written to it. The tier also fixes IOPS and throughput, for a Premium SSD P30 for example 5,000 IOPS and 200 MB/s. Performance plus raises IOPS and throughput from P30, E30 and S30 upwards, and the performance tier of a Premium SSD can be raised without a size change at a higher price.

Premium SSD v2 and Ultra Disk have no tiers. Capacity is billed per GiB and hour, in 1 GiB steps from 1 GiB to 64 TiB on Premium SSD v2. Every Premium SSD v2 comes with 3,000 IOPS and 125 MB/s at no charge; anything above is billed per IOPS and per MB/s and hour and can be changed four times in 24 hours. Ultra Disks bill capacity, IOPS and throughput separately from the start. Both types are allowed as data disks only; the OS disk stays Premium SSD or Standard SSD. The types of all three providers are set side by side in block, object and file storage.

Snapshots bill by used size: a snapshot of a 64 GiB disk holding 10 GiB of data bills 10 GiB. After the first full copy, incremental snapshots store only the changes since the last one, always sit on Standard HDD storage and use ZRS where it is available; up to 500 per disk are possible. The daily usage report shows the quantity as a share of the month, so 10 GiB appear as 0.3226 per day in a 31-day month.

How it appears in your billing data

Managed disks sit in the cost export not under Virtual Machines but under MeterCategory Storage. MeterSubCategory names the type, such as Premium SSD Managed Disks, Standard SSD Managed Disks, Standard HDD Managed Disks, Azure Premium SSD v2 or Ultra Disks; for the tiered types MeterName names the tier and the redundancy, such as P30 LRS Disk, E10 ZRS Disk or S10 LRS Disk, with UnitOfMeasure 1/Month and a Quantity that expresses the share of the month. Transactions carry Disk Operations in the name and the unit 10K; snapshots are LRS Snapshots or ZRS Snapshots with the unit 1 GB/Month; mounts of shared Premium SSDs are named like P30 LRS Disk Mount. Premium SSD v2 and Ultra Disk produce three rows per disk: Provisioned Capacity per 1 GiB/Hour, Provisioned IOPS and Provisioned Throughput (MBps) per 1/Hour; on Premium SSD v2 the rows below the free baseline appear at a price of 0.

ConsumedService is Microsoft.Compute, and ResourceId ends in disks/ and the disk name or in snapshots/ and the snapshot name, never in the VM. The disks of a VM can therefore be joined only through the resource group, through tags or through the disk's VM assignment in Resource Graph; a disk does not inherit the VM's tags. The export's structure is in Azure cost exports.

In the FOCUS export the rows become ChargeCategory Usage with PricingCategory Standard, or Committed for reserved disks; MeterName lands in SkuMeter, type and category in x_SkuMeterSubcategory and x_SkuMeterCategory. Microsoft derives ServiceName from ConsumedService and the resource type, so disks can appear under the same service as the VM, with the resource type telling them apart (FOCUS columns).

Levers

Configuration: the tier is the price, so the question is whether a 1 TiB P30 is needed or a 512 GiB P20 will do. The type is the second lever: Standard SSD for web servers and test environments, Premium SSD for production with fixed performance targets, Premium SSD v2 where capacity and performance should be sized apart (storage optimisation). Where performance is needed only now and then, the free credit-based bursting beats a higher tier; where a disk runs in burst all the time, a higher performance tier costs less than on-demand bursting.

Purchase option: for Premium SSD P30 to P80 there is a one-year reservation per SKU and region that applies automatically to matching disks; it covers neither smaller tiers nor snapshots or transactions (commitment coverage and utilisation).

Architecture: an ephemeral OS disk on the local storage of the VM size replaces the OS disk on stateless scale sets (Azure Virtual Machines). Data that is rarely read belongs in Blob Storage rather than on a disk, and backups belong in Azure Backup rather than in manual full snapshots (Azure Backup and Site Recovery). How to choose the disk type under a database on a VM is covered in database optimisation.

Where it goes wrong

• The VM is gone, the disk is not. The OS disk of a deleted VM stays unless its delete option was set, and keeps billing the full tier. Look for disks in the Unattached state (idle and orphaned resources).
• The tier is larger than the size. A 130 GiB disk is billed as a 256 GiB P15 because Azure rounds up to the next tier. Compare MeterName with the size provisioned in the portal.
• Transactions on standard disks. Standard SSD and Standard HDD bill I/O operations per 10,000 up to an hourly cap; a database or a log directory on a standard disk produces Disk Operations rows that the disk price gives no hint of.
• Snapshots keep growing. Full snapshots copy the used disk every time; incremental snapshots store only the changes, but a long chain that nobody prunes still adds up. Check rows with Snapshots in MeterName against the number of snapshots per disk.
• On-demand bursting stays on. The enablement fee accrues per hour even while the disk is detached, until you disable bursting, which is possible twelve hours after enabling it at the earliest.
• Ultra-capable VM without an Ultra Disk. A VM with the Ultra Disk capability enabled and no Ultra Disk attached pays the reservation fee per vCPU, on constrained-core sizes by the actual vCPUs.
• Shared Premium SSDs. Every additional mount of a shared Premium SSD costs a monthly surcharge; on Premium SSD v2 and Ultra Disk the sum of the four performance values is billed instead.

Example

List prices from the Azure Retail Prices API in EUR for Germany West Central, read on 2026-10-21, all LRS: a P30 (1 TiB) costs EUR 130.8342 per month, an E30 of the same size EUR 67.5818 and an S30 EUR 36.0436; one tier down, a P10 (128 GiB) costs EUR 19.0778, an E10 EUR 8.4477 and an S10 EUR 5.1813 per month. Transactions on Standard SSD stand at EUR 0.0023 per 10,000 (meter Disk Transactions LRS Disk Operations), on Standard HDD at EUR 0.0006 per 10,000. Snapshots cost EUR 0.1276 per GB and month on Premium SSD storage and EUR 0.044 on the Standard HDD storage that incremental snapshots use. An additional mount of a shared P30 costs EUR 7.5158 per month. For Premium SSD v2 the API returns EUR prices to four decimals only, so the capacity price shows as EUR 0.0001 per GiB and hour; the same query in USD gives USD 0.00013 per GiB and hour, USD 0.000008 per IOPS and hour above 3,000 and USD 0.000065 per MB/s and hour above 125. The figures show that Premium SSD costs about twice Standard SSD at each tier and that an incremental snapshot costs far less per GB than the disk it protects.

Sources

Read on 2026-10-21. Prices: Azure Retail Prices API, managed disk tiers in Germany West Central in EUR, snapshots and transactions, Premium SSD v2 and Ultra Disk in EUR, the same query in USD, Azure Retail Prices API reference. Billing data: Cost details fields, Convert Cost Management data to FOCUS. Service: Disk types and billing, Disk bursting, Incremental snapshots, Shared disks, Azure Disk Storage reservations.