This chapter covers Proximity Placement Groups (PPGs) in Azure, a critical compute feature for latency-sensitive workloads. On the AZ-104 exam, PPGs appear in approximately 5-10% of questions, often combined with availability sets, zones, or scale sets. Understanding when and how to use PPGs — and their limitations — is essential for designing high-performance Azure solutions. You will learn the internal mechanism, configuration steps, and exam traps to avoid.
Jump to a section
Imagine a concert venue with thousands of seats. If you buy two tickets, you might get seat 1 in Section A and seat 500 in Section Z — far apart, with high latency to share a drink. Proximity Placement Groups (PPGs) are like buying adjacent seats in the same row. The venue manager (Azure) guarantees that all VMs in the group are placed in the same 'section' (datacenter rack or cluster) to minimize the physical distance between them. However, this adjacency comes with a trade-off: if the row is full, you cannot add more seats (VMs) to that group; you may need to wait for someone to leave or accept seats elsewhere. Also, if you need to move to a different row (change VM size or availability zone), you might lose adjacency. The venue manager can also create 'intent' bookings (proximity placement groups) before tickets are sold, ensuring that when you buy later, you get seats as close as possible, but not guaranteed adjacent. This mirrors how PPGs work: they influence placement but do not guarantee absolute proximity under all conditions.
What is a Proximity Placement Group?
A Proximity Placement Group (PPG) is a logical grouping that ensures Azure VMs are physically located close to each other within an Azure datacenter. It is used to reduce network latency between VMs, typically for high-performance computing (HPC), SAP workloads, or distributed applications that require low-latency communication. PPGs are not a high-availability feature like availability sets or availability zones; they are a performance optimization.
Why Proximity Placement Groups Exist
Azure datacenters are massive facilities with thousands of servers across multiple racks, clusters, and network segments. Without a PPG, VMs in the same virtual network or even the same subnet can be placed on different racks or even different clusters, introducing network hops and latency. For workloads that require single-digit millisecond latency or use InfiniBand (e.g., MPI applications), this variance is unacceptable. PPGs influence the Azure Fabric Controller to co-locate VMs within the same datacenter 'stamp' (a cluster of servers sharing a network spine).
How PPGs Work Internally
When you create a PPG, you define a logical container in a specific Azure region (and optionally an availability zone). The PPG does not consume resources; it is a metadata object. When you create a VM and reference the PPG, the Azure Fabric Controller attempts to place the VM's physical host within the same datacenter cluster as other VMs in the group. The placement algorithm considers:
Available capacity in the cluster
VM size constraints (some sizes may not be available in all clusters)
Availability zone constraints (if specified)
Existing PPG members
If the Fabric Controller cannot place a new VM within the same cluster (due to capacity or size limitations), the VM creation fails with a 'AllocationFailed' error. This is a key exam point: PPGs are a hard constraint — Azure will not place the VM elsewhere if the group is full.
Key Components and Defaults
PPG Type: There are two types — Standard (default) and Intent. Standard PPGs attempt to place VMs in the same cluster but may allow placement in the same datacenter but different clusters if capacity is insufficient (this is a recent change; older behavior was strict co-location). Intent PPGs allow you to specify a 'zonal' or 'non-zonal' intent, influencing placement without guaranteeing absolute proximity.
Availability Zone Support: PPGs can be associated with a specific availability zone. If you specify a zone, all VMs in the PPG must be in that zone. If you do not specify a zone, VMs can be in any zone within the region, but the PPG will still try to co-locate them.
VM Sizes: Not all VM sizes are supported in PPGs. Generally, all sizes that support availability sets are supported, but check documentation for exceptions (e.g., some GPU sizes may have restrictions).
Limits: A PPG can contain up to 100 VMs. There is no limit on the number of PPGs per subscription, but regional capacity limits apply.
Configuration and Verification
You can create a PPG using Azure CLI, PowerShell, or the portal.
Azure CLI example:
az ppg create --name myPPG --resource-group myRG --location eastus --type standardTo create a VM in the PPG:
az vm create --name myVM --resource-group myRG --ppg myPPG --image UbuntuLTS --admin-username azureuser --generate-ssh-keysVerification:
az ppg show --name myPPG --resource-group myRG --query "colocationStatus" -o tsvThe output shows 'Colocated' if all VMs are in the same cluster, or 'Not colocated' if they are in different clusters (but same datacenter). Note: 'Not colocated' does not mean the PPG is broken; it means Azure could not achieve strict co-location but kept VMs close.
Interaction with Related Technologies
Availability Sets: You can use a PPG with an availability set. The PPG ensures the VMs are close, while the availability set ensures they are in different fault/update domains. However, this combination can reduce placement success because the Fabric Controller must satisfy both constraints.
Availability Zones: PPGs can be used within a single zone. You cannot span a PPG across multiple zones. If you need cross-zone low latency, you must use multiple PPGs.
Virtual Machine Scale Sets (VMSS): PPGs can be associated with a VMSS to ensure all instances are co-located. This is common for HPC clusters.
Azure NetApp Files: PPGs can also be used with Azure NetApp Files volumes to place storage close to compute.
Limitations and Caveats
No guarantee of absolute proximity: PPGs are a best-effort placement. In rare cases, VMs may be placed in different clusters within the same datacenter.
No support for moving VMs: You cannot move an existing VM into a PPG if it is already running. You must delete and recreate it.
No support for updating PPG type: Once created, you cannot change the PPG type (standard vs intent).
Cost: PPGs themselves are free, but they may lead to higher costs if they prevent you from using cheaper, scattered capacity.
Exam-Relevant Numbers
Maximum VMs per PPG: 100
Supported VM sizes: Most, but check for exceptions
PPG types: Standard, Intent
PPG location: Same region, optionally a single availability zone
Allocation failure: Occurs when the cluster is full for the requested VM size
Identify latency-sensitive workloads
Determine if your application requires low latency between VMs (e.g., <1ms RTT). Common candidates: HPC, SAP, real-time analytics, distributed databases. If latency is not critical, do not use PPGs — they add complexity and potential allocation failures.
Choose region and availability zone
Select the Azure region and optionally one availability zone for the PPG. Remember: PPGs cannot span zones. If you need low latency across zones, you need multiple PPGs. For non-zonal PPGs, VMs can be in any zone but will be co-located within the same zone if possible.
Create the Proximity Placement Group
Use Azure CLI, PowerShell, or portal to create a PPG. Specify type: standard (default) or intent. Intent PPGs are newer and allow more flexible placement. Example CLI: `az ppg create --name myPPG --resource-group myRG --location eastus --type standard`. The PPG is a regional resource.
Create VMs referencing the PPG
When creating VMs, specify the PPG ID. The Fabric Controller will attempt to place the VM in the same cluster as existing PPG members. If the cluster is full, the VM creation fails. Example CLI: `az vm create --name myVM --resource-group myRG --ppg myPPG --image UbuntuLTS --admin-username azureuser --generate-ssh-keys`. You can also add VMs to an existing PPG by updating the VM's PPG property, but this is only possible during creation.
Verify colocation status
After VMs are created, check the PPG's colocation status using `az ppg show --name myPPG --resource-group myRG --query "colocationStatus" -o tsv`. Output is 'Colocated' or 'Not colocated'. If 'Not colocated', VMs are still in the same datacenter but not the same cluster — latency may be slightly higher. This status can change over time if VMs are deallocated/started.
Monitor and adjust
If you receive allocation failures, consider: reducing the number of VMs, changing VM sizes, or removing the PPG if not critical. You cannot add VMs to a PPG that has reached capacity (100 VMs). Also, deallocating VMs releases their placement, so subsequent start operations may result in different placement.
Enterprise Scenario 1: High-Performance Computing (HPC) Cluster
A research lab deploys a 50-node MPI cluster using Azure HPC VMs (e.g., HB120rs_v3). They create a PPG in the West US region and deploy all VMs into it. The PPG ensures all VMs are on the same InfiniBand fabric, achieving sub-10µs latency. Without the PPG, VMs could be placed on different racks, forcing traffic through the network spine, increasing latency to 100µs+ and degrading MPI performance. In production, they monitor colocation status and have a script that alerts if it becomes 'Not colocated'. They also use a VMSS with the PPG to auto-scale while maintaining proximity. A common issue: when scaling up, if the cluster is full, new VM instances fail to create. They mitigate by over-provisioning capacity or using intent PPGs that allow slightly relaxed placement.
Enterprise Scenario 2: SAP HANA Multi-Node Deployment
A company runs SAP HANA on Azure using multiple VMs for scale-out. They need low latency between the HANA nodes and also between the application tier and database tier. They create two PPGs: one for the HANA nodes (all in availability zone 1) and another for the application VMs (in the same zone). The PPGs ensure that all HANA nodes are in the same cluster, and the app VMs are close to the database. They also use availability sets within the PPG to protect against hardware failures. A misconfiguration: they initially used a single PPG for both tiers, but the application VMs were placed in a different cluster due to capacity, causing higher latency. They learned to separate tiers into different PPGs for better control.
Performance Considerations
In production, PPGs can cause allocation failures during peak usage. For example, during a major cloud provider outage in a region, many customers redeploy VMs, filling clusters. PPG users may be unable to deploy new VMs until capacity frees up. To mitigate, use reserved instances or capacity reservations. Also, deallocating VMs (stop deallocate) releases the placement, so restarting may break colocation. To maintain colocation, use stop (not deallocate) or avoid stopping VMs altogether.
What Goes Wrong
Allocation failures: The most common issue. Solution: reduce VM count, change size, or remove PPG.
Colocation status loss: After a VM is deallocated and restarted, it may land in a different cluster. Solution: avoid deallocation; use stop instead.
Mixing zones: Attempting to add a VM from a different zone to a zonal PPG fails. Solution: create separate PPGs per zone.
Exactly What AZ-104 Tests
AZ-104 objective 3.1 (Configure virtual machines) includes PPGs under 'Implement proximity placement groups'. The exam tests:
When to use PPGs vs availability sets vs zones
How to create and associate VMs with PPGs
Limitations: maximum VMs (100), no cross-zone support, allocation failures
Colocation status interpretation
Impact on VMSS and availability sets
Common Wrong Answers and Why
'PPGs guarantee low latency across availability zones' — Wrong. PPGs cannot span zones. If you need low latency across zones, you need multiple PPGs or other solutions (e.g., ExpressRoute).
'PPGs are a high-availability feature like availability sets' — Wrong. PPGs are for performance, not HA. They do not provide fault domain isolation. In fact, PPGs can reduce HA because all VMs are in the same rack.
'You can add existing VMs to a PPG without redeploying' — Wrong. VMs must be created in the PPG. You cannot move a running VM into a PPG.
'PPGs guarantee colocation at all times' — Wrong. Colocation is best-effort. The status can become 'Not colocated' after deallocation/restart.
Specific Numbers and Terms
100 VMs per PPG
Colocation status: 'Colocated' or 'Not colocated'
PPG types: Standard, Intent
AllocationFailed error
Zonal vs non-zonal: Zonal PPGs restrict to one zone
Edge Cases and Exceptions
VMSS with PPG: When scaling out a VMSS with a PPG, new instances may fail if the cluster is full. The exam may ask how to handle this — answer: use manual scaling with capacity buffer.
Deallocated VMs: If you stop deallocate a VM in a PPG, its placement is released. When you start it again, it may be placed in a different cluster, breaking colocation. The exam may test that you should use 'stop' (not deallocate) to preserve placement.
Intent PPGs: Newer and less tested on the exam, but know they exist and allow more flexible placement.
How to Eliminate Wrong Answers
If a question mentions 'low latency across zones', eliminate options that use a single PPG — correct answer uses multiple PPGs or a different technology.
If a question asks about 'high availability', PPG is not the answer; choose availability sets or zones.
If a question says 'add an existing VM to a PPG', it is wrong — you must recreate the VM.
PPGs are used to reduce network latency between VMs, not for high availability.
A PPG can contain up to 100 VMs.
PPGs cannot span availability zones; each PPG is limited to one zone (or no zone).
VMs must be created inside a PPG; you cannot add existing VMs.
Deallocating a VM releases its placement; restarting may break colocation.
Allocation failures occur when the target cluster has insufficient capacity for the requested VM size.
Colocation status shows 'Colocated' (same cluster) or 'Not colocated' (same datacenter, different cluster).
PPGs can be used with availability sets and VMSS for combined benefits and constraints.
These come up on the exam all the time. Here's how to tell them apart.
Proximity Placement Group
Purpose: Reduce latency by co-locating VMs
Does not provide fault domain isolation
Maximum 100 VMs per group
No SLA for uptime; only affects performance
VMs can be in the same zone or no zone
Availability Set
Purpose: High availability by spreading VMs across fault/update domains
Provides up to 3 fault domains and 5 update domains
Maximum 200 VMs per availability set
Supports 99.95% VM SLA when used with two or more VMs
VMs must be in the same availability zone (if zonal) or no zone
Proximity Placement Group (Standard)
Attempts strict co-location in same cluster
Allocation failure if cluster is full
Colocation status can be 'Colocated' or 'Not colocated'
Older, widely supported
No intent specification
Proximity Placement Group (Intent)
Allows more flexible placement with intent
Can specify 'zonal' or 'non-zonal' intent
May succeed even if strict co-location is not possible
Newer, may not be available in all regions
Provides better capacity management
Mistake
Proximity Placement Groups guarantee that all VMs are in the same rack.
Correct
PPGs attempt to place VMs in the same datacenter cluster, which may span multiple racks. They do not guarantee rack-level proximity. The colocation status indicates whether VMs are in the same cluster, not necessarily the same rack.
Mistake
You can use a single PPG to cover multiple availability zones.
Correct
A PPG can be associated with at most one availability zone. If you create a PPG without specifying a zone, VMs can be in any zone, but they will not be co-located across zones. To achieve low latency across zones, you need separate PPGs per zone and other networking solutions.
Mistake
PPGs are free and have no impact on VM availability.
Correct
PPGs are free, but they can reduce VM availability because they constrain placement. If the cluster is full, new VMs cannot be created. Also, all VMs in a PPG are in the same cluster, so a cluster failure could affect all VMs simultaneously — unlike availability sets which spread across fault domains.
Mistake
You can move a running VM into a PPG by updating its properties.
Correct
The PPG property of a VM can only be set at creation time. You cannot modify it for an existing VM. To add a VM to a PPG, you must delete and recreate it.
Mistake
PPGs are only for VMs; they cannot be used with VMSS.
Correct
PPGs can be associated with a Virtual Machine Scale Set (VMSS). This is common for HPC clusters. When you scale out, new instances are placed in the same PPG, subject to capacity.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A Proximity Placement Group (PPG) is designed to reduce latency by co-locating VMs in the same datacenter cluster. It does not provide fault domain isolation. An Availability Set spreads VMs across multiple fault domains and update domains to protect against hardware failures and maintenance. PPGs are for performance; availability sets are for high availability. You can use both together, but it may reduce placement success.
No. A PPG can only be associated with a single availability zone, or no zone at all. If you create a PPG without specifying a zone, VMs can be in any zone, but they will not be co-located across zones. To achieve low latency across zones, you need separate PPGs in each zone and use other networking technologies (e.g., ExpressRoute, VNet peering).
The AllocationFailed error occurs when the Azure Fabric Controller cannot place the VM in the same cluster as other PPG members due to insufficient capacity for the requested VM size. To resolve, try a different VM size, reduce the number of VMs in the PPG, or remove the PPG association. You can also use an Intent PPG which allows more flexible placement.
Use the Azure CLI command: `az ppg show --name <PPG-name> --resource-group <RG> --query "colocationStatus" -o tsv`. The output will be 'Colocated' (all VMs in same cluster) or 'Not colocated' (VMs in different clusters within the same datacenter). You can also check in the portal under the PPG resource.
No. The PPG property of a VM can only be set at creation time. You cannot modify it for an existing VM. To add a VM to a PPG, you must delete the VM and recreate it with the PPG reference. This is a common exam trap.
When you deallocate a VM (stop deallocate), its physical placement is released. When you start the VM again, it may be placed in a different cluster, potentially breaking colocation. To preserve placement, use 'stop' (not deallocate) or avoid stopping VMs altogether. The PPG itself remains, but the colocation status may change to 'Not colocated'.
The maximum is 100 VMs per PPG. This is a hard limit. If you need more, you must create additional PPGs. However, VMs in different PPGs are not necessarily co-located with each other.
You've just covered Proximity Placement Groups — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?