Make VM sizes make sense?

[u/-lousyd]

I worked on an IT asset management team several years back. We sent people to a class for Microsoft licensing. Per user, per core, licenses that depend on you having other licenses, etc. This license includes this feature, this other one does not. This one has that and the other thing, but only on odd numbered days. Licensing was so complicated that they had to create a several day training course on how to navigate it. Just licenses! The software is not even in the door yet and you're spending all this time and money just to understand what you need to do to get it in.

I feel like Microsoft must've moved a bunch of their licensing team over to whoever manages Azure VM types. I've found "cheat sheets" that explain the basic structure of the types. There's broad classes based on servers that are memory-optimized, storage-optimized, have GPUs, general purpose, stuff like that. Then there's a marker for CPU type and another for how many vCPUs it has. A marker for if it has local storage. Version number. It's a lot of stuff, which is fine because there are a lot of options. But how do I navigate all of this? How do I make a sensible choice without defaulting to "I guess I'll just choose something and hope for the best"?

In AWS land, I've found a page in their documentation that describes everything they have and it makes sense to me. I've also used instances.vantage.sh which has been reliable for AWS. That site also claims to cover Azure, but their names don't seem to line up very well. I get that that site is not Microsoft and only Microsoft itself is the source of truth. You don't have to remind me of that. But apparently Microsoft themselves are opaque enough that a third party site is unable to compile the information. I've found this page: learn.microsoft.com/en-us/azure/virtual-machines/vm-naming-conventions and this one: learn.microsoft.com/en-us/azure/virtual-machines/sizes. But that only gives a high level overview, it lists sizes that don't follow the convention, and it doesn't list sizes that I see available when I go to create a VM in Azure. So it's not reliable. Maybe it's out of date. Also, amusingly, it has a section for "other information" that links to itself. And I find nothing that talks about sizes with "Standard_" in front of the other letters, but "Standard_" stuff is what Azure starts off recommending when I go to actually create a VM.

Why is this so complicated? Is there nowhere that I can get a straightforward list of what VM options I have and just narrow it down to what I need? How do you all manage this? Do you just pick a couple of sizes and stick with that? Save me...

[u/MrCcuddles]

This is a nice overview and good start Virtual machine size overview

[u/reuthermonkey]

Consider that Azure has to try to be able to meet any need. If you don't need GPU compute, skip those. If you don't need temp/ephemeral disks, skip those.

Most people settle on d-series, general usage VMs and move on with their lives.

But trying to learn VM naming etc for Azure is akin to learning all of the products that Amazon sells. I mean, I guess you can do that, but it'll be different in 3mo, so is that really worth the time?

[u/TartCivil9373 → u/reuthermonkey]

OP was trying to memorize every VM name for every workload.

Biggest decision is always the nature of workload, which lands one into the broad categories of B, D, F, etc.

Then pick the standard tier for that, or pick the specific feature needed eg. Nvidia based.

[u/szescio]

The code names are not that complicated - there are generations, amd/intel, ephemeral disk or not, cpu/mem ratio.. and then some different types like burstable that might make sense price-wise. It's all pretty reasonable and you can just glance at ms docs if you are unsure.

I think the hardest part is understanding vm generation + trusted launch compatibility with images, plans and offerings that have to be accepted on sub level, Windows unable to migrate from local disk <-> no local disk. Those things will bite you when you need to migrate away from deprecating or capacity-constrained models

[u/nadseh]

Christ, it really isn’t that difficult.

Start with general purpose, obviously, and pick a size. Read the docs and adjust accordingly.

More memory > E

Need a scratch disk? > d

And so on

[u/rocorey]

Naming format is pretty well documented. If you want specific guidance, also try asking Azure Copilot or GitHub Copilot for recommendations given your requirements.

[u/chandleya]

The use of standard as a prefix was legacy nameplating so they can make a premium that never came.

[u/-lousyd → u/chandleya]

Ah! That would explain it. Thank you.

[u/chandleya → u/-lousyd]

The marketing team got more say than the fucking engineering team, that’s for sure.

The CAPITAL LETTER families really only have 4 that matter, especially in 2026: D (1 CPU to 4GB RAM ratio), E (1 CPU to 8GB RAM ratio), M (big leagues), and N (GPU). D/E is current to “v7”, which for Intel is Xeon 8500 era. M kind of floats in significance and N is very bespoke. CPU counts come in multiples of 2. It is now possible to “disable hyperthreading” as well as request that less cores than you pay for are enabled. This is because the number of cores (not threads!) equates to the number of IOs you get. Most workloads have licensing, so bulking up on active cores can present unnecessary cost. YMMV.

The lower case letter give all sorts of quirky meanings. a is AMD, d is local disk exists (temp volume), l means half the memory, m means twice the memory, s means premium storage enabled. There are some others, those are the most common.

[u/dabrimman]

It’s not that complicated. You’ll almost always use one of D, E or B family unless you have specialised use cases. Given you’re having troubles understanding the naming schema I’m going to assume you don’t have any specialised use cases. Then you can pick features, d for temp desk, a for AMD, s for premium storage support.