What it is
A Premium SSD (v1) managed disk attached to a running VM whose sustained I/O, including its peaks, fits comfortably inside what a Standard SSD of the same size provides. Premium SSD bills a flat tier price for guaranteed IOPS and throughput whether the disk uses them or not; Standard SSD bills a lower capacity price plus a per-transaction charge. For a disk that sustains a few hundred IOPS, the Premium guarantee is capacity nobody draws on. This is a different lever from a tier bump (AZF-0099): the disk is at its baseline tier, it is simply in the wrong SKU family.
Why it happens
Premium SSD is the default in the portal's VM wizard, in most marketplace images, and in the Terraform and Bicep modules teams copy from each other. It is the safe choice at provisioning time, when nobody knows what the workload will do, and there is no later moment when Azure asks whether the guess was right. Managed disks have no "utilization" column, and nothing in the platform revisits the SKU once the workload's real demand is known.
The capability gap is also smaller than most people assume for light workloads. A Standard SSD E1 through E50 provides a base of 500 IOPS and up to 100 MBps, with credit bursting to 600 IOPS / 150 MBps on E1 through E20 and to 1,000 IOPS / 250 MBps on E30 (E40 and larger do not burst). A P30 provides 5,000 IOPS / 200 MBps. A file server, a domain controller, a build agent's data disk, or a lightly used application database often sustains well under 100 IOPS at the 95th percentile, with peaks that a Standard SSD's burst would absorb. What Standard SSD does not match is latency and consistency: it is the right move for workloads that are tolerant of both, not for a busy OLTP database.
Two mechanics make people hesitate, and both are manageable. The conversion needs the attached VM deallocated (not just stopped from inside the guest) and is limited to twice per day per disk, so it belongs in a maintenance window. And Standard SSD charges per 10,000 operations, so a disk's sustained IOPS translates directly into a monthly transaction bill that has to be counted before the saving is real. Shared disks (maxShares > 1) need every attached VM stopped before converting. Redundancy should be preserved: a Premium_ZRS disk converts to StandardSSD_ZRS, not to LRS.
What it costs / blast radius
At list price in East US (LRS), a 1 TiB P30 bills about $135.17/month; the same 1 TiB as a Standard SSD E30 bills about $76.80/month plus transactions at $0.002 per 10,000 operations. A disk that sustains 50 IOPS performs roughly 131 million operations a month (50 × 730 hours × 3,600 seconds), about $26 in transactions, for a total near $103 and a saving of about $32/month per disk. At 10 IOPS the transaction line drops to about $5 and the saving approaches $53/month. A 256 GiB P15 (~$38.01) against an E15 (~$19.20) follows the same shape at smaller numbers. (Azure list prices; treat the transaction figure as an upper bound, and your contract may differ.)
The transaction charge is the honest caveat: a disk sustaining a few hundred IOPS can add $50 or more a month in operations on Standard SSD and erase the saving, which is why the fit has to be judged on observed demand rather than on the size column. Where Premium was the default for everything, the disks that genuinely qualify are often the quiet ones nobody looked at twice.
See it
Resources
| where type =~ 'microsoft.compute/disks'
| where sku.name in~ ('Premium_LRS', 'Premium_ZRS')
| where properties.diskState =~ 'Attached'
| extend sizeGB = toint(properties.diskSizeGB)
| extend standardSsdBucket = case(
sizeGB <= 4, 'E1', sizeGB <= 8, 'E2', sizeGB <= 16, 'E3', sizeGB <= 32, 'E4',
sizeGB <= 64, 'E6', sizeGB <= 128, 'E10', sizeGB <= 256, 'E15', sizeGB <= 512, 'E20',
sizeGB <= 1024, 'E30', sizeGB <= 2048, 'E40', sizeGB <= 4096, 'E50',
sizeGB <= 8192, 'E60', sizeGB <= 16384, 'E70', 'E80')
| project id, name, resourceGroup, subscriptionId, sku = sku.name, sizeGB,
tier = properties.tier, standardSsdBucket,
maxShares = properties.maxShares, attachedTo = managedBy# The VM must be deallocated, not just shut down from inside the guest.
az vm deallocate --name vm-prod-01 --resource-group rg-prod
# Conversion is instantaneous. Keep the redundancy you had: Premium_ZRS
# becomes StandardSSD_ZRS. Limited to two SKU changes per day per disk.
az disk update --name vm-prod-01-data01 --resource-group rg-prod \
--sku StandardSSD_LRS
az vm start --name vm-prod-01 --resource-group rg-prod
# Shared disk (maxShares > 1)? Deallocate EVERY attached VM before the update.How StratoLens helps
StratoLens flags attached Premium SSDs whose sustained load would fit Standard SSD, priced with the transaction charge already added so the saving it shows is the saving on the invoice, automatically and continuously across every subscription, inside your own tenant. Disks that grow into their Premium tier later simply stop being flagged.
