Azure Premium Disk IOPS Downgrade
1
1
medium
What does ZopNight detect here?
Premium_LRS disks provisioned at 500 IOPS or more whose observed 30-day peak stays under 20% of provisioned IOPS are stepped down one Premium tier at the same size. Savings come from the authoritative tier-rate delta; a missing metric series or rate makes the rule abstain rather than estimate.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1394 |
| Category | rightsizing |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | disk_iops_downgrade.go |
Where it applies
Provisioned IOPS versus the observed peak
- resource.InstanceType must equal Premium_LRS (tier-delta math only applies inside the Premium family); other SKUs are skipped.
- resource.Metadata.iopsReadWrite holds provisioned IOPS as a string; parsed to int via provisionedIOPSFromMetadata. Missing / empty / non-numeric returns (0, false) and the rule fails safe.
- azurePremiumIOPSDowngradeMinProvisioned = 500, P10’s ceiling. Below this the rule cannot step down without leaving the Premium family, so it skips.
- resource.Metadata.tier gives the current P-tier name (e.g. P30); used by the SKU-rate lookup and the next-smaller computation via skuladder.PremiumIOPSDowngrade. The discoverer writes this from the Azure Resource Graph sku.tier field.
- Monitor metrics: both DiskDataReadOps and DiskDataWriteOps must be populated under uid:metricName. A missing series is a data gap (not idle) and the rule must not fire.
- Observed peak IOPS = readMetric.Maximum + writeMetric.Maximum. The sum overstates the true peak (the per-series maxes may not co-occur), which is the safe direction, biasing against flagging. both raw metric series are attached to the recommendation with a zero-floor gte comparator so the drawer chart shows the 30-day peak relative to a zero baseline; the description carries the utilisation ratio context.
Why the ceiling sits at 20% of provisioned IOPS
the rule fires when all gates align: SKU is Premium_LRS AND provisioned ≥ 500 IOPS AND both metric series present AND observedPeak / provisioned < azurePremiumIOPSUnderuseCeiling = 0.20 AND monthly cost > 0 AND an authoritative rate delta exists (both current and next-smaller P-tier rates present, dst < src, derived savings > 0). When the rate delta is missing or non-positive the rule abstains instead of fabricating a fraction-of-cost estimate. The 20% ceiling leaves ≥60% headroom on the next-smaller tier after downgrade.Stepping down one Premium tier safely
- Review the disk’s IOPS and throughput graphs in Azure Monitor to confirm the observed peak
- Snapshot the disk (Azure Portal → Disks → Create snapshot)
- Stop/deallocate the attached VM
- Azure Portal → Disks → Select → Size + performance → select the next-smaller Premium tier at the same size
- Start the VM and monitor latency / queue depth for 24h to validate the new tier
Disk read and write ops over 30 days
DiskDataReadOps + DiskDataWriteOps (Azure Monitor, 30d via azurePremiumIOPSDowngradeLookbackDays)