Azure VM naming and sizing feels unnecessarily difficult to navigate. There are broad families for general-purpose, memory-optimized, storage-optimized, GPU, and other workloads, followed by codes for CPU vendor, vCPU count, local or temporary storage, generation, and additional capabilities. The documentation explains parts of the naming scheme, but it does not always appear to match the sizes shown when creating a VM, and some available options do not seem to follow the documented patterns.
What is a practical way to narrow down the choices and select an appropriate VM size? Do most people rely on a few familiar families, or is there a straightforward workflow or reference for choosing based on workload requirements such as CPU, memory, storage, burstability, and GPU needs?
3 Answers
A simple first pass is to use B for burstable workloads, D for general-purpose workloads, and E when the workload needs a higher memory-to-CPU ratio. Letters such as A can indicate an AMD-based option, while an S commonly indicates support for premium storage. The exact suffixes vary by generation, so use the documentation to confirm the capabilities rather than treating the name as a complete specification.
The naming itself is only part of the problem. Pay attention to generation, image compatibility, trusted-launch support, required marketplace plans, regional availability, and whether the VM has a local temporary disk. Those details can matter during migrations, especially when moving between models with and without local storage. In practice, teams usually standardize on a few suitable sizes, test them, and revisit the choice when performance, availability, or pricing changes.
You generally do not need to learn every SKU. Start with the workload category and eliminate everything irrelevant: skip GPU families unless you need GPU compute, skip storage-heavy options unless local storage matters, and so on. For ordinary workloads, the B, D, and E families cover a lot of cases. Choose a reasonable starting size, monitor CPU, memory, disk, and network usage, then resize based on actual behavior and cost.
The key decision is the workload, not memorizing the names. Once you know whether you need burstable performance, more memory, local storage, or a particular CPU vendor, the list becomes much smaller.