Azure Disk Storage – Consider Updating to Premium SSD v2

The Azure Premium SSD v2 policy flags Azure managed data disks on Premium SSD (Premium_LRS) and recommends moving them to Premium SSD v2 (PremiumV2_LRS). Premium SSD v2 lets teams provision capacity, IOPS, and throughput separately, and an equivalent disk typically costs around 30% less. Apply this policy to azurerm_managed_disk data disks whose workloads fit within the Premium SSD v2 limitations.

Why This Policy Matters

How It Helps Reduce Cloud Costs

Azure Premium SSD (v1) ties performance to fixed size tiers. A P30 disk is 1 TiB with 5,000 IOPS and 200 MB/s, and every disk is billed at the price of its tier.

That tier model drives quiet over-provisioning. A workload that needs 600 GiB of storage still pays the P30 price, because the next tier down is too small.

A workload that needs more IOPS has one lever on Premium SSD: move to a larger tier and pay for capacity it does not use.

Azure Premium SSD v2 removes that link. Capacity is billed per GiB in 1 GiB increments, and every disk includes 3,000 IOPS and 125 MB/s at no extra charge.

IOPS and throughput above that baseline are provisioned and billed separately. Teams pay for the storage and performance the workload actually needs, not for the nearest tier.

Potential Savings

Azure Premium SSD v2 savings come from two sources: a lower effective price for matched performance, and the end of tier rounding.

For a like-for-like replacement, the saving is typically around 30%. In East US, a 1 TiB P30 disk lists at $135.17 per month. A 1,024 GiB Premium SSD v2 disk provisioned at the same 5,000 IOPS and 200 MB/s comes to about $95 per month.

The saving grows when a disk was sized up only to reach a tier. A 600 GiB Premium SSD v2 disk at the free baseline of 3,000 IOPS and 125 MB/s costs about $48 per month in East US.

This policy pays off most on data disks that were sized for a tier, not for their data. Disks already sized close to their real capacity and performance needs see a smaller, but still consistent, saving.

Implementation Guide

Infrastructure-as-Code Example (Terraform)

The following examples show an Azure managed data disk on Premium SSD, and the corrected Premium SSD v2 configuration.

Non-compliant configuration: Azure managed disk on Premium SSD (v1)

resource "azurerm_managed_disk" "app_data" {
  name                 = "app-data-disk"
  location             = azurerm_resource_group.app.location
  resource_group_name  = azurerm_resource_group.app.name
  zone                 = "1"
  storage_account_type = "Premium_LRS"
  create_option        = "Empty"
  disk_size_gb         = 1024
}

resource "azurerm_virtual_machine_data_disk_attachment" "app_data" {
  managed_disk_id    = azurerm_managed_disk.app_data.id
  virtual_machine_id = azurerm_linux_virtual_machine.app.id
  lun                = 10
  caching            = "ReadOnly"
}

resource "azurerm_managed_disk" "app_data" {
  name                 = "app-data-disk"
  location             = azurerm_resource_group.app.location
  resource_group_name  = azurerm_resource_group.app.name
  zone                 = "1"
  storage_account_type = "Premium_LRS"
  create_option        = "Empty"
  disk_size_gb         = 1024
}

resource "azurerm_virtual_machine_data_disk_attachment" "app_data" {
  managed_disk_id    = azurerm_managed_disk.app_data.id
  virtual_machine_id = azurerm_linux_virtual_machine.app.id
  lun                = 10
  caching            = "ReadOnly"
}

resource "azurerm_managed_disk" "app_data" {
  name                 = "app-data-disk"
  location             = azurerm_resource_group.app.location
  resource_group_name  = azurerm_resource_group.app.name
  zone                 = "1"
  storage_account_type = "Premium_LRS"
  create_option        = "Empty"
  disk_size_gb         = 1024
}

resource "azurerm_virtual_machine_data_disk_attachment" "app_data" {
  managed_disk_id    = azurerm_managed_disk.app_data.id
  virtual_machine_id = azurerm_linux_virtual_machine.app.id
  lun                = 10
  caching            = "ReadOnly"
}

This 1,024 GiB Premium SSD disk is billed as a P30 at about $135 per month in East US. This is a common source of wasted spend. The team pays a tier price, and the only way to get more IOPS is to buy a bigger tier.

Compliant configuration: Azure managed disk on Premium SSD v2

resource "azurerm_managed_disk" "app_data" {
  name                 = "app-data-disk"
  location             = azurerm_resource_group.app.location
  resource_group_name  = azurerm_resource_group.app.name
  zone                 = "1"
  storage_account_type = "PremiumV2_LRS"
  create_option        = "Empty"
  disk_size_gb         = 1024
  disk_iops_read_write = 5000
  disk_mbps_read_write = 200
}

resource "azurerm_virtual_machine_data_disk_attachment" "app_data" {
  managed_disk_id    = azurerm_managed_disk.app_data.id
  virtual_machine_id = azurerm_linux_virtual_machine.app.id
  lun                = 10
  caching            = "None"
}

resource "azurerm_managed_disk" "app_data" {
  name                 = "app-data-disk"
  location             = azurerm_resource_group.app.location
  resource_group_name  = azurerm_resource_group.app.name
  zone                 = "1"
  storage_account_type = "PremiumV2_LRS"
  create_option        = "Empty"
  disk_size_gb         = 1024
  disk_iops_read_write = 5000
  disk_mbps_read_write = 200
}

resource "azurerm_virtual_machine_data_disk_attachment" "app_data" {
  managed_disk_id    = azurerm_managed_disk.app_data.id
  virtual_machine_id = azurerm_linux_virtual_machine.app.id
  lun                = 10
  caching            = "None"
}

resource "azurerm_managed_disk" "app_data" {
  name                 = "app-data-disk"
  location             = azurerm_resource_group.app.location
  resource_group_name  = azurerm_resource_group.app.name
  zone                 = "1"
  storage_account_type = "PremiumV2_LRS"
  create_option        = "Empty"
  disk_size_gb         = 1024
  disk_iops_read_write = 5000
  disk_mbps_read_write = 200
}

resource "azurerm_virtual_machine_data_disk_attachment" "app_data" {
  managed_disk_id    = azurerm_managed_disk.app_data.id
  virtual_machine_id = azurerm_linux_virtual_machine.app.id
  lun                = 10
  caching            = "None"
}

The same disk on Premium SSD v2 costs about $95 per month and keeps the P30 performance level. Setting disk_iops_read_write and disk_mbps_read_write explicitly makes the performance baseline visible in code review.

The disk_iops_read_write and disk_mbps_read_write attributes are only valid when storage_account_type is PremiumV2_LRS or UltraSSD_LRS. If the workload needs no more than 3,000 IOPS and 125 MB/s, omit both attributes and pay only for capacity.

Premium SSD v2 does not support host caching, so caching on azurerm_virtual_machine_data_disk_attachmentmust be "None".

Step-by-Step Fix Instructions

1. Search Terraform configuration for every azurerm_managed_disk resource with storage_account_type = "Premium_LRS".

2. Exclude OS disks and disks created from an Azure Compute Gallery image. Azure does not allow either to move to Premium SSD v2.

3. Confirm Premium SSD v2 is available in the disk's region. In most regions with availability zones, Premium SSD v2 disks attach only to zonal VMs. Check that zone is set on the disk and the VM.

4. Review Azure Monitor disk metrics for peak IOPS and throughput. Use those numbers, not the old tier, to set disk_iops_read_write and disk_mbps_read_write.

5. Clear the blockers Azure lists for conversion. Set caching = "None" on the data disk attachment. Remove tierand on_demand_bursting_enabled from the disk. Disable Azure Site Recovery or double encryption if either is in use.

6. Apply those blocker changes in their own terraform apply, before touching storage_account_type. Terraform updates azurerm_managed_disk before the attachment that depends on it, so a combined apply can attempt the conversion while host caching is still on.

7. Change storage_account_type to "PremiumV2_LRS". Run terraform plan and confirm azurerm_managed_diskshows an in-place update, not a replacement.

8. Apply during a maintenance window. When storage_account_type changes on an attached disk, the AzureRM provider shuts down and deallocates the VM, updates the disk, and starts the VM again.

9. Track conversion progress until it reaches 100%. Disk performance is degraded until the conversion completes.

10. Add Infracost to CI/CD so any new azurerm_managed_disk on Premium_LRS is flagged in the pull request before it merges.

Best Practices

• Set storage_account_type = "PremiumV2_LRS" as the default for data disks in shared Terraform modules, with zonal VMs as the module default.

• Size disk_iops_read_write and disk_mbps_read_write from observed metrics. Start at the free 3,000 IOPS and 125 MB/s baseline and raise only when monitoring shows a need.

• Migrate in batches. Microsoft recommends 50 to 100 disks per subscription per region at a time, and a support ticket for more than 1,000.

• Do not set logical_sector_size on converted disks. Existing disks convert to a 512-byte sector size, and changing logical_sector_size in Terraform forces a new disk.

• This policy does not apply to OS disks. Keep OS disks on Premium SSD or Standard SSD and target data disks only.

Tools and Scripts

How does Infracost detect Premium SSD v1 disks automatically?

The Azure Premium SSD v2 policy is available in Infracost, including in the free trial. When Infracost runs in CI/CD, it checks azurerm_managed_disk resources in each pull request. It flags disks on Premium_LRS in the PR comment, with the file and line to change.

This catches a v1 disk before it exists, when the fix is a one-line change in the same pull request. Infracost also scans connected repositories for existing Premium SSD v1 disks. FinOps and platform teams can then burn down that backlog and track progress on a burndown chart.

Teams can set the policy to warn engineers or to block pull requests that fail it. The "trigger on new resources only" option limits findings to newly added disks. Engineers are not pushed into a disk migration inside an unrelated pull request.

To list Premium SSD v1 disks in a subscription with the Azure CLI:

az disk list \
  --query "[?sku.name=='Premium_LRS'].{name:name, rg:resourceGroup, sizeGb:diskSizeGB, zones:zones, attachedTo:managedBy}" \
  --output

az disk list \
  --query "[?sku.name=='Premium_LRS'].{name:name, rg:resourceGroup, sizeGb:diskSizeGB, zones:zones, attachedTo:managedBy}" \
  --output

az disk list \
  --query "[?sku.name=='Premium_LRS'].{name:name, rg:resourceGroup, sizeGb:diskSizeGB, zones:zones, attachedTo:managedBy}" \
  --output

To check conversion progress on a disk after the change:

az disk show --name app-data-disk --resource-group app-rg --query completionPercent --output

az disk show --name app-data-disk --resource-group app-rg --query completionPercent --output

az disk show --name app-data-disk --resource-group app-rg --query completionPercent --output

If a disk is managed by Terraform, change storage_account_type in code rather than in the portal or CLI. Otherwise the next terraform apply tries to move the disk back to Premium_LRS.

Examples of Impact

Illustrative example: a database cluster on P30 disks. A platform team runs 20 Azure Premium SSD P30 data disks for a database cluster in East US. At $135.17 each, that is about $2,700 per month. Moving them to Premium SSD v2 at the same 5,000 IOPS and 200 MB/s brings the total to about $1,910, saving roughly $9,500 per year.

Illustrative example: a disk sized up to reach a tier. A service needs 600 GiB of storage and about 3,000 IOPS. On Premium SSD it lands on a P30 at about $135 per month. On Premium SSD v2, a 600 GiB disk at the free performance baseline costs about $48 per month.

The saving depends on how far the old tier was from what the workload actually needs.

(These are illustrative scenarios using published East US pay-as-you-go list prices, not specific customer accounts.)

Considerations and Caveats

Premium SSD v2 is the right default for most Azure data disks, but its limitations decide which disks can move.

• No OS disks. Azure Premium SSD v2 cannot be an OS disk or be used with Azure Compute Gallery images.

• No host caching. Workloads that depend on ReadOnly or ReadWrite host caching need testing before migration.

• Zonal VMs in most regions. In most regions with availability zones, Premium SSD v2 disks attach only to zonal VMs. A non-zonal disk may need a snapshot-based migration to a new zonal disk, which Terraform treats as a replacement.

• Conversion needs a restart. Changing an attached disk's type requires a VM restart, and Azure allows a disk type change only twice per day.

• Backup and recovery settings. VMs using Azure Backup must move to the Enhanced Backup policy first. Azure Site Recovery must be disabled before conversion.

Related Policies and Concepts

• Amazon EBS - consider upgrading gp2 volumes to gp3: the AWS equivalent of decoupling block storage performance from volume size.

• Amazon EBS - consider updating io1/io2 volumes to gp3: a Block Storage policy for provisioned IOPS volumes whose workloads fit a cheaper general-purpose tier.

• Azure Storage Accounts - consider upgrading account kind to StorageV2: another Azure storage policy that moves resources from an older storage type to the current, lower-cost one.

• "How to Reduce Your Azure Cloud Costs With Infracost in 30 Days": an Infracost resource article covering the wider Azure cost workflow that this disk policy fits into.

Frequently Asked Questions (FAQs)

Is this policy supported in Infracost?

Yes. The Azure Premium SSD v2 policy is supported in Infracost and available in the free trial. Infracost flags azurerm_managed_disk resources using Premium_LRS in pull requests, so the team can switch to Premium SSD v2 before the disk is created.

Can this policy be customized?

Yes. Teams can configure how Infracost enforces the Azure Premium SSD v2 policy. For example, a finding can warn engineers or block the pull request, and can trigger on new resources only.

Does Infracost automatically fix violations?

No. Infracost does not change Azure disks on its own. Infracost reports Premium SSD v1 disks in the pull request with the file and line to change. Changing storage_account_type to PremiumV2_LRS is a decision the team makes and reviews.

Is this policy cloud-agnostic?

No. The Azure Premium SSD v2 policy targets Azure through the azurerm_managed_disk Terraform resource. Amazon EBS and Google Cloud persistent disks have their own performance tiers with different resource and attribute names.

How often should I review Azure managed disk types?

Teams running Infracost in CI/CD get an Azure managed disk type check on every pull request that touches an azurerm_managed_disk resource. For existing disks, a quarterly review is a reasonable cadence to catch Premium SSD v1 disks created outside Terraform.

Can an Azure OS disk use Premium SSD v2?

No. Azure Premium SSD v2 is supported for data disks only. OS disks must stay on another disk type, such as Premium SSD or Standard SSD.

Does converting an Azure disk to Premium SSD v2 require downtime?

Yes, briefly. Converting an attached Azure managed disk to Premium SSD v2 requires a VM restart, and disk performance is degraded until the conversion completes. Schedule the Premium SSD v2 conversion in a maintenance window.