Azure VM Sizing Demystified

How families, series, and sizes map to actual Azure VM capabilities

What We’re Going to Cover

How Azure VM naming actually works Family, series, and size — what each one represents
How to read a VM name left → right What each letter, number, and version implies
How to choose the right series first Balanced vs memory vs compute vs GPU — before choosing a VM size
How Microsoft documentation maps to VM selection Family → Series → Size → region and quota checks
Common VM sizing considerations Key considerations during VM deployment

By the end, you should be able to look at D16ds_v5 and understand the underlying capabilities and constraints of that VM — not just its size.

How Azure Organizes Virtual Machines

Type / Category
(General purpose / Memory / Compute / GPU / HPC)
      ↓
Family
(D / E / F / N / H)
      ↓
Series
(Dsv5 / Dasv6 / Ebdsv5)
      ↓
Size (SKU)
(D16ds_v5 / D32as_v6)

Type / category = the workload class you're optimizing for (balanced, memory, compute, GPU, HPC)
Family = workload archetype (balanced, memory-optimized, GPU…)
Series = a lineup built on the same generation + capability pattern
Size = a specific deployable SKU with exact vCPU/memory and flags

How Microsoft Organizes VM Sizes in Documentation

Microsoft documentation reflects the same hierarchy you just saw — but it’s split across different pages and navigation paths.

Microsoft Docs / Portal
        │
        ├─ Family pages
        │    (workload intent)
        │
        ├─ Series pages
        │    (hardware + capabilities)
        │
        └─ Size tables
             (deployable SKUs + limits)

Family pages describe the workload focus (general purpose, memory, compute, GPU)
Series pages define hardware generations, capabilities, and supported features
Size tables list the deployable SKUs, limits, and regional availability

This is why you often see separate links for Series and Sizes in Microsoft Learn and the Azure portal — they answer different questions.

Series vs Size: What Each One Answers

Concept	What it is	How you use it
Series	A group of related sizes with the same naming pattern and generation (e.g., `Dsv5`)	Pick the lineup that matches workload intent (balanced vs memory vs GPU), plus platform capabilities.
Size	A specific deployable SKU inside that series (e.g., `D16s_v5`)	Right-size vCPU/memory within the chosen series, then validate quotas/availability.

You can often resize within a series easily; Series defines platform behavior; size defines capacity.

How to read a VM name (read left → right)

[Family] + [Sub-family]* + [# vCPUs] + [Constrained vCPUs]*
        + [Additive Features] + [Accelerator Type]* + [Memory Capacity]* + [Version]

Uppercase letters (family/sub-family) set the workload class.
Numbers set the guest-visible vCPU count.
Lowercase letters are additive features that change capabilities.
_v# is the series version (generation contract).

VM Name Parsing Map

D 16 d s _v5
│ │  │ │   │
│ │  │ │   └─ Generation
│ │  │ └─ Premium SSD support
│ │  └─ Local NVMe temp disk
│ └─ vCPU count
└─ Family

Read left to right. Every character changes behavior.

Example: Reading a VM Name

    E32ds_v5
    E = Memory optimized family
32 = 32 vCPUs
d = includes local temporary disks (NVMe/temp storage)
s = compatible with premium SSD types
v5 = version/generation

  

If you miss d, you miss local temp disk behavior. If you miss v5, you miss a generation change.

What the lowercase letters mean

Flag	Meaning	Support / workload signal
`a`	AMD-based processor	CPU vendor shift; validate perf + licensing assumptions
`p`	ARM-based processor	Compatibility check (images, agents, drivers); great price/perf for some Linux workloads
`d`	Includes local temporary disks	Scratch/caching/spill; not durable
`s`	Premium SSD compatible	Most production persistent disks need this
`r`	Includes RDMA secondary network	HPC/MPI; fabric expectations + placement matters
`i`	Isolated size	Single-tenant isolation; compliance / noisy-neighbor avoidance
`e`	Encrypted / confidential TDX capability	Confidential computing; security posture change
`b`	Remote storage bandwidth optimized	When disks are the bottleneck (not CPU)
`n`	Network optimized	Higher vCPU-to-network bandwidth ratio

There are more flags (f, l, m, o, t…)—these are the ones that show up most often in support conversations.

GPU note: GPUs aren't represented by a single-letter flag. GPU SKUs are primarily identified by the N family / series (e.g., NC/ND/NV), and the accelerator often appears as a token in the name (e.g., _T4_, _A10_, _A100_).

Example: Reading a GPU VM Name

GPU SKUs follow the same rules — series indicates the platform, and extra letters add capabilities.

NC4as_T4_v3

N = GPU-enabled family
C = Compute-focused GPU series (HPC / ML workloads)
4 = Capacity tier (vCPU / memory sizing)
a = AMD-based CPU
s = Premium SSD support
T4 = NVIDIA Tesla T4 accelerator
v3 = Generation

Same takeaway: The number just scales the VM — it doesn’t change what it is.

Quick Reference: Azure VM Families

Family	Primary Use	Memory Ratio (RAM per vCPU)	Key Flags	Typical Workloads
D	General purpose	~4 GiB/vCPU	s, d, a	App tiers, services
E	Memory optimized	8–16 GiB/vCPU	b, s, d	SQL, SAP, JVM
F	Compute optimized	~2 GiB/vCPU	a	CPU-bound apps
L	Storage optimized	Varies	d	IO-heavy, logs
N	GPU	Specialized	_A100, _T4	ML, VDI
H	HPC	Specialized	r	MPI, CFD

Note: Memory ratio describes how much RAM is allocated per vCPU. This is why two VMs with the same core count can behave very differently across families.

How to choose: series first, size second

Identify workload bottleneck: CPU, memory, IO, network, GPU?
Select family: D (balanced), E (memory), F (compute), L (storage), N (GPU), H (HPC)…
Select series contract: vendor (a/p), temp disk (d), premium disks (s), bandwidth flags.
Pick the size: start small enough to measure, big enough to avoid immediate saturation.
Validate constraints: region availability, quota, disk limits, bandwidth limits, acceleration availability.

    Support tip: “Right series, wrong size” is fixable with resize. “Wrong series” often requires redeployment and downtime.
  

Walkthrough: from series → size in practice

Question	Series-level answer	Size-level answer
Do we need balanced vs memory-optimized?	Pick `D` vs `E`	Pick `D16` vs `E16`
Do we need local NVMe temp?	Series with `d` behavior	Confirm the exact size includes `d`
Do we need premium disks?	Choose series with `s`	Ensure the size has `s`
Do we need AMD or ARM?	Pick series with `a` or `p`	Keep flags consistent during resize

Workload example 1: enterprise web/app tier

Pattern

CPU moderate, memory moderate, needs reliable disk performance
Scale-out friendly, predictable latency

Sizing guidance

Start with D-family (balanced) and a premium-disk capable series (…s…).
Example sizing path: D4s_v5 → D8s_v5 → D16s_v5 based on CPU/mem utilization and app latency.

Common mistake: choosing a “bigger number” in a different series and unintentionally changing temp disk, CPU vendor, or generation.

Workload example 2: SQL Server / relational DB

Pattern

Often memory and storage-bandwidth sensitive
Licensing can dominate cost (core-based)

Sizing guidance

Consider E-family (memory optimized) and bandwidth-oriented flags.
Use temp disk (d) for tempdb when appropriate; use managed disks for durable data/logs.
Know constrained vCPU options for licensing control (see next slide).

    Docs even call out examples like E96bds_v5 as a SQL Server preferred option in the naming breakdown.
  

Constrained vCPU SKUs (licensing lever)

These SKUs exist primarily to reduce core‑based software licensing cost, not to reduce platform capability.

Used for certain sizes only: exposes fewer vCPUs than the underlying hardware allocation.
Goal: reduce core-based licensing cost while retaining memory and IO characteristics.

Common use case: SQL Server

E16-8s_v5

E = Memory‑optimized family (good for databases)
16‑class hardware = same memory, IO, and bandwidth as full E16
8 exposed vCPUs = only 8 cores need to be licensed
s = Premium SSD support
v5 = Generation

    Key idea: constrained vCPU SKUs reduce licensed cores, not memory,
    storage throughput, or network bandwidth.
  

This pattern is most common for SQL Server, Oracle, and other core‑licensed software.

Storage reality: local temp disk vs managed disks

d means the VM includes local temporary disks (often NVMe on the host).
Local temp storage is great for:
- DB tempdb, caches, build artifacts, spill, scratch, short-lived staging
But: local temp storage is not durable. Host moves/redeployments can wipe it.
s means the VM is compatible with Premium SSD types for persistent managed disks.

    Common mistake: customer stores durable data on temp disk because it “benchmarks fast.”
  

Version / generation (`_v#`) is a hardware contract

Generation changes can alter CPU microarchitecture, memory channels, PCIe generation, NIC characteristics.
Same “shape” across generations does not mean same performance.
Operationally: regional availability and quota can differ by generation.

    Example: D32s_v3 and D32s_v5 may have the same vCPU/memory ratio but differ materially in CPU and IO behavior.
  

What Typically Changes Between v4, v5, and v6

Area	What Changes
CPU	Newer microarchitecture and instruction support
Memory	Higher bandwidth and improved NUMA layouts
Storage	Faster local temp disks and newer PCIe generations
Network	Higher baseline throughput and NIC capabilities
Availability	Rolls out region by region, not globally at once
Quotas	Often tracked separately per generation

Same size name across generations does not guarantee identical performance.

Current state (late 2024/2025): v6 generation is still rolling out across regions. Check regional availability before planning v6 migrations. v5 remains widely available and stable.

Questions & Microsoft VM Sizing Resources

Official documentation to validate series, sizes, limits, and availability

Azure VM sizes overview
https://learn.microsoft.com/azure/virtual-machines/sizes
VM naming conventions
https://learn.microsoft.com/azure/virtual-machines/vm-naming-conventions
Azure VM quotas and limits
https://learn.microsoft.com/azure/quotas/view-quotas

Azure VM Sizing Demystified

What We’re Going to Cover

How Azure Organizes Virtual Machines

How Microsoft Organizes VM Sizes in Documentation

Series vs Size: What Each One Answers

How to read a VM name (read left → right)

VM Name Parsing Map

Example: Reading a VM Name

E32ds_v5

What the lowercase letters mean

Example: Reading a GPU VM Name

Quick Reference: Azure VM Families

How to choose: series first, size second

Walkthrough: from series → size in practice

Workload example 1: enterprise web/app tier

Pattern

Sizing guidance

Workload example 2: SQL Server / relational DB

Pattern

Sizing guidance

Constrained vCPU SKUs (licensing lever)

Common use case: SQL Server

Storage reality: local temp disk vs managed disks

Version / generation (_v#) is a hardware contract

What Typically Changes Between v4, v5, and v6

Questions & Microsoft VM Sizing Resources

`E32ds_v5`

Version / generation (`_v#`) is a hardware contract