# Azure VM Sizes Explained: B, D, E and F Series for Common Workloads

> Choose between Azure B, D, E and F series VMs: memory per vCPU, burstable credits, naming letters like s, d and a, and how to resize safely.

Source: https://www.epifive.com/blog/azure-vm-sizes-series-explained-b-d-e-f · Published 2026-10-26 · EpiFive

## Key takeaways

- B series VMs are burstable, earning CPU credits below baseline and throttling back to baseline when the credits are exhausted.
- D series is general purpose with 4 GiB of memory per vCPU at the entry size of current series, E series is memory optimized at 8 GiB per vCPU, and F series is compute optimized, with 2 to 4 GiB per vCPU in its Falsv7 and Fasv7 series.
- In size names, a means AMD, p means Arm, d means a local temporary disk, s means Premium SSD support and l means low memory.
- Resizing a running VM restarts it, and moving between sizes with and without a local temp disk is restricted for Windows VMs.
- Check B series credit metrics in Azure Monitor before and after you choose a size, because sustained high CPU on a B series wastes the saving.

For common workloads, choose a B series VM for small, mostly idle servers that burst occasionally, a D series VM for balanced general purpose work such as web and application servers, an E series VM when the workload needs a lot of memory per CPU such as databases and caches, and an F series VM when it is CPU-bound with modest memory. Within each series, the letters in the size name tell you the processor type, whether there is a local temp disk and whether Premium SSD is supported.

## Who this is for and what you will have

This guide is for people who have to pick or justify an Azure VM size and are looking at a long list of names like Standard_D4ds_v5 or Standard_B2ts_v2. By the end you will understand how Azure groups sizes into families, what B, D, E and F are each designed for, how to read a size name, how the B series credit model works, how to shortlist a size for a workload, and how to resize safely.

This guide does not list prices, which vary by region, operating system and commitment. Use the Azure pricing calculator for numbers.

## How Azure organizes VM sizes

Azure groups VM sizes into types by intended workload: general purpose, compute optimized, memory optimized, storage optimized, GPU accelerated and FPGA accelerated. Each type has families identified by a letter, each family has series (a group with similar hardware and features), and each series has individual sizes.

| Type | Meaning from the documentation | Families covered here |
|---|---|---|
| General purpose | Balanced CPU-to-memory ratio; testing and development, small to medium databases, low to medium traffic web servers | B (burstable), D |
| Compute optimized | High CPU-to-memory ratio; medium traffic web servers, network appliances, batch processes, application servers | F |
| Memory optimized | High memory-to-CPU ratio; relational databases, medium to large caches, in-memory analytics | E |

## The four families at a glance

| Family | Type | Designed for | Memory per vCPU at the smallest sizes in current series |
|---|---|---|---|
| B | General purpose, burstable | Workloads that do not need constant full CPU: web servers, proof of concepts, small databases, dev and build environments | Varies; the Bsv2 page lists 1 GiB at the smallest size |
| D | General purpose | Enterprise applications, web and app servers, relational databases, in-memory caching, data analytics, batch processing | 4 GiB per vCPU in the standard Dsv7 range (2 vCPUs, 8 GiB at the smallest), or 2 GiB per vCPU in the low-memory Dl series |
| E | Memory optimized | Large databases, big data analytics, enterprise apps such as ERP and CRM, in-memory computing | 8 GiB per vCPU in the current E series (2 vCPUs, 16 GiB at the smallest) |
| F | Compute optimized | Batch processing, web servers, analytics, gaming | Varies by series: 2 GiB per vCPU in Falsv7, 4 GiB in Fasv7 and 8 GiB in Famsv7 |

These ratios come from the memory ranges on Microsoft's family pages, for example Dsv7 at 2 to 372 vCPUs and 8 to 1,488 GiB, Dlsv7 at 2 to 248 vCPUs and 4 to 496 GiB, and Esv7 at 2 to 372 vCPUs and 16 to 2,832 GiB. Ratios differ between series within a family, so always read the table for the specific series.

## B series: burstable VMs

B series is the only VM type that uses credits for CPU performance. A B series VM accumulates credits while its workload runs below the base CPU performance level and spends them when it runs above it. When all credits are consumed, the VM is throttled back to its base performance until it earns credits again.

Terms from the documentation:

- **Base CPU performance:** the minimum CPU level always available. Below it you gain credits; above it you spend them.
- **Initial credits:** credits allocated when the VM is deployed.
- **Max banked credits:** the cap on how many credits a VM can store.
- **CPU Credits Consumed and CPU Credits Remaining:** Azure Monitor metrics that show spending and balance.

The documentation gives a formula for credits banked per minute: `((Base CPU performance * number of vCPU) - (Percentage CPU * number of vCPU)) / 100`. In its example, a Standard_B2ts_v2 with a 20 percent base and a workload using 10 percent CPU banks `((20*2) - (10*2))/100 = 0.2` credits per minute. A Standard_B32as_v2 with a 40 percent base running at 60 percent consumes 6.4 credits per minute.

### Which B series exist

The current B family has three series:

| Series | Processor | Size range |
|---|---|---|
| Bsv2 | Intel Xeon Platinum (Emerald Rapids, Sapphire Rapids or Ice Lake) | 2 to 32 vCPUs, 1 to 128 GiB |
| Basv2 | AMD EPYC 7763v (Milan) | 2 to 32 vCPUs, 1 to 128 GiB |
| Bpsv2 | Arm-based Ampere Altra | 2 to 16 vCPUs, 1 to 64 GiB |

Microsoft lists web servers, proof of concepts, small databases and development build environments as ideal B family uses.

### When B series is the wrong choice

If a workload keeps CPU above baseline for long periods, credits run out and performance drops to baseline. Watch **CPU Credits Remaining** and **Percentage CPU** in Azure Monitor for a few weeks. If the credit balance trends to zero, move to a D series size of similar capacity.

## D series: balanced general purpose

D family VMs are described as a balance of CPU and memory for most production workloads: enterprise applications, moderate to high traffic web and application servers, relational databases, development and test environments and batch processing. They have faster processors and more memory per core than the A series.

Within D there are variants worth knowing:

- **Dsv7 and Ddsv7:** Intel Xeon 6 (Granite Rapids), 8 GiB at 2 vCPUs.
- **Dasv7 and Dadsv7:** AMD EPYC 9005, 2 to 160 vCPUs.
- **Dlsv7 and Dldsv7, Dalsv7 and Daldsv7:** the `l` low-memory variants, with half the memory per vCPU (for example 4 GiB at 2 vCPUs), which suit workloads that need less RAM.
- **Dpsv6 family:** Arm-based on Azure Cobalt 100.

DC sizes, where the `C` subfamily letter means confidential, are a separate confidential-computing family and not part of the plain D family.

## E series: memory optimized

E family VMs have high memory-to-core ratios and suit large relational databases such as SQL Server and NoSQL databases, ERP and CRM systems, big data analytics, in-memory databases such as SAP HANA, and data warehousing. The Esv7 series, for example, starts at 2 vCPUs and 16 GiB and goes to 372 vCPUs and 2,832 GiB. The Epsv6 page states it directly: 8 GiB of memory per vCPU.

The E family also has subfamilies with special features, such as Eb (higher remote storage performance) and EC (confidential computing). The SQL-oriented option is an Eb size, for example E96bds_v5 in Microsoft's naming example. For a small database, compare a D size with enough memory first, because E sizes pay for memory you may not use.

## F series: compute optimized

F family VMs have a high CPU-to-memory ratio and are meant for batch processing, web servers, analytics and gaming. Recent F series such as Fasv7 run without simultaneous multithreading, so a vCPU maps to a full physical core, which gives dedicated resources. Fasv7 spans 1 to 80 vCPUs and 4 to 320 GiB, Falsv7 spans 1 to 80 vCPUs and 2 to 160 GiB and Famsv7 offers a higher ratio of 8 GiB per vCPU at the small end. The older Fsv2 series goes from 2 to 72 vCPUs and 4 to 144 GiB.

An F size is the right call when profiling shows the workload is CPU-bound and memory is mostly idle. If you are not sure, a D size is the safer default.

## How to read a size name

The documented pattern is family, optional subfamily, number of vCPUs, optional constrained vCPUs, additive features, optional accelerator, optional memory capacity and version. Lowercase additive letters you will meet most often:

| Letter | Meaning |
|---|---|
| a | AMD-based processor |
| p | Arm-based processor |
| d | Includes local temporary disk |
| s | Compatible with any Premium SSD type |
| l | Low memory; decreased vCPU-to-memory ratio |
| m | Memory intensive; highest vCPU-to-memory ratio in a series |
| b | Remote storage bandwidth optimized |
| i | Isolated size |
| e | Encrypted, with confidential TDX capabilities |
| t | Tiny memory; smallest vCPU-to-memory ratio in a particular size |

In the series covered here, sizes without an `a` or `p` run on Intel processors, as the Dsv7, Esv7 and Bsv2 pages show. The version number at the end is the series version.

So `Standard_D4ads_v6` reads: D family, 4 vCPUs, AMD processor, local temp disk, Premium SSD support, version 6. If you need Premium Storage, make sure the size has an `s`; Microsoft's resize guidance gives the example of choosing Standard_E4s_v3 rather than Standard_E4_v3.

## Step-by-step: shortlist a size

1. **Write down measurements, not guesses.** Collect average and peak CPU, memory used, disk IOPS and throughput and network use from the current server or from a test.
2. **Choose the type.** Balanced: D. Memory heavy: E. CPU heavy: F. Mostly idle with bursts: B.
3. **Choose the processor.** Intel is the default, `a` is AMD and `p` is Arm. Arm sizes need software that runs on Arm64.
4. **Decide on a temp disk.** If the application does not need local temporary storage, a size without `d` avoids paying for it; Microsoft describes no-local-disk sizes as a better value for workloads that do not need local temporary storage.
5. **Check storage needs.** Look at the remote storage IOPS and throughput limits of the series, not just the disk type.
6. **Check regional availability and quota** in the target region, and use Microsoft's VM selector to filter by workload, OS and region.
7. **Estimate cost** in the Azure pricing calculator for the shortlist, and compare with and without reservations or savings plans if the VM will run for months.
8. **Deploy, monitor and right-size.** Revisit the choice after two to four weeks of real usage.

## Resizing a VM

You can scale a VM up or down by changing its size, running or deallocated. Facts from Microsoft's resize guidance:

- Changing the size of a running VM restarts it, so treat it as disruptive, especially for stateful workloads.
- If the new size is not available on the current hardware cluster, you must deallocate first. Deallocation also releases dynamic IP addresses. OS and data disks are not affected.
- If a resize fails, the VM model can show the requested size while the VM keeps running on its previous size.
- For Windows VMs you can only resize between sizes with a local temp disk or between sizes without one, not across. Linux VMs can resize across both kinds.
- You cannot resize a SCSI-based VM size to a remote NVMe-enabled size.

In the portal: open **Virtual machines**, select the VM, under **Availability + scale** select **Size**, choose a new compatible size and select **Resize**. If the size you want is missing while the VM is running, stopping it may reveal more sizes.

With Azure CLI, from Microsoft's sample:

```bash
resourceGroup=myResourceGroup
vm=myVM
size=Standard_D4ds_v5

# List sizes available on the VM's current hardware cluster
az vm list-vm-resize-options --resource-group $resourceGroup --name $vm --query "[].name" -o tsv

az vm deallocate --resource-group $resourceGroup --name $vm
az vm resize --resource-group $resourceGroup --name $vm --size $size
az vm start --resource-group $resourceGroup --name $vm
```

With Azure PowerShell:

```powershell
$resourceGroup = "myResourceGroup"
$vmName = "myVM"
Get-AzVMSize -ResourceGroupName $resourceGroup -VMName $vmName

$vm = Get-AzVM -ResourceGroupName $resourceGroup -VMName $vmName
$vm.HardwareProfile.VmSize = "Standard_D4ds_v5"
Update-AzVM -VM $vm -ResourceGroupName $resourceGroup
```

Replace the size with one that exists in your region and appears in the list for your VM.

## Common choices by workload

| Workload | Starting point | Why |
|---|---|---|
| Small internal web app, low traffic | B series | Idle most of the time, bursts on requests |
| Dev and test, build agent | B or D series | B if usage is sporadic; D if builds run continuously |
| Production web and app servers | D series | Balanced and fixed CPU performance |
| SQL Server or other relational database | D or E series, E when memory-bound | E gives more RAM per vCPU |
| In-memory cache or analytics | E series | High memory-to-CPU ratio |
| Batch processing, CPU-bound services | F series | High CPU-to-memory ratio |
| Per-vCPU licensed software | F or constrained-vCPU sizes | The Fasv6 page says full-core F sizes can optimize cost for per-vCPU licensing, and constrained-vCPU sizes cut the vCPU count at the same memory; check licence terms |

For an overview of cost levers beyond size, see [Azure cost optimization checklist](https://www.epifive.com/blog/azure-cost-optimization-checklist), and to catch overspend early, see [Azure budgets and cost alerts setup](https://www.epifive.com/blog/azure-budgets-cost-alerts-setup).

## Troubleshooting

### The size I want is not in the list

The VM may be running on a hardware cluster that does not support it. Stop and deallocate the VM and check the list again. If the size is still missing, check regional availability and your subscription quota for that VM family.

### A B series VM is slow after hours of work

Credits are probably exhausted and the VM is throttled to its baseline. Check CPU Credits Remaining. Move to a larger B size with a higher baseline or to a D series size.

### Windows VM resize fails between sizes with and without temp disk

That combination is not allowed for Windows. Microsoft documents a workaround: snapshot the VM, create a disk from the snapshot and create a new VM from that disk with the new size.

### Premium SSD cannot be attached

The size does not support Premium Storage. Choose a size with `s` in the name.

### The resize appears successful but performance did not change

Microsoft notes that after a failed resize the VM model shows the requested size while the VM continues on the previous size. Check that the VM actually restarted and confirm the size from inside the OS or from the instance metadata.

## Checklist

- Measure CPU, memory, disk and network use before choosing.
- Pick the family by workload: B burstable, D balanced, E memory heavy, F CPU heavy.
- Read the size name for processor type, local temp disk and Premium SSD support.
- Monitor credits if you choose B series.
- Confirm regional availability and quota.
- Price the shortlist in the pricing calculator.
- Plan a maintenance window for resizing, because it restarts the VM.
- Review the size again after a few weeks of production usage.

## References

- Virtual machine sizes overview: https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/overview
- B family VM size series: https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/general-purpose/b-family
- D family size series: https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/general-purpose/d-family
- E family VM size series: https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/memory-optimized/e-family
- F family VM size series: https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/compute-optimized/f-family
- B series CPU credit model: https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/b-series-cpu-credit-model
- Azure VM sizes naming conventions: https://learn.microsoft.com/en-us/azure/virtual-machines/vm-naming-conventions
- Resize a virtual machine: https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/resize-vm
- Azure pricing calculator: https://azure.microsoft.com/pricing/calculator/

## Frequently asked questions

### What is the difference between Azure D series and B series VMs?

D series is general purpose with fixed CPU performance and a balanced CPU-to-memory ratio. B series is burstable: it earns CPU credits when running below its baseline and spends them to burst above it, then throttles back to baseline when credits run out. B series suits workloads that are idle much of the time.

### Which Azure VM series should I use for a database?

Microsoft lists relational databases among the workloads for both the D family and the memory optimized E family. E series has a higher memory-to-CPU ratio, 8 GiB per vCPU at the smallest sizes in the current series, so it fits databases that need a lot of RAM per core. Test with your own workload and monitor memory and CPU.

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

Lowercase letters after the vCPU count are additive features. For example, a means AMD-based processor, p means Arm-based, d means the size includes a local temporary disk, s means it supports any Premium SSD type, and l means a low-memory ratio. A trailing v number is the series version.

### Does resizing an Azure VM cause downtime?

Yes. Changing the size of a running VM restarts it, and in some cases you must deallocate it first if the new size is not available on the current hardware cluster. Deallocation also releases dynamic IP addresses, while OS and data disks are not affected.