Azure Virtual Machines – Consider Upgrading D Series Machines to Dv5

The Azure D-series to Dv5 upgrade policy flags Azure Virtual Machines on older D-series sizes, such as Standard_D4_v2, and recommends a Dv5, Ddv5, Dsv5, or Ddsv5 size instead. A Dv5 or Ddv5 VM with the same vCPU count costs about 23% to 34% less per month in East US. It also runs on a newer Intel Xeon processor. Apply this policy to any azurerm_linux_virtual_machine or azurerm_windows_virtual_machine whose size is an older D-series value.

Why This Policy Matters

How It Helps Reduce Cloud Costs

The Azure D-series and Dv2-series are early general-purpose VM families. Microsoft has since released several newer generations of the same general-purpose family, each with better price performance.

The Dv5 series runs on Intel Xeon Platinum Ice Lake or Sapphire Rapids processors with an all-core turbo of 3.5 GHz. A Standard_D8_v5 also provides 32 GiB of memory, compared with 28 GiB on a Standard_D4_v2.

Staying on an older D-series size means paying a higher hourly rate for slower hardware. This configuration increases costs without improving performance.

Reserved pricing for older D-series sizes is also disappearing. After July 1, 2026, Microsoft no longer sells or renews one-year Reserved VM Instances for the D-series and Dv2-series. As reservations expire, these VMs fall back to pay-as-you-go pricing.

The hard deadline is May 1, 2028. After that date, Microsoft deallocates remaining D-series and Dv2-series VMs, and temporary disk data is lost.

Potential Savings

The Azure D-series to Dv5 upgrade saves money because a Dv5 or Ddv5 size costs less than the older D-series size it replaces.

Moving one Standard_D4_v2 to Standard_D8_v5 cuts its compute cost by about 34%, or roughly $1,760 per year. Moving it to Standard_D8d_v5 cuts it by about 23%, or roughly $1,160 per year.

Prices vary by region, operating system, and commitment type. Confirm current list prices for your region in the Azure Pricing Calculator before planning a migration.

The savings repeat for every older D-series VM in the estate. A fleet of 20 Standard_D4_v2 VMs moved to Standard_D8_v5 saves roughly $35,000 per year at these list prices.

Implementation Guide

Most of the work in an Azure D-series to Dv5 migration is choosing the right target size. The Terraform change itself is a single attribute.

Infrastructure-as-Code Example (Terraform)

The following examples show an Azure Linux virtual machine on an older D-series size, and the corrected Dv5 configuration.

Non-compliant configuration: Azure VM on an older D-series size

resource "azurerm_linux_virtual_machine" "api" {
  name                = "api-vm-01"
  resource_group_name = azurerm_resource_group.api.name
  location            = azurerm_resource_group.api.location
  size                = "Standard_D4_v2"
  admin_username      = "azureuser"

  network_interface_ids = [
    azurerm_network_interface.api.id,
  ]

  admin_ssh_key {
    username   = "azureuser"
    public_key = file("~/.ssh/id_rsa.pub")
  }

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "StandardSSD_LRS"
  }

  source_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-jammy"
    sku       = "22_04-lts-gen2"
    version   = "latest"
  }
}

resource "azurerm_linux_virtual_machine" "api" {
  name                = "api-vm-01"
  resource_group_name = azurerm_resource_group.api.name
  location            = azurerm_resource_group.api.location
  size                = "Standard_D4_v2"
  admin_username      = "azureuser"

  network_interface_ids = [
    azurerm_network_interface.api.id,
  ]

  admin_ssh_key {
    username   = "azureuser"
    public_key = file("~/.ssh/id_rsa.pub")
  }

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "StandardSSD_LRS"
  }

  source_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-jammy"
    sku       = "22_04-lts-gen2"
    version   = "latest"
  }
}

resource "azurerm_linux_virtual_machine" "api" {
  name                = "api-vm-01"
  resource_group_name = azurerm_resource_group.api.name
  location            = azurerm_resource_group.api.location
  size                = "Standard_D4_v2"
  admin_username      = "azureuser"

  network_interface_ids = [
    azurerm_network_interface.api.id,
  ]

  admin_ssh_key {
    username   = "azureuser"
    public_key = file("~/.ssh/id_rsa.pub")
  }

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "StandardSSD_LRS"
  }

  source_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-jammy"
    sku       = "22_04-lts-gen2"
    version   = "latest"
  }
}

Standard_D4_v2 pays a higher hourly rate for an older processor and less memory. This is a common source of wasted spend in subscriptions where the VM size was set years ago and never revisited.

Compliant configuration: Azure VM on Dv5

resource "azurerm_linux_virtual_machine" "api" {
  name                = "api-vm-01"
  resource_group_name = azurerm_resource_group.api.name
  location            = azurerm_resource_group.api.location
  size                = "Standard_D8_v5"
  admin_username      = "azureuser"

  network_interface_ids = [
    azurerm_network_interface.api.id,
  ]

  admin_ssh_key {
    username   = "azureuser"
    public_key = file("~/.ssh/id_rsa.pub")
  }

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "StandardSSD_LRS"
  }

  source_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-jammy"
    sku       = "22_04-lts-gen2"
    version   = "latest"
  }
}

resource "azurerm_linux_virtual_machine" "api" {
  name                = "api-vm-01"
  resource_group_name = azurerm_resource_group.api.name
  location            = azurerm_resource_group.api.location
  size                = "Standard_D8_v5"
  admin_username      = "azureuser"

  network_interface_ids = [
    azurerm_network_interface.api.id,
  ]

  admin_ssh_key {
    username   = "azureuser"
    public_key = file("~/.ssh/id_rsa.pub")
  }

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "StandardSSD_LRS"
  }

  source_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-jammy"
    sku       = "22_04-lts-gen2"
    version   = "latest"
  }
}

resource "azurerm_linux_virtual_machine" "api" {
  name                = "api-vm-01"
  resource_group_name = azurerm_resource_group.api.name
  location            = azurerm_resource_group.api.location
  size                = "Standard_D8_v5"
  admin_username      = "azureuser"

  network_interface_ids = [
    azurerm_network_interface.api.id,
  ]

  admin_ssh_key {
    username   = "azureuser"
    public_key = file("~/.ssh/id_rsa.pub")
  }

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "StandardSSD_LRS"
  }

  source_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-jammy"
    sku       = "22_04-lts-gen2"
    version   = "latest"
  }
}

The only change is the size attribute. The StandardSSD_LRS OS disk works on both sizes, because neither Standard_D4_v2 nor Standard_D8_v5 supports Premium Storage.

Watch the naming shift. Standard_D4_v2 has 8 vCPUs, so its like-for-like Dv5 replacement is Standard_D8_v5, not Standard_D4_v5. Original D-series sizes such as Standard_D4 use the same vCPU numbering as their Dv2 counterparts.

Pick the target series by how the VM uses its local temp disk and its managed disks.

Step-by-Step Fix Instructions

1. Search Terraform for older D-series values such as Standard_D4_v2 in the size attribute of azurerm_linux_virtual_machine and azurerm_windows_virtual_machine, and in vm_size on the legacy azurerm_virtual_machine resource.

2. Check shared modules, .tfvars files, and variable defaults. Older D-series sizes often sit in a variable "vm_size" default rather than the resource block.

3. Map each older D-series size to a Dv5 size by vCPU count, not by the number in the size name.

4. Check whether the VM writes to its local temp disk (/dev/sdb or /mnt on Linux, the D: drive on Windows).

5. Choose Dv5 for Linux VMs with all data on managed disks. Choose Ddv5 for Windows VMs or any VM that uses its temp disk.

6. Confirm vCPU quota for the target family in the region. Azure assigns quota per VM family, so Dv2-series quota does not carry over to Dv5.

7. Change the size value and run terraform plan. Confirm the plan shows size as an in-place update, not a resource replacement.

8. Apply during a maintenance window. Resizing restarts the VM, and Azure may need to deallocate it if the new size is not available on the current hardware cluster.

9. Validate the workload, then add Infracost to CI/CD so new older D-series sizes are flagged in pull requests before they merge.

Best Practices

• Pin approved VM sizes in shared Terraform modules with a validation block, so older D-series sizes fail at terraform plan.

• Migrate development and staging first. A processor change rarely breaks applications, but a restart can surface boot or driver issues.

• Use plain Dv5 only for VMs on Standard HDD or Standard SSD disks. Dv5 sizes do not support Premium Storage, so pick Dsv5 or Ddsv5 when a workload needs Premium SSD.

• Review reserved instances before migrating. A reservation scoped to the Dv2-series does not cover Dv5 usage.

• Map memory-optimized sizes to Ev5, not Dv5. Older sizes such as Standard_D11_v2 to Standard_D15_v2 carry 7 GiB per vCPU, which matches the Ev5 series.

• This policy is for VMs staying on general-purpose Intel sizes. Teams that can move to AMD-based Dasv5 or Arm-based sizes may find further savings.

Tools and Scripts

How does Infracost detect older D-series sizes automatically?

The Azure D-series to Dv5 upgrade policy is available in Infracost, including in the free trial. When Infracost runs in CI/CD, it checks Azure virtual machine resources in each pull request. It flags older D-series sizes in the PR comment, with the file and line to change.

The Infracost pull request comment also explains why the best practice matters. The engineer sees the reason before merge, not in a FinOps ticket after deployment.

When FinOps policies are enabled, Infracost also scans connected repositories for older D-series sizes already in code. Platform and FinOps teams can burn down that backlog over time, tracking new issues prevented separately from existing issues fixed.

Teams can choose whether a failing pull request is blocked or only warns engineers. The message can also be customized to reference internal VM sizing standards.

To find older D-series sizes in a Terraform codebase:

grep -rnE '"Standard_D[0-9]+(_v2)?"' --include="*.tf" --include="*.tfvars"

grep -rnE '"Standard_D[0-9]+(_v2)?"' --include="*.tf" --include="*.tfvars"

grep -rnE '"Standard_D[0-9]+(_v2)?"' --include="*.tf" --include="*.tfvars"

To list Azure virtual machines still on an older D-series size with the Azure CLI:

az vm list \
  --query "[?starts_with(hardwareProfile.vmSize, 'Standard_D') && (ends_with(hardwareProfile.vmSize, '_v2') || !contains(hardwareProfile.vmSize, '_v'))].{name:name, rg:resourceGroup, size:hardwareProfile.vmSize}" \
  --output

az vm list \
  --query "[?starts_with(hardwareProfile.vmSize, 'Standard_D') && (ends_with(hardwareProfile.vmSize, '_v2') || !contains(hardwareProfile.vmSize, '_v'))].{name:name, rg:resourceGroup, size:hardwareProfile.vmSize}" \
  --output

az vm list \
  --query "[?starts_with(hardwareProfile.vmSize, 'Standard_D') && (ends_with(hardwareProfile.vmSize, '_v2') || !contains(hardwareProfile.vmSize, '_v'))].{name:name, rg:resourceGroup, size:hardwareProfile.vmSize}" \
  --output

This Azure CLI query also returns DS-series and DSv2-series sizes, which a separate DS-series policy covers. If Terraform manages the VM, change size in code rather than in the Azure portal. Otherwise the next terraform applyrestores the older size.

Examples of Impact

Savings from the Azure D-series to Dv5 upgrade scale with fleet size, because the code change per VM is a single attribute.

Illustrative example: a stateless Linux API tier. A platform team runs eight Standard_D4_v2 VMs behind a load balancer, with all data on managed disks. Moving them to Standard_D8_v5 one at a time cuts compute cost by about 34%, roughly $14,000 per year, with no downtime for users.

Illustrative example: Windows batch workers. A DevOps team runs Windows batch workers on Standard_D4_v2 and uses the D: temp drive for scratch files. The team moves to Standard_D8d_v5, which keeps a 300 GiB temp disk and still saves about 23%.

(These are illustrative scenarios, not specific customer accounts.)

Considerations and Caveats

The Azure D-series to Dv5 upgrade is low risk for most workloads, but temp disks and the smallest sizes need attention.

• Temp disk differences. Dv5 sizes have no local temp disk, and Windows cannot resize directly between sizes with and without one. Standard_D8d_v5 also has a smaller temp disk (300 GiB) than Standard_D4_v2 (400 GiB).

• No 1-vCPU Dv5 size. The smallest Dv5 size is Standard_D2_v5, so a Standard_D1_v2 has no like-for-like match and may cost more after the move.

• Restart required. Changing size restarts the VM and may deallocate it, which releases dynamic public IP addresses.

• Quota and reservations are per family. Request Dv5 or Ddv5 vCPU quota before the migration window. Plan for Dv2-series reservations to be exchanged or to expire.

• Provider-specific. This policy targets Azure Virtual Machines through the azurerm provider. AWS and Google Cloud instance generations use different names.

Related Policies and Concepts

Older Azure VM series rarely sit alone in a subscription, so these policies are usually worth enabling together.

• Azure Virtual Machines - consider upgrading DS series machines to Dv5: the same upgrade for DS-series sizes with Premium SSD support.

• Azure Virtual Machines - consider upgrading Da (AMD x64) series machines to Dav5: the AMD-based equivalent of moving off an older general-purpose Azure VM series.

• Azure Virtual Machines - consider upgrading E series machines to Ev5: the memory-optimized equivalent of this policy.

• Azure Virtual Machines - Consider using a preferred instance type: a Compute-group policy that restricts Azure VM sizes to an approved list, which can also block older D-series sizes.

• Azure Virtual Machines - consider using Azure Hybrid Benefit for Windows VMs: a related policy that lowers Windows VM licensing cost without changing the VM size.

Frequently Asked Questions (FAQs)

Is this policy supported in Infracost?

Yes. The Azure D-series to Dv5 upgrade policy is supported in Infracost and available in the free trial. Infracost flags Azure virtual machine resources using an older D-series size in pull requests, so the team can change the size before merge.

Can this policy be customized?

Yes. Teams can configure how Infracost enforces the Azure D-series to Dv5 upgrade policy. A failing pull request can be blocked or only warn engineers, and the message can reference internal VM sizing standards.

Does Infracost automatically fix violations?

No. Infracost reports each older Azure D-series size in the pull request with the file and line to change. Choosing between Dv5 and Ddv5 depends on whether the workload needs a local temp disk, so the team makes that decision.

Is this policy cloud-agnostic?

No. The Azure D-series to Dv5 upgrade policy targets Azure Virtual Machines through the azurerm Terraform provider. AWS and Google Cloud have their own instance generations, with different resource and attribute names.

Which Dv5 size replaces Standard_D4_v2?

Standard_D8_v5, or Standard_D8d_v5 when a temp disk is needed. Standard_D4_v2 has 8 vCPUs, so the Azure Dv5 replacement with the same vCPU count is the 8-vCPU size, not Standard_D4_v5.

When will Azure retire the D-series and Dv2-series?

Microsoft lists May 1, 2028 as the retirement date for the Azure D-series and Dv2-series. After that date, remaining Azure D-series VMs are deallocated, and temp disk data is lost while managed disk data is preserved.

How often should I review Azure VM series for upgrades?

Teams running Infracost in CI/CD get an Azure D-series check on every pull request that touches an Azure virtual machine resource. For existing Azure VMs, a quarterly review against Microsoft's retirement announcements is a reasonable cadence.