Azure VM Sizes Explained: Families, vCPUs, and How to Choose
Azure VM sizes follow a naming convention that tells you the workload family, vCPU count, storage capability, and hardware generation — all in one string like Standard_D4s_v5. This page decodes that naming system, walks through the major VM families, and gives you a decision pattern for picking the right size without guessing.
Reading the size name
Take Standard_D4s_v5 as an example:
- Standard — the pricing tier. All current VMs use Standard. The old Basic tier is retired.
- D — the family letter. D means general-purpose balanced compute and memory.
- 4 — the number of vCPUs.
- s — an optional capability flag.
smeans Premium SSD support. Other flags includea(AMD processor),d(local temp SSD),l(low memory),m(large memory multiplier),p(ARM/Ampere processor). - v5 — the hardware generation. Higher generation = newer, usually faster and cheaper per vCPU than the same family in an earlier generation.
Not every size has all parts. Standard_B2ms is a B-family burstable VM with 2 vCPUs, large memory (m), and premium storage (s) — no generation suffix because B-series has its own versioning scheme.
The major VM families
| Family | vCPU:Memory ratio | Best for | Example size |
|---|---|---|---|
| B-series (Burstable) | Varies, low baseline | Dev/test, light workloads that spike occasionally | Standard_B2s |
| D-series (General purpose) | 1:4 (1 vCPU per 4 GB RAM) | Web servers, app servers, databases | Standard_D4s_v5 |
| E-series (Memory optimised) | 1:8 (1 vCPU per 8 GB RAM) | In-memory databases, SAP HANA, large caches | Standard_E8s_v5 |
| F-series (Compute optimised) | 1:2 (1 vCPU per 2 GB RAM) | Batch processing, gaming servers, simulations | Standard_F8s_v2 |
| L-series (Storage optimised) | Varies | NoSQL databases, high-throughput local disk workloads | Standard_L8s_v3 |
| N-series (GPU) | GPU-attached | Machine learning, rendering, GPU compute | Standard_NC6s_v3 |
| M-series (Large memory) | Up to 1:28 | Very large in-memory databases, SAP | Standard_M128s |
B-series: burstable compute explained
B-series VMs are the most cost-effective option for workloads that do not need sustained high CPU. They accumulate CPU credits when idle, then spend those credits during spikes. A Standard_B2s has a baseline CPU performance of 40% (0.4 vCPUs worth of sustained compute) but can burst to 200% (both vCPUs at full speed) when it has credits banked.
This model works well for development environments, low-traffic web servers, build agents that sit idle between builds, and scheduled batch jobs. It breaks down for workloads that need sustained high CPU — a B-series VM running a CPU-bound task continuously will exhaust its credits and throttle to baseline performance, which can be dramatically slower than expected.
Check CPU credit balance in Azure Monitor or run az vm get-instance-view to detect credit exhaustion on B-series VMs before it causes a performance incident.
How to pick a size in practice
Most teams pick VM sizes in one of two ways: based on known requirements, or by starting small and resizing after observing actual usage.
Starting from known requirements
If you are migrating a server from on-premises, match the existing CPU and RAM as a starting point. If the on-premises server runs at 20% CPU utilisation on average, consider downsizing — you were probably over-provisioned. For new workloads, use the memory ratio as the primary guide: web and application servers tend to fit in D-series, database servers often need E-series, compute-heavy tasks use F-series.
Right-sizing after deployment
Start with a reasonably small D-series VM, deploy your workload, and observe CPU and memory metrics in Azure Monitor for two to four weeks. Azure Advisor will flag VMs that are consistently under 5% CPU and recommend downsizing. If memory pressure appears (high page faults, swap usage), move up or switch to E-series.
Azure Advisor’s cost recommendations often identify VMs running at <5% CPU that could be resized to save 30–60% on compute costs. Check Advisor under the Cost tab before assuming you need a larger size.
Checking available sizes
Not all sizes are available in every region and Availability Zone. Before specifying a size in a template or pipeline, verify it is available where you plan to deploy:
# List all VM sizes available in East US
az vm list-sizes --location eastus --output table
# List sizes available for a specific existing VM (resize candidates)
az vm list-vm-resize-options \
--resource-group my-rg \
--name my-vm \
--output tableThe second command is particularly useful when you need to resize a VM and want to know what options are available on the same physical host without deallocating first.
Constrained vCPU sizes
Some database software is licensed per vCPU. Azure offers constrained vCPU sizes that provide the same amount of memory as a full-size VM but with fewer active vCPUs — reducing software licensing costs while maintaining memory.
For example, Standard_E32-8s_v5 has 8 active vCPUs but the same 256 GB memory as a Standard_E32s_v5 with 32 vCPUs. If you are running SQL Server Enterprise Edition licensed per core, using the constrained size could cut your licensing cost by 75% while keeping the same memory for the database workload. Compute performance for non-CPU-bound queries is unchanged.
Common sizing mistakes
- Using B-series for sustained CPU workloads. B-series works for bursty tasks. Running a compiler or a machine learning training job on a B-series VM will exhaust CPU credits and stall at baseline performance — often 40–60% slower than expected.
- Over-provisioning to be safe. A VM with twice the vCPUs you need costs twice as much. Start with a smaller size, monitor usage for a few weeks, and resize up only if metrics show actual bottlenecks.
- Choosing an older generation for a new deployment. D-series v3 and D-series v5 have the same vCPU counts but different pricing and performance characteristics. v5 is generally cheaper per vCPU-hour than v3. Use the latest available generation unless you have a specific compatibility reason not to.
- Ignoring storage performance caps per VM size. Every VM size has a maximum IOPS limit for attached managed disks. Attaching a high-performance Ultra Disk to a small VM does not help if the VM’s network disk throughput cap is the bottleneck. Check the disk throughput limits in the VM size documentation.
Summary
- The VM size name encodes family, vCPU count, capability flags, and hardware generation. Learning to read it saves time when choosing or comparing sizes.
- D-series for general-purpose workloads, E-series for memory-heavy workloads, F-series for compute-heavy tasks, B-series for bursty dev/test environments.
- B-series VMs use a CPU credit model — they are not suited for sustained high-CPU workloads.
- Start small, deploy, observe metrics in Azure Monitor, and resize based on actual usage rather than guessing upfront.
- Always check available sizes for your target region and Availability Zone before committing to a deployment template.
Frequently asked questions
What does Standard_D4s_v5 mean?
Standard is the pricing tier (vs Basic, which is discontinued). D is the family (general purpose). 4 is the vCPU count. s means it supports Premium SSD storage. v5 is the hardware generation. The full SKU name encodes family, size, capabilities, and generation in that order.
Can I change a VM size after creation?
Yes. Resizing requires a VM restart. Some resizes — particularly moving between families — require deallocating the VM first. Available sizes depend on your region and Availability Zone. Run az vm list-vm-resize-options to see what sizes are available for a specific VM.
What is the difference between a vCPU and a physical CPU core?
A vCPU is a virtual CPU mapped to a thread on a physical processor. Most Azure VM sizes are sized at 2 vCPUs per physical core (hyper-threading). Some constrained vCPU sizes give you fewer vCPUs than physical cores — useful when you are paying database licensing by vCPU and want to reduce license cost without reducing memory.