Azure Virtual Machines – Consider Upgrading DS Series Machines to Dv5

The Azure DS-series to Dv5 upgrade policy flags Azure Virtual Machines running an original DS-series size and recommends the Dsv5 or Ddsv5 series instead. A Dsv5 or Ddsv5 VM with the same vCPU count costs about 27% to 38% less per month in East US and runs on a newer Intel Xeon processor. Apply this policy to any azurerm_linux_virtual_machine or azurerm_windows_virtual_machine whose size is a DS-series value such as Standard_DS4.

Why This Policy Matters

How It Helps Reduce Cloud Costs

The Azure DS-series is one of the original general-purpose VM families with Premium SSD support. Azure has since released several newer generations of the same general-purpose family.

Each newer generation runs on faster processors and is usually priced lower per vCPU. Staying on the DS-series means paying more for older hardware.

The Dsv5 series runs on Intel Xeon Platinum Ice Lake or newer processors with an all-core turbo of 3.5 GHz. A Standard_D8s_v5 also gives 32 GiB of memory against 28 GiB on a Standard_DS4.

This is a common source of wasted spend in long-lived Azure subscriptions. The VM size was chosen years ago and nobody revisited it.

There is also a deadline. Microsoft lists May 1, 2028 as the retirement date for the D-series and DS-series, after which remaining VMs are deallocated.

Potential Savings

The Azure DS-series to Dv5 upgrade saves money because Dsv5 and Ddsv5 sizes cost less than the DS-series size they replace.

Moving one Standard_DS4 to Standard_D8s_v5 cuts its compute cost by about 38%, or roughly $2,000 per year. Moving it to Standard_D8ds_v5 cuts it by about 27%, or roughly $1,400 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 DS-series VM in the estate. A fleet of 20 Standard_DS4 VMs moved to Dsv5 saves roughly $40,000 per year at these list prices.

Implementation Guide

Infrastructure-as-Code Example (Terraform)

The following examples show an Azure Linux virtual machine on a DS-series size, and the corrected Dsv5 configuration.

Non-compliant configuration: Azure VM on a DS-series size

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

  network_interface_ids = [
    azurerm_network_interface.app.id,
  ]

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

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

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

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

  network_interface_ids = [
    azurerm_network_interface.app.id,
  ]

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

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

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

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

  network_interface_ids = [
    azurerm_network_interface.app.id,
  ]

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

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

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

Standard_DS4 pays a premium for an older processor and less memory. This configuration costs more every month than a newer size with the same vCPU count.

Compliant configuration: Azure VM on Dsv5

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

  network_interface_ids = [
    azurerm_network_interface.app.id,
  ]

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

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

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

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

  network_interface_ids = [
    azurerm_network_interface.app.id,
  ]

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

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

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

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

  network_interface_ids = [
    azurerm_network_interface.app.id,
  ]

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

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "Premium_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. Standard_D8s_v5 keeps Premium SSD support, so the Premium_LRS OS disk works without changes.

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

Step-by-Step Fix Instructions

1. Search Terraform for DS-series sizes 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. DS-series sizes often sit in a variable "vm_size"default rather than the resource block.

3. For each match, check whether the VM writes to its local temp disk (/dev/sdb or /mnt on Linux, the D: drive on Windows).

4. Choose Dsv5 for Linux VMs with all data on managed disks, and Ddsv5 for Windows VMs or any VM that uses its temp disk. Match vCPU count first, then confirm the extra memory does not change application tuning.

5. Confirm vCPU quota for the Dsv5 or Ddsv5 family in the target region. Azure assigns quota per VM family, so DS-series quota does not carry over.

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

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

8. Validate the workload, then add Infracost to CI/CD so new DS-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 DS-series sizes fail at terraform plan.

• Migrate development and staging first. Processor and memory changes rarely break applications, but a restart can surface boot or driver issues.

• Keep Dv5 without the "s" (for example Standard_D8_v5) for VMs with no Premium SSD disks only. Dv5 sizes do not support Premium Storage.

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

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

Tools and Scripts

How does Infracost detect DS-series sizes automatically?

The Azure DS-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 DS-series sizes in the PR comment, with the file and line to change.

The same Infracost pull request comment shows the estimated monthly cost of the resources in the change. Reviewers see the cost of a Standard_DS4 before it merges, not on next month's invoice.

Infracost also scans connected repositories for DS-series sizes already in code. FinOps and platform teams can burn down that backlog over time, tracking new issues prevented separately from existing issues fixed.

Teams can set the policy to warn engineers or to block pull requests that fail it, and can limit it to new resources only.

To find DS-series sizes in a Terraform codebase:

grep -rnE '"Standard_DS[0-9]+"' --include="*.tf" --include="*.tfvars"

grep -rnE '"Standard_DS[0-9]+"' --include="*.tf" --include="*.tfvars"

grep -rnE '"Standard_DS[0-9]+"' --include="*.tf" --include="*.tfvars"

To list Azure virtual machines still on a DS-series size with the Azure CLI:

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

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

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

If a VM is managed by Terraform, change size in code rather than resizing it in the portal. Otherwise the next terraform apply sets the DS-series size again.

Examples of Impact

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

Illustrative example: a stateless web tier. A platform team runs six Standard_DS4 VMs behind a load balancer, with all data on managed disks. Moving them to Standard_D8s_v5 one at a time cuts compute cost by about 38% with no downtime for users.

Illustrative example: a Windows build agent pool. A DevOps team runs Windows build agents on Standard_DS4 and uses the D: temp drive for build caches. The team moves to Standard_D8ds_v5, which keeps a larger 300 GiB temp disk and still saves about 27%.

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

Considerations and Caveats

The Azure DS-series to Dv5 upgrade is low risk, but the temp disk is where migrations go wrong.

• Temp disk differences. Dsv5 sizes have no local temp disk. Windows VMs cannot resize from a size with a temp disk to one without, so use Ddsv5 for Windows.

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

• Reservations do not move automatically. Existing DS-series reserved instances need to be exchanged or allowed to expire.

• Quota is per family. Request Dsv5 or Ddsv5 vCPU quota before the migration window.

• 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

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

• Azure Virtual Machines - consider upgrading E series machines to Ev5: the memory-optimized equivalent of moving off an older Azure VM series.

• Azure Virtual Machines - consider upgrading ND series machines to NCas T4 v3 or NDamsr A100 v4: a Compute-group policy for the GPU sizes Azure has already retired.

• 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 DS-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 DS-series to Dv5 upgrade policy is supported in Infracost and available in the free trial. Infracost flags Azure virtual machine resources using a DS-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 DS-series to Dv5 upgrade policy. For example, a finding can warn engineers or block the pull request, and can apply to new resources only.

Does Infracost automatically fix violations?

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

Is this policy cloud-agnostic?

No. The Azure DS-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.

Should I choose Dsv5 or Ddsv5 when replacing an Azure DS-series VM?

Choose Dsv5 when the workload keeps all data on managed disks. Choose Ddsv5 when the Azure DS-series VM uses its local temp disk for scratch data, caching, or a page file, or when it runs Windows.

When will Azure retire the DS-series?

Microsoft lists May 1, 2028 as the retirement date for the Azure D-series and DS-series. After that date, remaining Azure DS-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 DS-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.