# Treat proximity-placement intent as a compatibility constraint, not reserved capacity

> What does a proximity placement group's VM-size intent establish before deployment, and what remains unguaranteed?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-035-treat-proximity-placement-intent-as-a-compatibility-constraint-not-reserved/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:31:21+00:00
- Modified: 2026-09-10T00:32:00+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Explainer
- DSE priority: Information
- Topics: IT, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

What does a proximity placement group's VM-size intent establish before deployment, and what remains unguaranteed?

## Potentially affected

Teams placing Azure VMs of multiple sizes in a proximity placement group.

## DSE recommendation

Declare the workload's complete intended VM-size combination and keep a separate plan for allocation failure.

## Article

## Source facts

A proximity placement group constrains Azure compute resources to nearby physical placement. Its optional intent lists expected VM sizes so Azure can select a datacenter supporting their combination. Intent neither reserves capacity nor guarantees allocation; deployment can still fail if capacity is exhausted. Changing an existing group’s intent requires all its VMs to be deallocated; intent needs API version 2021-11-01 or later. A zone can accompany intent only at group creation, and that zone choice cannot later be changed. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machines/co-location).

## Applicability

Use this design check when a workload requires proximity across several VM sizes. Ask the application owner to justify that requirement with its own measurements. Identify the full size combination and any intended zone before approving the placement-group definition.

## DSE recommendation

Declare the workload’s complete intended VM-size combination and keep a separate plan for allocation failure. Review an existing group’s intent before introducing a new size or redeploying a removed tier. Have the capacity and application owners agree on an acceptable alternate configuration rather than assuming that successful group creation proves the future deployment will fit. Record the zone choice as a deliberate design decision.

## Verification

Deploy the agreed combination in an approved test and compare the actual resources with the declared intent. Capture any allocation error together with the group definition and requested sizes. Measure the application’s relevant latency rather than accepting proximity configuration as a measured outcome. Before a later size change, repeat the compatibility review and preserve the previous intent so the change can be explained and investigated.

## Official references

[Microsoft Learn: Proximity placement groups](https://learn.microsoft.com/en-us/azure/virtual-machines/co-location). Source reviewed September 9, 2026.

## Primary reference

- Name: Proximity placement groups - Azure Virtual Machines | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/virtual-machines/co-location
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Treat proximity-placement intent as a compatibility constraint, not reserved capacity,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-035-treat-proximity-placement-intent-as-a-compatibility-constraint-not-reserved/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.