Azure VM Sizes & Series

Which Azure VM size should you choose? The letter in the name tells you

By Captain O7 min read

The size picker in the portal has hundreds of options with names like Standard_D4s_v5 and Standard_E8ds_v5, and most people scroll until something looks big enough — which is how you end up paying for RAM you never touch, or throttling a database that needed it.

New to cloud? CAMPUX is a free, build-first course. Start here →

An Azure VM size is a hardware recipe: a fixed ratio of vCPUs to memory, plus what disks, network, and accelerators the machine gets. Microsoft groups those recipes into types by intended workload — general purpose, compute optimized, memory optimized, storage optimized, GPU, and high performance compute — and each type is made of families named by a single letter. Once you can read that letter, the wall of options collapses into a short list. You are not memorizing sizes. You are learning to recognize which family fits the job, then picking a size inside it.

This is a money decision. You pay for the whole recipe every hour the VM runs, whether or not you use it. Pick a memory-optimized machine for a web server that is all CPU and no state, and you rent gigabytes of RAM that sit idle — real money, every hour, for nothing. Go the other way and put a memory-hungry database on a balanced size that is short on RAM, and it spills to disk, latency climbs, and you are firefighting a performance problem that was a sizing mistake. Right-sizing is the most common way a cloud bill leaks, and the fix starts before you deploy: know what the workload is bound by, then choose a family built for that.

The family map: one letter, one job

Here is the whole landscape in the language you will actually see in the portal. Each family is a letter; the type tells you the CPU-to-memory balance it is built around.

General purpose (B, D, A, DC) — balanced CPU-to-memory. The D-family is the sensible default for web servers, app servers, and small-to-medium databases. The B-family is burstable and cheap (more on it below). A is entry-level and economical; DC adds hardware-based confidential computing for sensitive data.
Compute optimized (F) — high CPU relative to memory. The F-family is for CPU-bound work: busy web front ends, batch processing, application servers, and analytics that crunch more than they remember.
Memory optimized (E, M) — high memory relative to CPU. The E-family is the workhorse for relational databases, caches, and in-memory analytics. The M-family goes to the extreme — the biggest RAM sizes Azure offers, for SAP HANA and large in-memory databases.
Storage optimized (L) — high local disk throughput and IOPS. The L-family is for big data, NoSQL stores like Cassandra and MongoDB, data warehousing, and anything that reads and writes local disk hard.
GPU (N-series: NC, ND, NV) — machines with attached GPUs. NC and ND are for compute: model training and inference, HPC with GPU acceleration. NV is for graphics: virtual desktops, 3D rendering, and visualization.
High performance compute (H) — the H-family, built for tightly coupled HPC and simulation: fluid dynamics, weather modeling, molecular work, often with fast interconnects between nodes.

You do not choose from hundreds of sizes. You choose one letter for the shape of the work, and the size only sets how much of it.

Figure — VM series are just presets on two axes: how much vCPU and how much memory you get per core. B is burstable and cheap for bursty dev/test; D is the balanced general-purpose default; E is memory-optimised for databases and caches; F is compute-optimised for CPU-bound work; N carries GPUs for AI and rendering. Pick the family by the shape of your workload first, then the number for the size.

How to read the name

The size name packs the whole recipe into a short string. Take Standard_D4s_v5. Standard is the tier. D is the family — general purpose, balanced. 4 is the number of vCPUs. The lowercase letters are a sub-family of features: s means premium-SSD capable, d means it has a local temp disk, a often means an AMD processor. v5 is the version — the hardware generation, where higher is newer and usually gives you more performance per dollar. So Standard_E8ds_v5 reads as: general memory-optimized family, 8 vCPUs, with local disk and premium storage, generation 5. You do not need the exact vCPU and RAM figures in your head — those change and are one click away in the portal. What lasts is the grammar: family letter, size number, feature letters, version.

The B-series: paying for the average, not the peak

The B-family deserves its own note because it bills on a different idea. Most VMs give you a fixed fraction of a core all the time and charge for it all the time. A B-series VM is burstable: it runs at a low baseline and earns CPU credits while it sits under that baseline. When traffic spikes, it spends those credits to run at full speed, then coasts back to earning. That makes it cheap and correct for workloads with a low average and occasional peaks — small web servers, dev and test boxes, low-traffic APIs, build agents. The trap is running a B-series under a sustained heavy load: it burns through its credits, then throttles down to baseline and stays there. B-series rewards spiky, idle-most-of-the-time work and punishes anything that is busy all day.

The practical method — start from the bottleneck

Do not start from the size list. Start from the workload and ask what limits it. Is it CPU-bound (compute, transcoding, request-heavy front ends)? Reach for F, or D if it is balanced. Is it memory-bound (a database, a big cache, in-memory analytics)? Reach for E, or M at the extreme. Is it disk-bound (local throughput and IOPS)? Reach for L. Does it need a GPU? N-series. Only after the family is settled do you pick a size number, and you start smaller than you think. Then you right-size from real metrics — watch CPU, memory, and disk over a week or two and move up or down. The first pick is a hypothesis; the metrics settle it.

Where sizing meets the rest of your bill

Sizing is one lever; it works with the others. A right-sized family stops you renting hardware you never use, but pair it with autoscaling so you run the right number of those VMs as load moves through the day, and with the broader habits in cutting your Azure costs — reservations for steady workloads, shutting down what runs nightly, and reviewing the metrics you swore you would check. Picking the family is the decision that shapes everything downstream: get the shape right first, then tune the count and the commitment.

The takeaway

Azure groups VMs by the balance the workload needs, and the family letter names it: D and B for general purpose, F for CPU, E and M for memory, L for disk, N for GPU, H for HPC. Read the name as family, size, features, version, and the portal stops being a wall. Choose from the bottleneck — CPU-bound, memory-bound, or disk-bound — pick a family, pick a modest size, and let real metrics right-size it from there. "D for balanced, E when it is the database, F when it is the CPU, B for the spiky little box, and let the metrics move it" is how someone who has paid a few oversized bills talks about it.

Questions people also ask

What do the letters in an Azure VM size name mean?

Each letter names a family built for a workload shape. B and D are general purpose, F is compute optimized, E and M are memory optimized, L is storage optimized, N carries GPUs, and H is high performance compute. You read a name as family letter, size number, feature letters, then version, so the family tells you what the machine is for.

What is a B-series Azure VM?

A B-series VM is burstable. It runs at a low baseline and earns CPU credits while it sits under that baseline, then spends those credits to run faster when load spikes. That fits web servers, dev and test boxes, and low-traffic apps that idle most of the time. Run it under sustained heavy CPU and it exhausts its credits and throttles back.