Azure Virtual Machines – Consider Upgrading G Series Machines to Ev5

The Azure G-series to Ev5 upgrade policy flags Azure Virtual Machines on G-series sizes, such as Standard_G4, and recommends an Ev5 or Edv5 size instead. A Standard_E32_v5 costs about 54% less per month than a Standard_G4 in East US 2, with more vCPUs and more memory. Apply this policy to any azurerm_linux_virtual_machine or azurerm_windows_virtual_machine whose size is a G-series value.

Why This Policy Matters

How It Helps Reduce Cloud Costs

The Azure G-series is one of Azure's earliest memory-optimized VM families. It launched in 2015 on Intel Xeon E5 v3 (Haswell) processors, with up to 448 GiB of memory and a very large local SSD.

The Ev5 series is the current-generation memory-optimized family. It runs on 3rd Generation Intel Xeon Platinum (Ice Lake) processors with an all-core turbo of up to 3.5 GHz.

Staying on a G-series size means paying a premium rate for decade-old hardware. This configuration increases costs without improving performance.

The G-series is also on a fixed retirement path. Microsoft has announced capacity growth restrictions for the G-series starting July 2026, and new subscriptions cannot deploy G-series sizes.

The hard deadline is November 15, 2028. After that date, Microsoft deallocates remaining Azure G-series VMs, and they stop working.

Potential Savings

The Azure G-series to Ev5 upgrade saves money because an Ev5 size with the same or more memory costs far less than the G-series size it replaces.

Moving one Standard_G4 to Standard_E32_v5 cuts its compute cost by about 54%, or roughly $20,880 per year. Moving it to Standard_E32d_v5 cuts it by about 48%, or roughly $18,360 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.

G-series VMs are expensive individually, so even a small fleet adds up. Five Standard_G4 VMs moved to Standard_E32_v5 save roughly $104,000 per year at these list prices.

Implementation Guide

Most of the work in an Azure G-series to Ev5 migration is choosing the right target size and handling the local disk. The Terraform change itself is a single attribute.

Infrastructure-as-Code Example (Terraform)

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

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

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

  network_interface_ids = [
    azurerm_network_interface.cache.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"
    version   = "latest"
  }
}

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

  network_interface_ids = [
    azurerm_network_interface.cache.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"
    version   = "latest"
  }
}

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

  network_interface_ids = [
    azurerm_network_interface.cache.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"
    version   = "latest"
  }
}

Standard_G4 pays more than twice the Ev5 rate for an older processor and less memory. This is a common source of wasted spend in subscriptions where a large memory-optimized VM was sized years ago and never revisited.

Compliant configuration: Azure VM on Ev5

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

  network_interface_ids = [
    azurerm_network_interface.cache.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"
    version   = "latest"
  }
}

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

  network_interface_ids = [
    azurerm_network_interface.cache.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"
    version   = "latest"
  }
}

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

  network_interface_ids = [
    azurerm_network_interface.cache.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"
    version   = "latest"
  }
}

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

Map by memory, not by the number in the size name. G-series sizes carry 14 GiB of memory per vCPU, while Ev5 sizes carry 8 GiB per vCPU, so the matching Ev5 size has twice the vCPU count.

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 G-series values such as Standard_G4 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. G-series sizes often sit in a variable "vm_size"default rather than the resource block.

3. Map each G-series size to an Ev5 size by memory, using the table above as a starting point.

4. Measure how much of the local temp disk the VM actually uses (/mnt or /dev/sdb on Linux, the D: drive on Windows). Edv5 temp disks are less than half the size of G-series temp disks.

5. Choose Ev5 for Linux VMs with all data on managed disks. Choose Edv5 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, and the Ev5 target needs twice the vCPU quota of the G-series size it replaces.

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. The G-series runs on older hardware clusters, so expect Azure to deallocate the VM during the resize.

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

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

• Copy anything stored on the G-series temp disk to a managed disk before resizing. Temp disk data does not survive a deallocation.

• Check per-core software licensing before doubling vCPUs. If a license is billed per vCPU, a constrained vCPU size such as Standard_E32-16ds_v5 keeps 256 GiB of memory with 16 active vCPUs.

• Review reserved instances before migrating. Microsoft's modernization guide lists July 1, 2026 as the one-year reservation expiration for the G-series, so remaining G-series VMs fall back to pay-as-you-go pricing.

• This policy is for workloads that need memory, not local storage. Workloads built around the G-series multi-terabyte SSD may fit the Lsv3 series better than Ev5.

Tools and Scripts

How does Infracost detect G-series sizes automatically?

The Azure G-series to Ev5 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 G-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 G-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 G-series sizes in a Terraform codebase:

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

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

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

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

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

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

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

This Azure CLI query excludes GS-series sizes, which a separate GS-series policy covers. If Terraform manages the VM, change size in code rather than in the Azure portal. Otherwise the next terraform apply restores the G-series size.

Examples of Impact

Savings from the Azure G-series to Ev5 upgrade are large per VM, because G-series list prices are more than double the Ev5 rate for similar memory.

Illustrative example: an in-memory cache tier. A platform team runs three Standard_G4 Linux VMs for an in-memory cache, with persistent data on managed disks. Moving them to Standard_E32_v5 one at a time cuts compute cost by about 54%, roughly $62,600 per year at East US 2 list prices.

Illustrative example: Windows analytics workers. A DevOps team runs Windows analytics workers on Standard_G3and uses the D: temp drive for intermediate files. The team moves to Standard_E16d_v5, which keeps a 600 GiB temp disk, after confirming the jobs never use more than that.

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

Considerations and Caveats

The Azure G-series to Ev5 upgrade is low risk for memory-bound workloads, but local storage and licensing need attention.

• Much smaller temp disks. Ev5 sizes have no local temp disk, and Edv5 temp disks are less than half the G-series size. Windows cannot resize directly between sizes with and without a temp disk.

• Double the vCPUs. Matching G-series memory on Ev5 doubles the vCPU count, which affects quota and any per-core software licensing.

• Fewer data disk slots. Standard_G4 and Standard_G5 support up to 64 data disks, while Standard_E32_v5 and Standard_E64_v5 support up to 32. Consolidate data disks before the move if a VM uses more than 32.

• Deallocation required. Changing size from a G-series VM typically deallocates it, which releases dynamic public IP addresses and clears the temp disk.

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

• Provider-specific. This policy targets Azure Virtual Machines through the azurerm provider. AWS and Google Cloud memory-optimized 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 GS series machines to Esv5 or Mv3: the same upgrade for GS-series sizes with Premium SSD support.

• Azure Virtual Machines - consider upgrading E series machines to Ev5: the policy for older memory-optimized E-series sizes that share the same Ev5 target.

• Azure Virtual Machines - consider upgrading D series machines to Dv5: the general-purpose equivalent of moving off an older Azure VM series.

• Azure Virtual Machines - consider upgrading Ls series machines to Lsv2: a related upgrade for storage-optimized VMs, relevant when a G-series workload depends on local storage.

• 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 G-series sizes.

Frequently Asked Questions (FAQs)

Is this policy supported in Infracost?

Yes. The Azure G-series to Ev5 upgrade policy is supported in Infracost and available in the free trial. Infracost flags Azure virtual machine resources using a G-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 G-series to Ev5 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 Azure G-series size in the pull request with the file and line to change. Choosing between Ev5 and Edv5 depends on whether the workload needs a local temp disk, so the team makes that decision.

Is this policy cloud-agnostic?

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

Which Ev5 size replaces Standard_G4?

Standard_E32_v5, or Standard_E32d_v5 when the workload needs a local temp disk. Standard_G4 has 224 GiB of memory, so the closest Azure Ev5 replacement by memory is the 32-vCPU size with 256 GiB.

When will Azure retire the G-series?

Microsoft lists November 15, 2028 as the retirement date for the Azure G-series and GS-series. After that date, remaining Azure G-series VMs are deallocated and stop working.

How often should I review Azure VM series for upgrades?

Teams running Infracost in CI/CD get an Azure G-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.