Azure VM types compared: B vs D vs E vs F series

Quick answer

B-series (burstable, idle-tolerant) is 40-50% cheaper than D for bursty workloads. D-series (general, 4GB/vCPU) is the default baseline. E-series (memory-optimized, 8GB/vCPU) costs 30-40% more than D but doubles memory. F-series (compute-optimized, 2GB/vCPU) is 20-30% cheaper than D for CPU-bound workloads with modest memory. Prefer v5 or v6 generations and AMD variants (Dasv5) for the best price-performance.

Azure has dozens of VM families. The marketing pages list them all but don't help with the actual question: which one for my workload? This post compares the four most common general-purpose families — B, D, E, F — with real per-hour pricing and the workload patterns each one wins on.

The four families at a glance

Sample pricing for East US, pay-as-you-go Linux, June 2026:

B2s_v2 (2 vCPU, 8 GB, burstable): $0.0416/hour = $30.37/month
D2s_v5 (2 vCPU, 8 GB, general): $0.096/hour = $70.08/month
E2s_v5 (2 vCPU, 16 GB, memory-optimized): $0.126/hour = $91.98/month
F2s_v2 (2 vCPU, 4 GB, compute-optimized): $0.085/hour = $62.05/month

The same nominal "2 vCPU" varies from $30 to $92 monthly depending on family. That's a 3x range. Picking the right family matters more than picking the right size within the wrong family.

B-series: burstable

B-series instances accumulate CPU credits when idle and spend them during CPU bursts. Each size has a baseline CPU percentage and credit accumulation rate:

B2s_v2: 30% baseline, 36 credits/hour
B4s_v2: 50% baseline, 72 credits/hour
B8s_v2: 67% baseline, 144 credits/hour

If the workload uses below baseline CPU, credits accumulate up to a max. When CPU need spikes above baseline, credits get spent at 1 credit per minute per 100% of one vCPU. When credits hit zero, the instance throttles to baseline.

Right for: development environments, internal tools, scheduled scrapers, anything spending most of its time idle.

Wrong for: production web servers (sustained traffic exhausts credits, surprise throttling), batch jobs (constantly above baseline), background workers under steady load.

D-series: general purpose (the default)

D-series gives 4 GB memory per vCPU and dedicated CPU. No credits, no throttling. This is the default choice when you're unsure.

Generation evolution:

Dsv3: Skylake CPUs (legacy)
Dsv4: Cascade Lake (also legacy)
Dsv5: Ice Lake (current Intel)
Dsv6: Sapphire Rapids (newest Intel)
Dasv5: AMD EPYC Milan (current AMD)
Dadsv5: AMD with local NVMe

New deployments should use v5 or v6. Migrate v3 and v4 when possible — same nominal size, lower price, better performance.

Right for: web tiers, application servers, microservices, general workloads. Default to Dasv5 (AMD) for the best price-performance unless you have Intel-specific dependencies.

E-series: memory-optimized

E-series doubles memory per vCPU (8 GB) at a ~30-40% premium. For memory-bound workloads, this is cheaper than scaling out D-series.

Compare for a 16 GB workload:

2x D2s_v5 (16 GB total, 4 vCPU): 2 × $70.08 = $140.16/month
1x E2s_v5 (16 GB, 2 vCPU): $91.98/month

E-series saves $48/month and avoids the overhead of running two instances. For 32 GB workload, the comparison shifts further in E's favor.

Right for: databases, caching servers (Redis, Memcached), JVM applications with large heaps, analytics workloads.

Wrong for: stateless web tiers (extra memory wasted), CPU-bound services.

F-series: compute-optimized

F-series has 2 GB memory per vCPU and faster CPUs at a lower per-vCPU cost. For CPU-bound workloads with modest memory, F-series wins.

Compare for a 4-vCPU CPU-bound workload (e.g. media encoding):

D4s_v5 (4 vCPU, 16 GB): $140.16/month
F4s_v2 (4 vCPU, 8 GB): $124.10/month

F-series saves $16/month while delivering equal or better CPU performance. The catch: only 8 GB memory. If the workload needs more memory, F-series forces scale-out.

Right for: media encoding/decoding, batch transforms, web servers behind a stateful cache, scientific computing, compilation farms.

Wrong for: memory-bound workloads, JVM apps with large heaps, databases.

The decision flow

Is the workload idle most of the time? → B-series. Verify credit accumulation handles your peak with the AvailableCredits metric.
Is the workload memory-bound (high memory usage relative to CPU)? → E-series.
Is the workload CPU-bound with modest memory? → F-series.
None of the above (mixed/general)? → D-series (specifically Dasv5 AMD for price-performance).

Real workload examples

Production API behind a load balancer

Consistent 40-60% CPU utilization, memory needs ~6 GB per instance, no bursty pattern. → D2s_v5 or Das2_v5. Not B-series (steady load exhausts credits). Not E-series (memory headroom not needed). Not F-series (memory exactly matches, no headroom for spikes).

Internal dashboard used by 20 people

90% idle (only used during business hours), occasional bursts when reports run. → B-series. Even with frequent business-hour use, idle nights and weekends accumulate enough credits to cover bursts.

Redis cache holding 24 GB of session data

Memory-bound, light CPU. → E4s_v5 (4 vCPU, 32 GB) at $183.96/month. Compare to D4s_v5 (4 vCPU, 16 GB) which is too small, or D8s_v5 (8 vCPU, 32 GB) at $280.32/month which wastes vCPU.

Video transcoding worker

Constantly 80%+ CPU, modest memory (~6 GB). → F4s_v2 (4 vCPU, 8 GB) at $124.10/month. F-series saves 15% over D-series and the AVX2/AVX-512 instructions on newer F-series help video codec performance.

Pricing math: per-vCPU and per-GB

Reframe the families by what you're paying per resource unit:

B2s_v2: $15.18/vCPU, $3.80/GB memory (but vCPU is bursty, not dedicated)
D2s_v5: $35.04/vCPU, $8.76/GB memory (dedicated vCPU)
E2s_v5: $45.99/vCPU, $5.75/GB memory
F2s_v2: $31.03/vCPU, $15.51/GB memory

F-series is cheapest per dedicated vCPU. E-series is cheapest per GB memory. D-series is the balanced middle. B-series is the cheapest overall but its vCPU is bursty.

Spot pricing

All four families have spot variants at 60-90% discount with the trade-off of preemption with 30-second notice. Right for stateless, fault-tolerant workloads. For more on spot economics, see the azurerm_linux_virtual_machine catalog page.

Azure Hybrid Benefit

If you have Windows Server or SQL Server licenses with Software Assurance, Azure Hybrid Benefit lets you BYOL to VMs, cutting the Windows license portion (~$0.04/vCPU/hour) from the price. For Windows workloads at scale, this is substantial: a D8s_v5 Windows VM saves ~$140/month per instance with Hybrid Benefit applied.

Reservation strategy with VM family choice

Azure Reserved Instances are size-flexible within a family (D-series) but not across families. So:

Reserve D-series at the smallest size in your fleet — the reservation flexes up to larger D sizes proportionally
Don't reserve across families until you're confident in family choice
Hybrid Benefit stacks with reservations for Windows workloads

Estimating with c3x

c3x estimates Azure VM costs from Terraform's azurerm_linux_virtual_machine and azurerm_windows_virtual_machine. The estimate factors in spot pricing, Hybrid Benefit, and the Azure Retail Prices API for live rates:

c3x estimate
# azurerm_linux_virtual_machine.api:
#   size: Standard_D2s_v5
#   region: eastus
#   monthly: $70.08

For the full Azure VM pricing reference, see the azurerm_linux_virtual_machine catalog page.

FAQ

What's the practical difference between D-series and E-series?

D-series is general-purpose (4 GB memory per vCPU). E-series is memory-optimized (8 GB memory per vCPU, double the D). E-series costs roughly 30-40% more than the equivalent D size, but you get 2x memory. For workloads constrained by memory not CPU, E-series is cheaper effectively because you'd need 2x D instances for the same memory.

When is the B-series the right choice?

Workloads that are idle most of the time with occasional bursts: dev environments, low-traffic services, build agents, batch coordinators. B-series accumulates CPU credits during idle and burns them during bursts. Roughly 40-50% cheaper than the equivalent D-series. Avoid for steady-state CPU-bound workloads — credits run out and the instance throttles.

Is F-series worth the premium for compute-heavy workloads?

F-series is compute-optimized: 2 GB memory per vCPU (half of D-series) at lower per-vCPU cost. For CPU-bound workloads with modest memory needs (encoders, batch transforms, web tier behind a stateful cache), F-series can be 20-30% cheaper than D-series for the same vCPU count. For memory-balanced workloads, F-series forces extra instances and ends up more expensive.

How do v5 and v6 generations differ from v4?

Newer generations use newer CPUs (Ice Lake in v5, Sapphire Rapids in v6) with better single-thread performance and lower price per vCPU. v5/v6 are typically 5-15% cheaper than v4 with 10-25% better performance. Always prefer the latest available generation in your region. v4 instances should migrate when possible.

What about Ds_v5 vs Dasv5 (AMD)?

Dasv5 uses AMD EPYC Milan; Ds_v5 uses Intel Ice Lake. AMD variants are typically 10% cheaper at similar performance for many workloads. Some workloads with Intel-specific instructions (AVX-512) do better on Intel. For most general workloads, AMD is the price-performance winner.

How do Azure reservations interact with VM size changes?

Reserved Instances in Azure are size-flexible within an InstanceSeriesFlexibility group: a reservation on a D2s_v5 can apply across other D-series sizes (D2s through D64s) proportionally. So you can right-size within the family without losing reservation coverage. Cross-family changes (D to E, D to F) break the reservation match.

Summary

Family selection drives the bill more than size. B for bursty, D for general, E for memory-bound, F for CPU-bound. Prefer v5/v6 generations and Dasv5 (AMD) for the best price-performance. Reserve within a family once usage is steady.

For commitment strategy in general, see Reserved Instances vs Savings Plans. For the parallel AWS picture, see m5 vs m6i vs m7i: cost and price-performance compared.