Hello Friends,
One of the projects I was recently involved in brought something to my mind that I have been wanting to write about for a while. The team had a solid Azure footprint, a mature DevOps practice, and a FinOps initiative that was starting to ask the right questions about where the money was actually going. When we pulled the disk inventory, the answer was staring back at us: disk after disk on Premium SSD, sized at 2,048 GiB to reach 7,500 IOPS, running workloads that were using 300 GiB of actual storage. The performance need was driving the disk size, not the other way around, and the team had no idea because that is just how Premium SSD works.
This is exactly the kind of spend that FinOps conversations surface once you get past the shiny dashboards and start looking at the actual resource configuration. You are not paying for something wasteful, you are paying for the model. The billing is working exactly as designed. The problem is the design itself, and Premium SSD v2 changes it entirely. Storage, IOPS, and throughput become three independent dimensions you configure and pay for separately. If you only need 300 GiB and 4,000 IOPS, that is precisely what you provision and precisely what you pay for.
In this three-part series I want to walk through the full picture: why the old model creates this pattern, how to identify which disks in your environment are worth migrating, how the migration itself works, and what to do after migration to keep the economics working in your favour. In Part 2 we go through the direct in-place conversion with PowerShell and Bicep. In Part 3 we cover right-sizing, monitoring, and cost governance after migration.
The problem with how Premium SSD works
Premium SSD ties IOPS and throughput directly to disk size. The bigger the disk, the higher the performance tier. There is no way to get more IOPS without provisioning more storage, and no way to reduce storage without also reducing performance. For teams that have latency-sensitive workloads, this creates a very common situation: disks that are massively over-provisioned on storage just to hit a required IOPS number.
A P40 disk gives you 7,500 IOPS and 250 MB/s throughput. It also gives you 2,048 GiB of storage whether you asked for it or not. If your workload only needs 300 GiB, you are paying for 1,748 GiB you will never use. Multiply this across dozens of disks in an environment and the overspend is significant.
Premium SSD v2 removes this coupling entirely. Storage size, IOPS, and throughput are three separate dimensions that you configure independently. You pay for each one based on what you actually provision.
What Premium SSD v2 changes
The most important shift is that IOPS and throughput are no longer a function of disk size. You can have a 300 GiB disk with 10,000 IOPS and 400 MB/s throughput, and pay only for those specific values. Nothing more.
Here is how the two SKUs compare on the dimensions that matter most for planning a migration:
| Dimension | Premium SSD | Premium SSD v2 |
|---|---|---|
| IOPS | Tied to disk size, up to 20,000 | Independently configured, up to 80,000 |
| Throughput | Tied to disk size, up to 900 MB/s | Independently configured, up to 1,200 MB/s |
| Latency | Single-digit milliseconds | Sub-millisecond |
| Min / Max size | 4 GiB to 32,767 GiB | 1 GiB to 65,536 GiB |
| Availability Zone | Optional | Required |
| Host Caching | Supported | Not supported |
| Bursting | Credit-based bursting | Not supported |
The two rows that cause the most migration complexity are Availability Zone and Host Caching. Premium SSD v2 requires a zone at creation time, and it does not support host caching at all. Both of these can affect whether a given disk is a straightforward migration or one that needs more planning.
The four constraints you need to understand
Before looking at individual disks, there are four constraints that will shape how you approach migration planning.
1-) Availability Zone is required in regions that support it
Not every Azure region has availability zones. In regions like UK West there are no zones at all, so this constraint does not apply. In regions like West Europe where zones exist, the Premium SSD v2 disk must be in the same zone as the VM. If the VM has no zone assignment, you have two options: use the regionalToZonal migration (currently in public preview) to move the VM into a zone without redeployment, or take the legacy route of redeploying the VM into a zone using a snapshot of the existing disk.
2-) Host caching is not supported
Premium SSD supports ReadOnly and ReadWrite host caching, which is commonly used for OS disks and read-heavy workloads. Premium SSD v2 does not support any host caching. If your workload relies on caching, you should benchmark the effective read performance before committing to migration.
3-) There is no live migration path
You cannot convert a disk from Premium SSD to Premium SSD v2 while the VM is running. The VM must be deallocated first. The disk stays attached throughout, the VM simply needs to be in a stopped state before the SKU change can proceed. This means a maintenance window is required for every migration.
4-) Not all regions support it
Premium SSD v2 is not available everywhere. Before planning anything, confirm that the target region supports the SKU.
$location = 'westeurope'
Get-AzComputeResourceSku |
Where-Object { $_.ResourceType -eq 'disks' -and $_.Name -eq 'PremiumV2_LRS' } |
Where-Object { $_.Locations -contains $location } |
Select-Object Name, Locations
If the query returns a result, the region supports it. If it returns nothing, Premium SSD v2 is not yet available there.
The pricing model
Premium SSD v2 bills storage, IOPS, and throughput as separate meters. Every disk includes a baseline of 3,000 IOPS and 125 MB/s at no additional charge. You only pay for what you provision above those baselines.
| Meter | What You Pay For |
|---|---|
| Storage | Per GiB per month |
| IOPS | Per provisioned IOPS above 3,000 (included free) |
| Throughput | Per provisioned MB/s above 125 MB/s (included free) |
To put this in practical terms: a P40 disk at 2,048 GiB costs roughly $140 per month in West Europe. A Premium SSD v2 disk at 300 GiB provisioned with 7,500 IOPS and 250 MB/s costs closer to $55 per month for the same effective performance tier. That difference comes from removing the 1,748 GiB of storage you were carrying purely for the performance benefit.
The savings are not universal. For workloads where disk size and performance requirements are naturally aligned, the difference is smaller. But for latency-sensitive databases, analytics workloads, and any disk that was provisioned large to reach a higher performance tier, the economics are compelling.
Assessing your environment
A question I get asked often is: how do I find the disks worth migrating? The answer is to look for disks where the provisioned storage is significantly larger than the data they actually hold, and where the VM they are attached to already lives in an availability zone.
The script below pulls all Premium SSD disks in a subscription, checks whether the attached VM has a zone assignment, and produces a report flagging which disks are straightforward migration candidates and which need additional work before they can be migrated.
[CmdletBinding()]
param (
[Parameter(Mandatory = $true)]
[string]$subscriptionId
)
$ErrorActionPreference = 'Stop'
Set-AzContext -Subscription $subscriptionId | Out-Null
$disks = Get-AzDisk | Where-Object { $_.Sku.Name -eq 'Premium_LRS' }
$vms = Get-AzVM
$report = foreach ($disk in $disks) {
$attachedVm = $vms | Where-Object {
$_.StorageProfile.OsDisk.ManagedDisk.Id -eq $disk.Id -or
$_.StorageProfile.DataDisks.ManagedDisk.Id -contains $disk.Id
}
$diskZone = if ($attachedVm -and $attachedVm.Zones) {
$attachedVm.Zones[0]
} else {
'No Zone'
}
[pscustomobject]@{
diskName = $disk.Name
resourceGroup = $disk.ResourceGroupName
diskSizeGb = $disk.DiskSizeGB
diskIops = $disk.DiskIOPSReadWrite
diskThroughput = $disk.DiskMBpsReadWrite
vmName = if ($attachedVm) { $attachedVm.Name } else { 'Unattached' }
diskZone = $diskZone
migrationReady = ($diskZone -ne 'No Zone')
notes = if ($diskZone -ne 'No Zone') { 'Ready to migrate' } else { 'Zone alignment required first' }
}
}
$report | Sort-Object migrationReady -Descending | Format-Table -AutoSize
The migrationReady flag is the starting point. Disks that are already zone-aligned are the lowest-friction candidates. Disks without a zone need more planning before migration can proceed, but they are still worth migrating once the zone question is resolved.
If you manage multiple subscriptions, wrap this script in a loop over Get-AzSubscription to build a consolidated view across your entire environment. The output is consistent enough to feed into a CSV or a workbook without modification.
Eligibility: what can be migrated directly and what cannot
Before touching any disk, you need to know whether it can be converted as-is or whether something needs to change first. The classification is straightforward: a disk is either eligible for a direct SKU change, or it has a condition that must be resolved first.
| Eligible | Ineligible - Resolve First |
|---|---|
| No host caching on the disk attachment | Host caching is enabled |
| Disk bursting not enabled | Disk bursting is enabled |
| No double encryption configured | Double encryption is in use |
| Not a shared disk | Configured as a shared disk |
| No Azure Site Recovery configured | Azure Site Recovery is active on this disk |
| Azure Backup using Enhanced Policy, or no Backup | Azure Backup is on the Standard policy |
| Data disk only | OS disk - not supported on Premium SSD v2 |
The conditions that come up most often in practice are host caching and Backup policy. Host caching must be removed from the VM's disk attachment before conversion, not from the disk itself. The Backup Standard policy needs to be upgraded to Enhanced before migration, which is a vault-level operation and can take time to coordinate with whoever owns the backup configuration.
For environments with many disks, convert in batches of 50 to 100 disks per subscription per region. If you are working at scale above 1,000 disks, raise a Microsoft support ticket before starting.
What is coming in Part 2
In this first part we covered why Premium SSD creates the oversizing pattern, what Premium SSD v2 changes, the four constraints that shape migration planning, how the pricing model works, and a PowerShell assessment script to identify candidates in your environment.
In Part 2, we will go through the actual migration. We will walk through the direct in-place SKU conversion with a PowerShell script that includes a WhatIf mode, monitor the conversion as it runs, and look at a Bicep pattern for deploying new workloads directly onto Premium SSD v2 with zone alignment handled correctly from the start.