Microsoft announced Automatic Zone Placement for Azure Virtual Machine Scale Sets in public preview on September 9, 2026. Azure can choose availability zones using SKU availability, capacity signals, and the placement requirements you configure.
The feature supports Uniform and Flexible orchestration. It is aimed at teams that want zonal deployments without maintaining a different fixed zone list for every region. Read the Azure Compute announcement.
This is a placement capability, not an application failover service or a guarantee that every scale-out request will succeed. For cloud engineers, the opportunity is to simplify deployment configuration while keeping resilience requirements explicit.
What Azure Chooses Automatically
The announced default behavior targets an even spread across three zones, requires at least two zones, and limits one zone to 50 percent of instances. Where a region has additional eligible zones, placement can expand beyond three when existing zones cannot satisfy scale-out.
You can configure placement constraints instead of relying on those defaults. The important operational boundary is that placement happens when new VMs are created. Enabling it does not relocate the existing fleet.
That makes this a distinct implementation update from our recent two-zone versus three-zone architecture discussion. The architecture defines what the workload needs; the placement policy helps express how new compute instances may be allocated.
Check Preview Eligibility Before Changing Templates
Microsoft's configuration guide requires Compute API 2026-03-01 or later, registration of Microsoft.Compute/VmssAutomaticZonePlacement, and a public Azure region supporting availability zones.
Preview limitations include no proximity placement groups, capacity reservation groups, Instance Mix, standby pools, dedicated host groups, edge zones, or Service Fabric scale sets. Overprovisioning must be disabled. Customer-selected zones and automatic placement cannot be configured together.
There is also an important migration warning: a regional scale set cannot return to regional placement after automatic zone placement is enabled. Existing regional instances remain regional; newly created instances become zonal. Configuration, prerequisites, and limitations.
My recommendation is to review the whole scale-set model before adding a flag to a shared deployment template. A preview-compatible lab configuration does not prove that the same change is compatible with the production fleet.
Expect Partial Allocation, Not Just Success or Failure
The configuration guide explains that Azure may create the instances allowed by the placement policy while other requested instances fail to provision. A successful subset does not mean the desired capacity was reached.
My monitoring recommendation is to distinguish three counts: requested instances, provisioned instances, and instances healthy enough to serve work.
For an illustrative worker service requesting twelve instances, ten provisioned VMs and eight healthy workers represent different problems. The first needs allocation investigation; the second also needs application-startup investigation. Do not let a dashboard collapse both into “deployment completed.”
Use a clearly defined shortfall threshold and an owner for the alert. Otherwise, an automated deployment can leave a team with less capacity than it planned for without a clear next action.
Placement and Rebalancing Are Different
Microsoft documents Automatic Zone Balance separately. That preview can correct an existing imbalance through a create-before-delete process, temporarily adding a VM and then removing another. Its guidance warns that it is not a zone-down recovery mechanism. Automatic Zone Balance overview.
Do not enable both capabilities in the first experiment simply because their names sound related. My recommendation is to test placement first, then evaluate rebalancing as a separate operational change with its own health, quota, and instance-replacement requirements.
A Practical Nonproduction Pilot
I would start with a disposable stateless worker scale set and a representative application image. This is a suggested evaluation, not a claim that the feature has been tested on your workload.
Capture the starting configuration, instance distribution, quota headroom, and normal startup time. Then perform a modest scale-out and examine each new instance's zone and application health.
The acceptance checklist should include:
New instances stay within the intended placement constraints.
The deployment reports any requested capacity that was not created.
The application becomes healthy within the agreed startup window.
Existing VM identities and placement remain unchanged by enabling placement.
Alerting reaches the engineer responsible for capacity shortfalls.
Test resources and any billable dependencies have an explicit cleanup owner.
For migrations, document the intended end state of the old instances. Leaving them untouched can be appropriate, but it should be an acknowledged transition state, not evidence that the whole fleet has already become zone-resilient.
Practical Cloud Engineer Takeaway
Review whether fixed zone lists are solving a real application requirement or merely preserving old deployment assumptions. Pilot automatic placement where flexibility is acceptable, and keep explicit placement where the workload genuinely requires it.
Do not relax a resilience constraint solely to make a deployment turn green. First agree what reduced capacity or concentration in one zone means for the customer-facing service.
Who Should Care?
Platform engineers deploying VM Scale Sets across regions, teams managing SKU availability differences, and operators investigating recurring scale-out allocation failures.
Bottom Line
Automatic Zone Placement moves zone selection closer to current capacity conditions. The useful outcome is simpler configuration with observable allocation behavior, not less responsibility for workload recovery.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments