AzureFeeds

When a Virtual Machine Scale Set needs to scale out, it normally uses a single VM size (also known as SKU). Whilst that is simple, it can also become a constraint. For example the scale out might be limited if that specific size has limited regional capacity, quota pressure, or a price profile that is not ideal for every scale-out event.

Instance Mix for Azure Virtual Machine Scale Sets allows you to configure your scale out with more options by define multiple compatible VM sizes in a single scale set. When scaling out, Azure can choose from your list during provisioning based on the allocation strategy you select.

What is Instance Mix?

Instance Mix is a Virtual Machine Scale Sets capability that lets you specify up to five VM sizes for a single scale set that uses Flexible orchestration mode. Instead of setting the scale set to a single size such as Standard_D2s_v5, you set the scale set SKU name to Mix and define the real VM sizes in the skuProfile.

At provisioning time, Azure uses the skuProfile.vmSizes list and the selected allocation strategy to decide which VM size to deploy.

The high-level model looks like this:

{

  “sku”: {

    “name”: “Mix”,

    “capacity”: 2

  },

  “properties”: {

    “skuProfile”: {

      “vmSizes”: [

        { “name”: “Standard_D2s_v5” },

        { “name”: “Standard_D2as_v5” },

        { “name”: “Standard_D2s_v4” }

      ],

      “allocationStrategy”: “CapacityOptimized”

    }

  }

}

You can use this if your workload can run on more than one VM size and you want to improve provisioning success, optimize for cost, or align allocation with reservations or savings plans.

When should you use Instance Mix?

Instance Mix is a good fit when:

• Your application can run correctly on several similar VM sizes.


• You want scale-out to have more than one capacity option in a region.


• You run Spot VMs and want Azure to prefer lower-priced capacity when available.


• You have reservations for specific sizes, or want to favor VM sizes with better savings-plan economics, and need predictable priority.


• You want one scale set instead of several separate scale sets for equivalent worker capacity.

It is usually best for stateless or horizontally scalable workloads, such as web front ends, API tiers, queue workers, batch workers, and other scale-out services where each instance performs the same role.

Avoid using Instance Mix as a way to combine very different machines in one pool. For example, mixing a small general-purpose VM with a much larger memory-optimized VM can make capacity planning, load distribution, and performance troubleshooting harder. Best practice is to use sizes with similar vCPU and memory for balanced load distribution and similar VM types for consistent performance.

Key requirements and limits

Before you deploy, check these requirements:

Microsoft Learn currently states that all public Azure regions support Instance Mix. VM size availability and quota still vary by region and subscription, so you should check the exact sizes you plan to use before deploying.

Choose an allocation strategy

Instance Mix supports three allocation strategies.

Rank note: Use rank only with Prioritized. Ranks are optional with Prioritized; when specified, lower numbers have higher priority, and rank values can be duplicated or non-sequential. Omit ranks for LowestPrice and CapacityOptimized.

For many operations teams, CapacityOptimized is a practical starting point for production scale sets because it is designed to improve the chance of successful provisioning. For Spot-heavy or highly cost-sensitive workloads, LowestPrice may be a better first choice. If you have reservations for specific sizes, or want to favor VM sizes with better savings-plan economics, use Prioritized and rank those reservation-backed or preferred sizes first.

Walkthru Prereqs

The commands below are Bash-specific. Use Azure Cloud Shell in Bash mode or another Bash environment with Azure CLI installed.

You need:

• An Azure subscription.


• Permission to create resource groups, networking, and Virtual Machine Scale Sets.


• Azure CLI version 2.66.0 or later.


• An SSH-capable client if you plan to connect to the Linux instances.

Check your Azure CLI version:

az version –query ‘”azure-cli”‘ –output tsv

Sign in and select the subscription you want to use:

az login

az account set –subscription “”

Set variables for the example:

RG=”rg-vmss-instancemix-demo”

LOCATION=”australiaeast”

VMSS=”vmss-instancemix-demo”

ADMIN_USER=”azureuser”

You can change LOCATION to another public Azure region if you don’t feel like sharing a datacenter rack with drop bears and the occasional kangaroo. Keep the VM sizes in the examples compatible if you change regions or families.

Step 1: Check VM size availability in the region

Before creating the scale set, check that the candidate VM sizes are available in your target region and subscription.

az vm list-skus

  –location “$LOCATION”

  –resource-type virtualMachines

  –size Standard_D

  –all

  –output table

For this walkthrough, we will use these D-series sizes:

• Standard_D2s_v5


• Standard_D2as_v5


• Standard_D2s_v4

In the az vm list-skus output, check the Restrictions column. If a size is restricted in your region or subscription, choose another compatible size or deploy in a different region.

Step 2: Check quota

Instance Mix does not automatically request quota. If one size in the mix lacks quota, Azure can try another size from the list that has quota. If none of the eligible sizes has enough quota, deployment or scale-out can fail.

Check current regional VM quota and usage:

az vm list-usage

  –location “$LOCATION”

  –output table

Look for:

• Total Regional vCPUs


• The family quota rows that match your selected VM sizes, such as DSv5, DASv5, or DSv4 family vCPUs

If quota is too low, either request a quota increase or choose sizes that have available quota in the target region.

Step 3: Create a resource group

Create a resource group for the demo:

az group create

  –name “$RG”

  –location “$LOCATION”

Step 4: Create a VM Scale Set with Instance Mix

The key settings are:

• –orchestration-mode Flexible


• –vm-sku Mix


• –skuprofile-vmsizes


• –skuprofile-allocation-strategy

Create the scale set:

az vmss create

  –resource-group “$RG”

  –name “$VMSS”

  –location “$LOCATION”

  –orchestration-mode Flexible

  –image Ubuntu2204

  –vm-sku Mix

  –skuprofile-vmsizes Standard_D2s_v5 Standard_D2as_v5 Standard_D2s_v4

  –skuprofile-allocation-strategy CapacityOptimized

  –instance-count 2

  –admin-username “$ADMIN_USER”

  –generate-ssh-keys

This creates a Flexible orchestration scale set with two instances. Because the scale set uses Instance Mix, the scale set SKU name is Mix, and the allowed VM sizes are stored in skuProfile.vmSizes.

Do not expect every VM size in the list to appear immediately. Azure may deploy all initial instances using the same VM size if that satisfies the selected allocation strategy and capacity is available. The point of Instance Mix is to give Azure more eligible choices during provisioning and scaling.

Step 5: Verify the Instance Mix configuration

View the complete skuProfile:

az vmss show

  –resource-group “$RG”

  –name “$VMSS”

  –query “skuProfile”

  –output jsonc

Example output:

{

  “allocationStrategy”: “CapacityOptimized”,

  “vmSizes”: [

    {

      “name”: “Standard_D2s_v5”

    },

    {

      “name”: “Standard_D2as_v5”

    },

    {

      “name”: “Standard_D2s_v4”

    }

  ]

}

View only the configured VM sizes:

az vmss show

  –resource-group “$RG”

  –name “$VMSS”

  –query “skuProfile.vmSizes[].name”

  –output tsv

View only the allocation strategy:

az vmss show

  –resource-group “$RG”

  –name “$VMSS”

  –query “skuProfile.allocationStrategy”

  –output tsv

List the current instances and their VM sizes. Because Flexible orchestration instances are standard Azure VMs, use az vm list for full instance details and filter by the scale set resource ID:

VMSS_ID=$(az vmss show

  –resource-group “$RG”

  –name “$VMSS”

  –query id

  –output tsv)

az vm list

  –resource-group “$RG”

  –query “[?virtualMachineScaleSet.id==’$VMSS_ID’].{Name:name, VMSize:hardwareProfile.vmSize, ProvisioningState:provisioningState}”

  –output table

Step 6: Scale out and observe allocation

Scale the set from two instances to five:

az vmss scale

  –resource-group “$RG”

  –name “$VMSS”

  –new-capacity 5

List the instances again:

VMSS_ID=$(az vmss show

  –resource-group “$RG”

  –name “$VMSS”

  –query id

  –output tsv)

az vm list

  –resource-group “$RG”

  –query “[?virtualMachineScaleSet.id==’$VMSS_ID’].{Name:name, VMSize:hardwareProfile.vmSize, ProvisioningState:provisioningState}”

  –output table

You may see one VM size or several VM sizes. The result depends on allocation strategy, quota, regional capacity, and the sizes in your skuProfile.

Step 7: Add autoscale

Instance Mix does not require autoscale, but it becomes especially useful when a workload scales out under demand. Autoscale asks the scale set to add instances; Instance Mix gives Azure multiple eligible VM sizes to use for those new instances.

Create an autoscale profile:

az monitor autoscale create

  –resource-group “$RG”

  –resource “$VMSS”

  –resource-type Microsoft.Compute/virtualMachineScaleSets

  –name “vmss-autoscale”

  –min-count 2

  –max-count 10

  –count 2

Create a scale-out rule that adds two instances when average CPU is greater than 70 percent for five minutes:

az monitor autoscale rule create

  –resource-group “$RG”

  –autoscale-name “vmss-autoscale”

  –condition “Percentage CPU > 70 avg 5m”

  –scale out 2

Create a scale-in rule that removes one instance when average CPU is less than 30 percent for five minutes:

az monitor autoscale rule create

  –resource-group “$RG”

  –autoscale-name “vmss-autoscale”

  –condition “Percentage CPU < 30 avg 5m"

  –scale in 1

Tune these thresholds for your workload. Scale out aggressively enough to protect availability, and scale in conservatively enough to avoid unnecessary churn.

Step 8: Update the VM sizes in the mix

You can change the VM sizes in an existing Instance Mix configuration. The important detail is that updating –skuprofile-vmsizes replaces the full list. It does not add or remove a single size incrementally.

For example, this command replaces the mix with four sizes:

az vmss update

  –resource-group “$RG”

  –name “$VMSS”

  –skuprofile-vmsizes Standard_D2s_v5 Standard_D2as_v5 Standard_D2s_v4 Standard_D2as_v4

If you want to remove a size, specify the full list of sizes you want to keep. If you want to add a size, specify the full existing list plus the new size.

Verify the new list:

az vmss show

  –resource-group “$RG”

  –name “$VMSS”

  –query “skuProfile.vmSizes[].name”

  –output tsv

Step 9: Change the allocation strategy

You can also update the allocation strategy.

For example, this changes the walkthrough scale set from its original CapacityOptimized strategy to LowestPrice. Use this as a real update example, not as a blanket production recommendation:

az vmss update

  –resource-group “$RG”

  –name “$VMSS”

  –set skuProfile.allocationStrategy=LowestPrice

When you change the allocation strategy, existing VMs are not immediately reshaped. The new strategy takes effect after the scale set scales in or out.

If you change from Prioritized to another allocation strategy, Microsoft Learn notes that you must first nullify the priority ranks associated with the VM sizes.

Step 10: Enable Instance Mix on an existing scale set

You can enable Instance Mix on a separate existing scale set if it uses Flexible orchestration mode, does not already use Instance Mix, and the selected VM sizes are compatible. Do not run this procedure against the $VMSS scale set created earlier, because that scale set is already Instance Mix-enabled.

The required settings are:

• Set sku.name to Mix.


• Set sku.tier explicitly to null unless you have confirmed it is already null or absent.


• Provide at least one VM size in skuProfile.vmSizes.


• Provide an allocation strategy, or let Azure use the default lowest-price strategy.

Set a separate variable for the existing scale set you want to convert:

EXISTING_VMSS=”my-existing-flex-vmss”

Example:

az vmss update

  –resource-group “$RG”

  –name “$EXISTING_VMSS”

  –set sku.name=Mix sku.tier=null

  –skuprofile-vmsizes Standard_D2as_v4 Standard_D2s_v5 Standard_D2as_v5

  –set skuProfile.allocationStrategy=CapacityOptimized

As with other Instance Mix updates, existing VM instances are not necessarily changed immediately. The configuration is used for subsequent scale actions.

Portal procedure

If you prefer the Azure portal:

1. Go to Virtual machine scale sets.


2. Select Create.


3. On the Basics tab, choose the subscription, resource group, scale set name, region, image, and administrator settings.


4. Set Orchestration mode to Flexible.


5. In the Size section, choose Select up to 5 sizes.


6. Select up to five compatible VM sizes.


7. Choose the Allocation strategy.


8. If you choose Prioritized (preview), a Rank size section appears below Allocation strategy. Select Rank priority to open the prioritization blade and order the VM sizes based on your preferred priority.


9. Complete the remaining tabs for networking, management, health, scaling, and advanced settings.


10. Select Review + create, then create the scale set.

After deployment, open the scale set and check the Overview blade. In the Properties section, check Size for the configured VM sizes and Management for the allocation strategy.

Operational tips

Use similar sizes for predictable application behavior

For web, API, and worker tiers, choose sizes with similar vCPU and memory. This makes autoscale behavior easier to reason about and helps load distribution remain balanced.

Do not rely on Instance Mix as a quota workaround

Instance Mix can use another listed size if one size lacks quota, but it does not request quota for you. Check quota before production deployment, especially if your autoscale maximum is high.

Align reservations and savings plans with Prioritized

Reserved instance pricing and savings-plan discounts can apply with Instance Mix. If you want to consume reservation-backed sizes first, or favor sizes with better savings-plan economics, use the Prioritized strategy and rank those sizes first.

Use Spot Priority Mix for Spot plus Standard

Instance Mix can be used with both Spot and Standard VMs. The Instance Mix FAQ says to use Spot Priority Mix when you need a defined split between Spot and Standard capacity.

Caveat: Instance Mix supports B-family sizes for regular capacity, but Azure Spot VMs do not support B-series or promo versions of any size. If your scale set will use Spot capacity, choose Spot-supported sizes for the mix.

Be careful with unsupported properties

If a deployment template includes unsupported properties such as Azure Dedicated Host, on-demand capacity reservation, Standby Pools, Proximity Placement Groups, or OS disk diffDiskSettings, remove those settings before using Instance Mix.

Troubleshooting common deployment errors

 

Instance Mix gives your operations team a practical way to make scale sets more flexible. By defining several compatible VM sizes and selecting the right allocation strategy, you can improve scale-out success, give Azure more capacity choices, and better align VM allocation with cost or reservation goals.

For most production workloads, start with similar VM sizes, verify regional availability and quota, use Flexible orchestration mode, and test scale-out behavior before relying on the configuration in a critical environment.

Further reading on Microsoft Learn:

Use multiple Virtual Machine sizes with instance mix

Create a scale set using instance mix

Orchestration modes for Virtual Machine Scale Sets

Update instance mix settings on an existing scale set

Instance Mix FAQ and troubleshooting