Azure VM Scale Sets Automatic Zone Placement Preview: Setup, Limits and Capacity Risks

Microsoft's Azure Compute team said the preview lets Azure select availability zones for your scale set based on SKU availability, capacity, and your placement requirements. It is supported for scale sets using either Uniform or Flexible orchestration modes. The Azure Updates entry appeared on September 29, 2026, but it trails the actual launch: Microsoft announced Automatic Zone Placement for Azure Virtual Machine Scale Sets in public preview on September 9, 2026.

Preview terms apply. Microsoft Learn says the feature is still in preview, falls under the supplemental terms of use and may change before general availability (GA).

The problem it solves​

Microsoft describes the pain point plainly. SKU availability and capacity can vary between zones and regions. A configuration that works in one region might require a different zone selection in another, adding complexity to large-scale and multi-region deployments.

Here's what that looks like in practice. Your infrastructure-as-code template says zones: ["1","2","3"] and works in one region. In another region, the VM size you want isn't offered in zone 3. Now you need a second version of the template, and you have to keep both versions current by hand. The traditional approach, per Microsoft's customer-selected zones guidance, is to verify that your VM size and disk types are available in the zones that you want to use. Use the Compute Resource SKUs API to determine which sizes are available in each zone.

That guidance also marks the boundary between the two models. Use customer-selected zones when your workload must use specific availability zones. If you want Azure to select zones based on capacity and SKU availability, consider automatic zone placement.

In short: automatic placement replaces manual SKU-by-zone checks with a policy. It does not guarantee capacity. As one independent analysis put it, this is a placement capability, not an application failover service or a guarantee that every scale-out request will succeed.

How the default policy behaves​

Microsoft Learn's configuration guide says that when you add no other constraints, automatic placement:

• aims for an even spread across three availability zones
• requires instances to span at least two zones
• caps any single zone at 50% of the scale set's instances, even if you never set a per-zone limit
• can grow into more zones if the current zones run out of capacity and the region has another zone available

The 50% cap is the part to understand before you enable the feature. Microsoft's own example is a request for 100 instances where the three zones have capacity for 70, 30 and 0. Azure aims for 50/30/20. The third zone has nothing, so you end up with 50/30/0, and 20 instances fail to provision.

Microsoft calls this a partial allocation failure, not a failure of the whole request. Your scale set comes up short rather than failing outright. That's gentler in one sense, but your monitoring has to be able to spot it.

The knobs you can turn​

The only required property is placement.zonePlacementPolicy set to "auto". The rest are optional:

Microsoft documents the math for the per-zone cap:

• Minimum valid percentage = ceil(100 ÷ number of eligible zones). With includeZones set to 1, 2 and 4 and maxZoneCount set to 2, only two zones count, so the minimum is 50.
• Maximum instances in one zone = ceil(percentage × target capacity ÷ 100). At 85% of 101 instances, that's up to 86 in one zone.

Raising the cap means you care more about getting all your instances than about spreading them out. In Microsoft's 85% example, with zone capacity of 90/10/0, Azure places 85/10/0 and only five instances fail instead of twenty. You get more of your VMs, but more of them now depend on a single zone. Whether that's acceptable depends on how your application behaves if that zone goes down.

Strict balancing works the other way. Microsoft warns that when Azure can't keep the zones balanced because of capacity or zone availability, the instances that don't fit fail to provision. Strict balancing can therefore mean fewer successful allocations than best-effort mode.

Getting started: prerequisites and steps​

Before you begin, Microsoft Learn lists three requirements:

1. Use Compute API version 2026-03-01 or later.
2. Deploy in a public Azure region that supports availability zones.
3. Register the subscription for the AFEC feature flag Microsoft.Compute/VmssAutomaticZonePlacement.

Register the flag in the Azure portal: go to Subscriptions → select your subscription → Settings → Preview features → search for VmssAutomaticZonePlacement → Register.

Or register it with the Azure CLI:

az feature register --namespace Microsoft.Compute --name VmssAutomaticZonePlacement
az feature show --namespace Microsoft.Compute --name VmssAutomaticZonePlacement

Or with PowerShell: use Register-AzProviderFeature and Get-AzProviderFeature with -ProviderNamespace Microsoft.Compute -FeatureName VmssAutomaticZonePlacement.

Create a scale set with the default policy (CLI):

az vmss create \
  --resource-group myResourceGroup \
  --name myScaleSet \
  --image Ubuntu2204 \
  --admin-username azureuser \
  --generate-ssh-keys \
  --instance-count 3 \
  --zone-placement-policy Auto

Microsoft's CLI examples add these options for the other controls:

• --include-zones 1 2 or --exclude-zones 3 to set eligible zones
• --instance-percent-policy true --max-instance-percent 85 to change the per-zone cap
• --zone-balance true --max-zone-count 3 for strict balancing

In PowerShell, New-AzVmssConfig accepts -ZonePlacementPolicy "Auto" along with -IncludeZone/-ExcludeZone, -EnableMaxInstancePercentPerZone/-MaxInstancePercentPerZoneValue and -ZoneBalance/-MaxZoneCount. You still have to fill in the operating system, storage and network profiles before deploying.

Signs it worked: new instances land in zones Azure picked, within the limits you set. Signs of trouble: check first for an unregistered feature flag, an older API version, or overprovisioning left switched on (see below).

Converting existing scale sets: read this first​

You can switch on automatic placement for scale sets that currently use customer-selected zones or regional placement. Both cases have rules:

• Customer-selected zones: clear zones and set zonePlacementPolicy to auto in the same update. In the CLI, that's az vmss update ... --zone-placement-policy Auto --set zones=[]. The two settings can't exist together.
• Regional scale sets: Microsoft warns that once you enable automatic placement, you can't return to regional placement. Existing regional instances stay regional, but every new instance goes into an availability zone. Microsoft recommends reading its "Prepare for zone expansion" guidance first.
• Only new instances are affected. Existing VMs are not moved or recreated, and automatic placement won't fix an existing imbalance.
• You can go back to customer-selected zones: clear zonePlacementPolicy and set zones in one update. Existing instances still don't move.

How it relates to Automatic Zone Balance​

Microsoft points to its separate Automatic Zone Balance feature for fixing an existing imbalance. That's a different feature with its own preview, flag and requirements, so it helps to know how they differ. Automatic Zone Balance continuously monitors your scale set and redistributes VMs across availability zones, working by moving VMs across availability zones using a create-before-delete approach.

It has its own requirements:

• It is supported for Compute API version 2024-07-01 or higher.
• It uses a different flag: Microsoft.Compute.AutomaticZoneRebalancing.
• It excludes one group entirely: scale sets that contain regional (non-zonal) VMs don't qualify for automatic zone balance.

That last requirement matters if you plan to convert a regional scale set. This is my reading of the two documents together, not something Microsoft states outright: after conversion, the leftover regional instances still count as regional VMs. Automatic Zone Balance won't be an option until those instances are gone. That's another reason to plan a regional-to-zonal move carefully rather than flipping the setting and hoping for the best.

Automatic Zone Balance also isn't disaster recovery. Microsoft says it doesn't monitor Virtual Machine (VM) health for zone outages and shouldn't be used as a zone-down recovery mechanism.

Preview limitations​

According to Microsoft Learn, the preview does not support:

• Proximity placement groups or capacity reservation groups
• Instance Mix for VMSS (Microsoft expects support by GA but doesn't guarantee it)
• Standby pools, dedicated host groups or edge zones
• Overprovisioning. Set overprovision to false before adding the placement policy, or the deployment fails.
• Service Fabric scale sets
• Creating and attaching a new VM. You can attach an existing zonal VM if its zone fits the placement rules.

The capacity reservation exclusion stands out. Teams that most want guaranteed capacity often buy reservations, and during the preview they can't combine reservations with Azure-chosen zones.

Bottom line​

The main benefit is less template maintenance: one scale-set definition can work across regions whose zones offer different VM sizes. The main risk is misreading the defaults. The 50% per-zone cap and strict balancing can both leave a scale-out short, and converting a regional scale set can't be undone.

Test in non-production environments first, check that your alerts catch partially provisioned scale sets, and decide deliberately how much you'll trade even spread for getting all your instances. Azure will pick the zones, but choosing that trade-off is still your job.