I used to work in IT asset management, so I'm familiar with complicated licensing systems. Azure VM sizing feels similarly overwhelming. There are broad families for general-purpose, memory-optimized, storage-optimized, GPU, and other workloads, followed by indicators for CPU vendor, vCPU count, local or temporary storage, generation, and additional features.
I understand the general naming convention, but I'm struggling to turn it into a practical decision process. The documentation gives a high-level overview, yet it doesn't always seem to list every size available in the portal, and some names don't appear to follow the convention consistently. The portal also recommends sizes with prefixes such as "Standard_," which adds to the confusion.
How do you usually narrow down the choices? Is there a straightforward way to start with workload requirements and arrive at a sensible VM family and size? Do most people simply standardize on a few common families, such as B, D, or E, and adjust after monitoring performance?
4 Answers
The naming becomes more useful if you treat it as a set of filters. First choose the CPU-to-memory ratio you need, then check whether you need a temporary local disk, a particular CPU vendor, premium storage support, or a specific generation. For example, E generally points toward memory-heavy machines, D toward general purpose, and B toward burstable compute. An “a” suffix commonly indicates AMD, while an “s” indicates support for premium storage. The exact letters can vary by family, so use the name as a shortcut and verify the selected SKU’s capabilities before deploying.
The tricky parts usually appear after you have chosen a family: generation compatibility, image support, trusted launch, marketplace plans, regional availability, and whether a VM has local temporary storage. Those details can matter during migration or resizing, especially when moving between models with and without local disks. A practical approach is to shortlist two or three candidates, compare their actual capabilities and price in the target region, deploy one, and validate it with monitoring rather than trying to solve the whole catalog up front.
You do not need to learn every available size. Azure has to offer many combinations because the requirements vary so widely, and the catalog changes over time. In practice, teams often standardize on a small set of families and sizes, then keep a few alternatives for regional capacity, pricing, or special requirements. The portal’s recommendations are a starting point, not a requirement to understand the entire catalog.
Most workloads can be narrowed down by starting with the workload rather than the full SKU catalog. Skip GPU, HPC, storage-optimized, and other specialized families unless you have a specific reason to use them. For ordinary servers, B, D, and E cover a lot of cases: B is useful for burstable workloads, D is general purpose, and E is for workloads that need more memory. Pick a reasonable starting size, monitor CPU, memory, disk, and network usage, then resize if the metrics show a problem.
The important decision is the workload category, not memorizing every individual VM name. Once you land on a family, choose the standard option unless you need a particular CPU vendor, storage feature, GPU, or other capability.