Azure VM series decoded: B, D, E, F and when each is the cheap answer

Standard_D4ads_v5 looks like a licence plate. It is actually a compact description of exactly what you are renting, and the Azure VM series letter is the part that matters most, and reading it is the fastest way to stop over provisioning.

Breaking the name apart

Working through Standard_D4ads_v5:

• D is the family. General purpose.
• 4 is the vCPU count.
• a is the processor. AMD, in this case. No letter usually means Intel, and p means an ARM part.
• d means a local temporary disk is attached.
• s means premium storage capable.
• v5 is the generation.

Other suffixes appear: m for extra memory, l for less memory, t for a smaller memory ratio, i for isolated hardware, NP for FPGA. You rarely need all of them, but knowing the pattern means an unfamiliar size stops being opaque.

The Azure VM series families

B, burstable. A baseline fraction of a core with credits accrued while idle. Genuinely cheap for development machines, low traffic sites and jump boxes. Watch the credit balance in metrics; a B series machine that runs out of credits is slower than the size suggests.

D, general purpose. Roughly 4 GB of memory per vCPU. The default choice for application servers, small databases and most web workloads.

F, compute optimised. Around 2 GB per vCPU with higher clock parts. Batch processing, encoding, application servers that are genuinely CPU bound.

E, memory optimised. Around 8 GB per vCPU. Databases, caches, analytics that hold a working set in memory.

L, storage optimised. Large local NVMe throughput. Suitable for databases that stage locally and for high IOPS workloads where remote disks are the constraint.

M, memory intensive. Very large memory footprints for SAP HANA and similar. Priced accordingly.

N, accelerated. NC for compute and inference, ND for large scale training, NV for visualisation and virtual desktops. These families frequently sit at a zero quota on new subscriptions, so confirm availability before designing around them.

Intel, AMD or ARM

Most families now offer all three. AMD variants generally price slightly below the Intel equivalent for similar throughput. ARM variants, marked with a p, offer the best price for performance where the software runs, which covers most Linux workloads, containers built for multiple architectures and standard runtimes.

The migration question is the same as it is on AWS Graviton: check for x86 only binaries in your dependency tree, then benchmark. Where it works, it usually wins.

Disks are a separate decision

A common source of disappointing VM performance is the disk, not the machine. Azure managed disks come in Standard HDD, Standard SSD, Premium SSD, Premium SSD v2 and Ultra Disk, and each tier has its own IOPS and throughput characteristics tied to provisioned size.

Two consequences:

• On the older Premium SSD tiers, performance scales with disk size, so a small disk can bottleneck a large VM. Premium SSD v2 decouples this and lets you set IOPS independently, which is often both faster and cheaper.
• The VM size itself caps disk throughput. Attaching a very fast disk to a small VM does not produce a fast machine.

A quick decision path

1. Development box, low traffic site, bastion host: B series.
2. General application server: D series, current generation, AMD or ARM if the stack allows.
3. CPU bound work: F series, and confirm the job is not actually single threaded.
4. Database or cache: E series, sized to the working set.
5. GPU work: N series, and check the quota before anything else.

Once the size is settled, the purchasing mechanism is where the real money is. That is covered in how Azure pricing works. For the equivalent naming scheme on the other major clouds, see EC2 instance families and Compute Engine machine types.