Ultra SSD disks using a fraction of their provisioned IOPS
What does ZopNight detect here?
Ultra SSD disks bill capacity, provisioned IOPS, and provisioned throughput as 3 separate meters. RC-1308 reconstructs that true monthly cost and recommends a Premium SSD swap when the 30-day observed peak stays under 20% of provisioned IOPS. Guards on both IOPS and MBps keep the target tier from starving the workload.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1308 |
| Category | rightsizing |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | vm_ultra_disk.go |
Where it applies
One disk, three meters
Ultra Disk is the only Azure disk family where performance is a line item. A Premium SSD bundles capacity and performance into one tier price; an Ultra disk bills capacity per GB, provisioned IOPS per hour, and provisioned throughput per MBps-hour as three independent meters. Provision 20,000 IOPS “to be safe” and you pay for 20,000 IOPS around the clock, whether the workload issues them or not. That decoupling is exactly what makes over-provisioned Ultra disks expensive in a way no other idle disk is.
See what the disk is provisioned for
az disk show -n <disk> -g <rg> \ --query "{sku:sku.name, iops:diskIopsReadWrite, mbps:diskMBpsReadWrite, sizeGb:diskSizeGB}"The idle test and its honest bias
RC-1308 watches the 30-day DiskDataReadOps and DiskDataWriteOps series from Azure Monitor (Monitoring Reader covers the reads) and fires when the observed peak lands under 20% of provisioned IOPS. The peak is the read maximum plus the write maximum, two values that may not have co-occurred, so the estimate overstates real usage, deliberately biasing the rule toward silence. Missing series, an absent provisioned-IOPS or throughput value, or an unpopulated regional rate feed all cause an abstain: a data gap is never read as idleness.
Two ways a downgrade could starve the workload
Recommending Premium blindly would be dangerous on two axes, so the rule guards both. On the IOPS axis, the observed peak must fit within the target Premium tier’s published ceiling for the disk’s size. On the throughput axis there is no observed-MBps series in the pipeline today, so the rule uses the disk’s provisioned MBps as a static stand-in: if that exceeds what the target Premium tier can deliver, the recommendation is suppressed. A throughput-bound Ultra disk (low IOPS but heavy sustained MBps) is therefore never pushed onto a tier that would choke it.
Reconstructing the real bill before claiming a saving
The pipeline’s per-resource cost for an Ultra disk is the capacity meter only, so the rule rebuilds the true monthly figure: capacity cost plus provisioned IOPS times the per-IOPS-hour rate times 730, plus provisioned MBps times the per-MBps-hour rate times 730. The saving is that total minus the Premium tier’s monthly rate. When a small, modestly provisioned Ultra disk turns out cheaper than Premium, the rule abstains instead of recommending a swap that loses money.
Why no automation touches this one
Azure rejects an in-place SKU change to or from Ultra Disk, so the swap requires snapshot, detach, and recreate: a sequence ZopNight will not run unattended. The recommendation ships with a real dollar figure and manual steps, and validating latency for a day after the move is part of the job.