Older VM series still running in Azure
A server on older hardware than Azure offers today
Why it happens
Azure keeps releasing newer models and never moves you. The same size on newer hardware is often faster and cheaper.
Azure ships newer hardware generations and never migrates existing machines. A v3 VM keeps running on v3 pricing even when the same size on v5 performs the same or better for the same money or less.
Paste this into Resource Graph Explorer in the Azure portal.
resources
| where type =~ 'microsoft.compute/virtualmachines'
// Scope below matches CloudFinOpsPro policy DEFAULTS: exclusions.protectTag, environment.tagKeys,
// environment.allowedTagValues, and allowUntagged false so an untagged resource counts as production.
// If your policy.yaml differs, edit the three lines below or this will disagree with your own agent.
| where tolower(tostring(coalesce(tags['cfop:protect'], ''))) !in ('true', 'yes', '1')
| extend cfopEnv = tolower(trim(' ', tostring(coalesce(tags['Environment'], tags['environment'], tags['env'], ''))))
| where cfopEnv in ('dev', 'development', 'test', 'qa', 'sandbox', 'nonprod', 'non-prod', 'staging')
| extend size = tostring(properties.hardwareProfile.vmSize)
// The sizes the agent can actually propose an upgrade for, which is narrower than
// every v3 or v4 machine: newerSeries only returns a target the size ladder knows.
| where size in~ (
'Standard_D2s_v3',
'Standard_D4s_v3',
'Standard_D8s_v3',
'Standard_D16s_v3',
'Standard_D2s_v4',
'Standard_D4s_v4',
'Standard_D8s_v4',
'Standard_D16s_v4',
'Standard_E2s_v3',
'Standard_E4s_v3',
'Standard_E8s_v3',
'Standard_E16s_v3'
)
| project name, resourceGroup, location, size
| order by size ascEvery row here is a size the agent carries a v5 equivalent for, and this list is the agent's coverage rather than Azure's. A v3 or v4 machine NOT listed, which includes every non-s size such as Standard_D4_v3 and every AMD a-suffixed size such as Standard_E8as_v4, may still have a cheaper v5 equivalent; the agent simply does not carry that size in its ladder yet and will not report it, so an earlier version of this query that matched every _v3 and _v4 machine returned a long list the agent would never act on. Check the target size is offered in your region before moving, and note the check additionally requires the v5 price to be at or below the current one, which is a pricing test no Resource Graph query can make.
Applies to microsoft.compute/virtualmachinesWhat the agent does about it
A VM running a v3 or v4 series where the same size on v5 costs the same or less.
It will not fix this one
It finds it and tells you what to change. The change itself is yours to make, because it is not one the agent should make on your behalf.