# Azure Premium Disk IOPS Downgrade

> 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.

Source: https://zop.dev/integrations/azure/recommendations/azure-premium-disk-iops-downgrade
Updated: 2026-08-19

---

## 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

```text
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

1. Review the disk's IOPS and throughput graphs in Azure Monitor to confirm the observed peak
2. Snapshot the disk (Azure Portal → Disks → Create snapshot)
3. Stop/deallocate the attached VM
4. Azure Portal → Disks → Select → Size + performance → select the next-smaller Premium tier at the same size
5. 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)