A Premium SSD with its performance tier bumped above its size baseline bills the higher tier until someone puts it back

What it is

A Premium SSD (v1) managed disk whose properties.tier has been set above the baseline tier for its provisioned size, such as a 128 GiB disk billing at P30 instead of its baseline P10, while the I/O it actually serves would fit a lower tier. Azure bills a Premium SSD by its performance tier, not its size, so the bump costs real money every month it stays in place. The fix is a single online property change that needs no VM downtime, which is exactly why nobody schedules the time to do it.

Why it happens

Every Premium SSD size maps to a baseline performance tier (4 GiB is P1, 128 GiB is P10, 1 TiB is P30, and so on). Azure lets you raise the tier without changing the size to buy more IOPS and throughput for a while: P10 is 500 IOPS / 100 MBps, P30 is 5,000 IOPS / 200 MBps. Microsoft's own examples for the feature are seasonal peaks, performance testing, and training environments, all temporary by definition. The property that remembers the choice is not.

The bump gets made for sensible reasons: a one-time data migration, a restore that needed to finish before morning, a load test, or a "just in case" during a cutover. Then the reason ends and the tier stays, because nothing surfaces it. The VM's disk list shows the size column (128 GiB) and the SKU (Premium SSD); the tier lives on a separate Size + performance page per disk, and properties.tier is a field most inventory scripts never project. For disks created before June 2020 the property is not even returned until someone sets it, which trains people to ignore it.

A few rules shape the cleanup. A disk can never bill below its size baseline, so a 1 TiB disk is P30 at minimum no matter how idle it is. P60, P70, and P80 are only valid on disks larger than 4,096 GiB. Downgrades are allowed once every 12 hours. Shared disks (maxShares > 1) are the exception to "online": every VM attached to a shared disk must be stopped before its tier changes. And if you manage the disk with Terraform, note that Terraform's tier change shuts the VM down and restarts it; the CLI, PowerShell, and the portal do not.

What it costs / blast radius

At list price in East US (LRS), a 128 GiB Premium SSD bills about $19.71/month at its P10 baseline and about $135.17/month at the P30 tier, a difference of roughly $115/month, or about $1,385/year, for one disk. A 256 GiB disk left at P30 pays about $97/month over its P15 baseline (~$38.01). (Azure list prices; your contract, region, and redundancy may differ.)

The multiplier is the problem. A tier bump is usually applied to every disk in a migration wave or a test fleet, so what looks like one forgotten setting can be ten or twenty identical ones. There is no performance downside to reverting a disk whose observed demand fits the lower tier: the change is online and the disk keeps serving I/O throughout.

See it

Resources
| where type =~ 'microsoft.compute/disks'
| where sku.name in~ ('Premium_LRS', 'Premium_ZRS')
| where isnotempty(properties.tier)
| extend sizeGB = toint(properties.diskSizeGB), tier = tostring(properties.tier)
| extend baseline = case(
    sizeGB <= 4, 'P1', sizeGB <= 8, 'P2', sizeGB <= 16, 'P3', sizeGB <= 32, 'P4',
    sizeGB <= 64, 'P6', sizeGB <= 128, 'P10', sizeGB <= 256, 'P15', sizeGB <= 512, 'P20',
    sizeGB <= 1024, 'P30', sizeGB <= 2048, 'P40', sizeGB <= 4096, 'P50',
    sizeGB <= 8192, 'P60', sizeGB <= 16384, 'P70', 'P80')
| where tier != baseline
| project name, resourceGroup, subscriptionId, sizeGB, baseline, tier,
          sku = sku.name, diskState = properties.diskState, attachedTo = managedBy

# Confirm the current tier, then drop it. The disk keeps serving I/O
# throughout; the change is live within minutes and billing follows.
az disk show --name vm-prod-01-data01 --resource-group rg-prod \
  --query "{sizeGB: diskSizeGB, tier: tier}" -o table

az disk update --name vm-prod-01-data01 --resource-group rg-prod \
  --set tier=P10

# Shared disk (maxShares > 1)? Stop every attached VM first, then run the
# same update. Downgrades are limited to once every 12 hours per disk.