Understanding Microsoft Azure Virtual Machine sizes

Having an on-premises infrastructure background, I'm used to scoping hardware by defining the specifications (CPU, memory etc) we'll need to run the applications and expected concurrent users and allowing for some growth. Then we'd often buy a box that would give us room to upgrade further, so for example we're not putting the maximum amount of RAM in that server today. But when it comes to creating a virtual machine in Microsoft Azure, you're now faced with unfamiliar choices – Burstable, D series, F series etc. and a mix of vCPU, RAM and temporary combinations. How do you know which 8 vCPU 32GB size to choose?

T-shirt sizes!

A great way to think of the different combinations of specifications is to relate it to clothing. If I'm buying a t-shirt, I can choose from small, medium, large, extra large etc. Each size has specifications for the body length, sleeve circumference, neck circumference etc. I also have to decide how I like my t-shirts to fit – do I want a tighter, slimmer fit or a baggier, relaxed fit? A small size in a slim but range will be different to a small size in a relaxed cut. And what style do I want – am I going for short sleeves, no sleeves, long sleeves, round neck, or v neck? There are a lot of decisions we make when we're buying clothing, but these choices are familiar.

Microsoft uses the terms category, series and instance when talking about sizes. Lets start with our VM “t-shirt” style!


You'll find the high level categories mentioned in some of the Azure VM documentation, include the pricing information. This is a great place to start to narrow down which machines would be the most suited to the workloads you want to run. Pick your style!
General purpose: Balanced CPU-to-memory ratio. Ideal for testing and development, small to medium databases, and low to medium traffic web servers.
Compute optimized: High CPU-to-memory ratio. Good for medium traffic web servers, appliances, batch processes and application servers.
Memory optimized: High memory-to-core ratio. Great for relational database servers, medium to large caches and in-memory analytics.
optimized: High disk throughput and IO. Ideal for SQL, and NoSQL databases.
GPU: Specialised virtual machines targeted for heavy graphic rendering and video editing available with single or multiple GPUs.
High performance compute: Our fastest and most powerful CPU virtual machines with optional high-throughput interfaces (RDMA).


Next, you'll choose your t-shirt fit, by examining the different series of virtual machines. A series is a group of sizes based on the same host hardware configuration. For compute optimized, that's CPU focussed. For optimized, that might be local SSD disks or directly mapped local NVMe storage.

In the Compute optimised category for example, lets compare two different series:
Fsv2 series: 2GB RAM and 8GB local temporary storage per vCPU, hyperthreaded and based on the Intel Xeon Platinum 8272CL (second generation Intel Xeon Scalable processors or the Intel Xeon Platinum 8168 (Skylake) processor.

F series: 2GB RAM and 16GB local temporary storage per CPU core, based on the Intel Xeon Platinum 8272CL (second generation Intel Xeon Scalable processors, Intel® Xeon® 8171M 2.1GHz (Skylake), Intel® Xeon® E5-2673 v4 2.3 GHz (Broadwell) or the Intel® Xeon® E5-2673 v3 2.4 GHz (Haswell) processor.


Now we're down to the specific t-shirt size for your virtual machine, it's own combination of CPU, RAM and temporary storage. Looking again at computer optimized machines, we'll see the Fsv2 series offers vCPUs in combinations like:

Instance name vCPUs Memory Temporary Storage
F4s v2 4 8 GB 32 GB
F8 v2 8 16 GB 64 GB
F16s v2 16 32 GB 128 GB

While the F series offers physical CPU cores in combinations like:

Instance name Cores Memory Temporary Storage
F4 4 8 GB 64 GB
F8 8 16 GB 128 GB
F16 16 32 GB 256 GB

Note: Temporary storage is a non-persistent disk that disappears & is recreated new if the VM is shut down, resized, moved to a different physical host or if the host is updated or upgraded. It's the default location for the pagefile.sys for Windows and can also be used for SQL's TempDB. You need to provision additional storage for your applications and data, which is not included in the instance sizes.

Where to find sizing information

As sizing is a consideration when estimating or creating a virtual machine, you can find a direct link to detailed sizing information from the Azure Pricing Calculator when you add a virtual machine to your estimate. After adding a virtual machine, click the i symbol then choose Pricing details:

Azure Pricing Calculator link to VM sizing informationAzure Pricing Calculator link to VM sizing information

And from the Azure portal when you create a new virtual machine, click the i symbol next to Size, then choose Learn more about Virtual Machine sizes:
Azure portal VM size informationAzure portal VM size information

B-series burstable virtual machines

The B-series VMs are unique in that they will build up credits when they are operating under their baseline CPU performance, but they can use more than that baseline when your application needs it, up to the maximum provided by the instance size you have selected. For example, the Standard_B2ms instance has 2 vCPUs and a baseline of 60% CPU performance of the VM. When the VM is operating at less than 60% of the CPU performance, you'll accumulate credits. When needed, the Standard_B2ms can burst up to 200% max CPU performance. This is great for applications that have regular, short periods of high demand and long periods of low or no demand, like outside of office hours.

In the Azure Pricing Calculator, there's a switch you can toggle to not show B-series VMs in the size selector. For more information on burstable VMs, maximum credits and how they are applied, visit B-series burstable virtual machines sizes.

Restricting certain VM sizes

Azure Policy lets you control which VM sizes are allowed to de deployed in your environment, and by omission, which sizes are not allowed. The instance sizes are referred to as SKUs (stock keeping units) and this Deny policy will stop VMs being created with or resized to any instance that is not listed in your policy. This is an effective way of putting a cost control measure in place to ensure that the more expensive sizes are not deployed without your knowledge. For more information see Azure Policy built-in definitions for Azure Virtual Machines and the json policy definition on GitHub. 

Getting your sizing right

If you are still unsure, the Azure Portal will recommend sizes related to the Image you have selected for your VM. When an operating system image is added to the gallery, the publisher can recommend a list of instance sizes that are appropriate for that image:

Azure portal showing recommended sizes for the selected imageAzure portal showing recommended sizes for the selected image

Note: Note all instance sizes are available in all Azure regions due to capacity of the data centers and demand. As you need to choose a region first when you create a VM in the Azure portal, you'll received a warning in red if the selected size is not available in that region. Instance sizes can also be restricted depending on your subscription type. For example, an Azure free account is limited to 750 hours of Azure B1S virtual machines for the first 12 months. Also, as per the previous section, you'll receive an error if an administrator has prevented the creation of (and resizing to) certain instance sizes.

List your VMs and their sizes

You can use the Azure Resource Graph Explorer to return a list of all your VMs and their current sizes, with the following KQL query:

| where type =~ 'Microsoft.Compute/virtualMachines'
| project vmName = name, vmSize=tostring(properties.hardwareProfile.vmSize), vmId = id


If you find that your virtual machine is not performing as well as you need it to, you may have undersized it. Azure Advisor will also notify you if your VM is consistently under utilised and could be down sized, saving you money. Fortunately, resizing a VM is a simple process using the Azure portal or PowerShell, but it does require your VM to be shut down and restarted. Also, if your VM is part of an availability set and the new size is not available in it's current physical host hardware , all of the VMs in that availability set need to be deallocated and moved, which may require updating the size of the other VMs too. For detailed information on resizing a virtual machine, visit Resize a Windows VM in Azure. 

Learn more:

Docs – Sizes for virtual machines in Azure (including a great video)

MS Learn – Introduction to Azure virtual machines

Great blog, but there is more to a VM sku than just CPU & Mem, amount of network cards , disks and the throughput and his limits, better start with a bigger machine and downsize later. as the installation goes faster so quicker done and resize if needed for cost savings.  But keep an close eye on your disk iops as you can't run 80000 iops with a B type vm. more about this in a blog post https://techcommunity.microsoft.com/t5/microsoft-mvp-award-program-blog/friday-five-azure-free-smtp-…  Azure VM vs Disk vs Costs


This article was originally published by Microsoft's ITOps Talk Blog. You can find the original article here.