Azure VM Series Guide

Understanding Azure VM Series and Sizes

Azure offers hundreds of virtual machine sizes organized into families, each optimized for different workload types. Picking the right VM size can mean the difference between an application that performs well at reasonable cost and one that wastes money on unused capacity or struggles under load. This guide breaks down every major VM family, explains the naming convention, provides sizing recommendations for common workloads, and covers cost optimization strategies including Spot VMs and Reserved Instances.

Understanding the VM family landscape is essential not just for IaaS workloads but also for services built on VMs under the hood, including AKS node pools, Azure Batch pools, VM Scale Sets, and even some configurations of Azure SQL and Cosmos DB use VM-based compute. Choosing the right underlying VM size affects performance, cost, and feature availability across all of these services.

VM Family Overview

Azure VM sizes are grouped into families identified by a letter prefix. Each family is designed for a specific balance of CPU, memory, storage, and GPU resources. Selecting the right family is the most impactful decision; choosing between sizes within a family is a matter of scaling up or down.

Understanding the Naming Convention

Azure VM size names follow a structured pattern that encodes the family, generation, processor, additive features, and size. Learning to decode these names lets you quickly understand what a VM offers without looking up documentation.

Standard_D8as_v5
         | || |  |
         | || |  └── Version (v5 = 5th generation)
         | || └───── Additive features (s = Premium Storage)
         | |└──────── Sub-family (a = AMD processor)
         | └───────── vCPU count (8 vCPUs)
         └──────────── Family (D = General Purpose)

Additive feature letters:
  a = AMD processor           i = Isolated (dedicated host)
  b = Block storage           l = Low memory (less RAM/vCPU)
  d = Local temp disk (NVMe)  m = Memory intensive (more RAM/vCPU)
  p = ARM-based processor     s = Premium Storage capable
  t = Tiny memory             C = Confidential

Processor indicators:
  (none) = Intel               a = AMD EPYC
  p = Ampere ARM (Cobalt)

Examples decoded:
  Standard_D4s_v5    = General Purpose, 4 vCPU, Intel, Premium SSD, Gen 5
  Standard_D8as_v5   = General Purpose, 8 vCPU, AMD, Premium SSD, Gen 5
  Standard_E16ds_v5  = Memory Optimized, 16 vCPU, local NVMe, Premium SSD, Gen 5
  Standard_B2ms      = Burstable, 2 vCPU, more memory, Premium SSD
  Standard_F4s_v2    = Compute Optimized, 4 vCPU, Premium SSD, Gen 2
  Standard_NC24ads_A100_v4 = GPU, 24 vCPU, AMD, local disk, Premium SSD, A100 GPU

General Purpose: D-series Deep Dive

The D-series is the workhorse of Azure compute. With a balanced 1:4 CPU-to-memory ratio (approximately 4 GB RAM per vCPU), it handles the vast majority of production workloads. If you are unsure which family to choose, start with D-series. It covers roughly 80% of cloud workloads.

*Approximate Linux pay-as-you-go rates in East US 2. Actual costs vary by region, OS, and discount programs.

Memory Optimized: E-series

The E-series provides a high memory-to-CPU ratio (1:8, or 8 GB RAM per vCPU), making it ideal for memory-intensive workloads like relational databases, in-memory caching, and real-time analytics. If your application's primary bottleneck is available RAM rather than CPU, E-series delivers more memory per dollar than D-series.

Common E-series Use Cases

• SQL Server: Database workloads with large buffer pool requirements. E-series provides the memory headroom for in-memory OLTP and columnstore indexes.
• SAP applications: SAP NetWeaver and S/4HANA require significant memory. E-series (and M-series for very large instances) are SAP-certified.
• Redis / Memcached: In-memory caching layers benefit from maximum available RAM.
• Elasticsearch / OpenSearch: Search engines that keep indices in memory for fast query performance.
• Apache Spark: In-memory data processing frameworks that benefit from large executor memory.

Compute Optimized: F-series

The F-series offers a high CPU-to-memory ratio (1:2, or 2 GB RAM per vCPU) and the highest clock speeds in Azure. It is designed for workloads that are CPU-bound rather than memory-bound. F-series VMs use the latest high-frequency processors, making them the best choice for raw single-threaded performance.

F-series Use Cases

• Batch processing: CPU-intensive data processing, media transcoding, and ETL pipelines
• Gaming servers: Multiplayer game servers that need high single-core performance
• CI/CD build agents: Compilation and testing workloads benefit from fast processors
• Scientific computing: Financial modeling, Monte Carlo simulations, molecular dynamics
• Web servers (CPU-bound): Applications with heavy server-side processing and minimal memory needs

Burstable B-series: The Cost Optimizer

B-series VMs use a CPU credit model that makes them dramatically cheaper for workloads with low average CPU utilization. They accumulate CPU credits during idle periods and spend them during bursts. If your workload has an average CPU utilization below 20-30% with occasional spikes, B-series can be 50-70% cheaper than equivalent D-series VMs.

How the Credit Model Works

Each B-series size has a baseline CPU percentage. When the VM uses less than the baseline, it banks credits. When it exceeds the baseline, it spends credits. If credits are depleted, the VM is throttled to the baseline level. This makes B-series unsuitable for sustained high-CPU workloads but ideal for bursty, intermittent usage patterns.

# Check CPU credit balance for a B-series VM
az monitor metrics list \
  --resource /subscriptions/<sub-id>/resourceGroups/myRG/providers/Microsoft.Compute/virtualMachines/myBVM \
  --metric "CPU Credits Remaining" "CPU Credits Consumed" "Percentage CPU" \
  --interval PT1H \
  --output table

# List available VM sizes in a region
az vm list-sizes --location eastus2 --output table

# Check which sizes are available in specific availability zones
az vm list-skus --location eastus2 \
  --query "[?resourceType=='virtualMachines' && contains(name, 'Standard_D')].{Name:name, Zones:locationInfo[0].zones}" \
  --output table

# Resize a VM (may require deallocation for cross-family changes)
az vm deallocate --resource-group myRG --name myVM
az vm resize --resource-group myRG --name myVM --size Standard_D4s_v5
az vm start --resource-group myRG --name myVM

# List Azure Advisor right-sizing recommendations
az advisor recommendation list \
  --category Cost \
  --query "[?contains(shortDescription.solution, 'virtual machine')]" \
  --output table

GPU Accelerated: N-series

The N-series provides GPU-accelerated compute for machine learning, rendering, and visualization workloads. Azure offers several N-series sub-families with different GPU types optimized for different use cases.

Storage Optimized: L-series

The L-series provides high local NVMe SSD throughput and IOPS, designed for workloads that need fast local storage access. The key differentiator is the massive local NVMe storage that is directly attached to the VM (not network-attached managed disks). This local storage provides single-digit microsecond latency and millions of IOPS.

L-series Use Cases

• NoSQL databases (Cassandra, ScyllaDB, MongoDB): Benefit from high local IOPS for write-heavy workloads
• Elasticsearch / OpenSearch: Index storage on NVMe for fast search queries
• Data warehousing (ClickHouse, Apache Druid): Analytical databases that scan large volumes of data
• Log analytics: Ingestion and indexing of high-volume log data

Managed Disk Types

The disk type attached to your VM significantly affects performance and cost. Azure offers five managed disk types, each suited to different IOPS and throughput requirements.

Cost Optimization Strategies

VM compute is typically the largest line item in Azure bills. Several strategies can significantly reduce VM costs without impacting performance.

Spot VMs

Azure Spot VMs provide access to unused Azure capacity at discounts of up to 90% compared to pay-as-you-go pricing. The trade-off is that Azure can evict Spot VMs with 30 seconds notice when it needs the capacity back.

# Create a Spot VM with a maximum price
az vm create \
  --resource-group myRG \
  --name spot-worker \
  --image Ubuntu2204 \
  --size Standard_D4s_v5 \
  --priority Spot \
  --max-price 0.05 \
  --eviction-policy Deallocate \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_rsa.pub

# Check current Spot pricing for a VM size
az vm list-skus --location eastus2 --size Standard_D4s_v5 \
  --query "[].{Name:name, SpotPrice:capabilities[?name=='MaxResourceVolumeMB']}" \
  --output table

# Create a VMSS with Spot instances for batch processing
az vmss create \
  --resource-group myRG \
  --name batch-workers \
  --image Ubuntu2204 \
  --vm-sku Standard_F4s_v2 \
  --instance-count 10 \
  --priority Spot \
  --eviction-policy Delete \
  --max-price -1 \
  --single-placement-group false

Reserved Instances and Savings Plans

Choosing the Right VM Size

Follow this decision framework to select the best VM for your workload:

1. Profile your workload: Understand CPU, memory, disk IOPS, and network throughput requirements. Use Azure Monitor to measure actual utilization patterns on existing workloads, or use vendor sizing guides for new deployments.
2. Select the right family: Match the CPU:memory ratio to your needs. D-series (1:4) for balanced, E-series (1:8) for memory-heavy, F-series (1:2) for CPU-heavy, B-series for bursty/low-utilization.
3. Choose the latest generation: Always prefer v5 or v6 over older generations. Better performance at the same or lower cost.
4. Consider AMD vs Intel: AMD VMs are 10-15% cheaper with comparable performance. Test with your workload and choose based on benchmarks.
5. Right-size continuously: Use Azure Advisor to identify VMs running below 40% average CPU. Downsize to the next smaller size or switch to B-series for consistently low utilization.
6. Apply cost optimizations: Spot VMs for interruptible work, Reserved Instances for steady-state, Azure Hybrid Benefit for Windows/SQL, and auto-shutdown schedules for dev/test.