Premium SSD disks of 32 GiB or more on non-production machines that Standard SSD could carry

Premium SSD pricing on disks that never face production load

Managed disks bill by provisioned size, not by data written. The disk types page explains that Azure maps each disk to the nearest offered size and prorates that tier’s monthly price by the hour. Premium SSD tiers buy low latency and guaranteed IOPS; Microsoft describes Standard SSD as suited to web servers, lightly used applications and non-production workloads.

A development VM cloned from a production template usually inherits Premium disks along with everything else. Those disks cost the same whether the VM runs a load test once a quarter or sits idle, which is why the environment alone is a reasonable signal here.

Listing Premium disks by size and owner

az disk list \
  --query "[?sku.name=='Premium_LRS' && diskSizeGB >= \`32\`].{name:name, rg:resourceGroup, size:diskSizeGB, tier:tier, vm:managedBy}" \
  -o table

Cross-check the resource groups and tags against your environment naming. To see what the disk actually does, read its operations per second:

az monitor metrics list --resource <disk-resource-id> \
  --metric "Composite Disk Read Operations/sec" "Composite Disk Write Operations/sec" \
  --aggregation Maximum --interval PT1H --offset 30d

Environment and size gates for this recommendation

1. The disk SKU is Premium_LRS and the disk is at least 32 GiB, the P4 size.
2. The disk is positively non-production: a dev or test environment tag, a dev or test name, or a dev or test resource group, with no production tag overriding it. A disk with no environment signal at all is not assumed to be non-production.
3. The disk name does not suggest a database role. Names containing datadisk, logdisk or tempdb, or a database engine name such as sql, oracle, hana, postgres, mysql or mongo, are never proposed for a tier change, because those volumes are often sized for an I/O requirement even outside production.
4. The disk has a monthly cost, and Premium and Standard SSD tier rates for its size are known for the region.

When observed IOPS or pricing block the change

Usage is not what makes this rule fire, but it can stop it. When Azure Monitor has both read and write operations for the disk and their combined peak is above what the same-size Standard SSD tier provides, the move would starve the workload and there is no finding. Missing metrics do not block it, since the environment is the basis here.

Disks with real production usage are covered elsewhere: Azure Premium Disk IOPS Downgrade looks at measured IOPS on any Premium disk, and Azure Small Premium Disk Tier Optimization handles low-IOPS disks that are not marked non-production.

Tier rate arithmetic for the downgrade

monthly saving = (Premium tier hourly rate - Standard SSD tier hourly rate) x 730

If either rate is missing, the Standard SSD rate is not lower, or the result is at or above the disk’s whole monthly cost (a sign of a stale rate), no recommendation is produced.

Converting the disk to Standard SSD

1. Confirm the VM really is non-production and nobody depends on its disk latency.
2. Take a snapshot of the disk.
3. Stop and deallocate the VM: az vm deallocate --resource-group my-rg --name my-dev-vm.
4. Change the SKU at the same size: az disk update --resource-group my-rg --name my-disk --sku StandardSSD_LRS.
5. Start the VM and check application latency.