Conttext

We encountered a situation where two virtual networks (spokes) in different subscriptions experienced connectivity latency. These spokes belonged to completely separate business applications, one being an Azure Virtual Desktop (AVD) environment. Consolidating them into the same subscription wasn’t feasible due to the specialized nature of the AVD subscription, which is shared with other applications. Also, this wouldn’t solve the underlying issue, as any future spokes needing to interact with the AVD spoke could face similar latency challenges. Despite being in the same region, the spokes couldn’t be placed in the same Proximity Placement Group due to the subscription boundary.

Azure Availability Zones

Azure Availability Zones are physically separate locations within a region, providing redundancy for your applications. While you deploy resources to a specific zone (like “zone 1”), the underlying physical location can differ between your Azure subscriptions.

Why? Azure maps the logical zone IDs (1, 2, 3) to physical zones differently per subscription to ensure balanced resource distribution across its infrastructure.

This means “zone 1” in one subscription might not be the same physical location as “zone 1” in another. This is crucial for scenarios like disaster recovery or interconnecting resources across subscriptions where physical proximity matters.

Once an Azure subscription is created, its zone mapping remains consistent throughout its lifespan. By documenting this mapping, you gain valuable insights into the physical location of your resources across subscriptions.

How to Determine the Mapping

You can use the Azure Resource Manager REST API to reveal this mapping. Here’s a simple bash script to get you started:

location="westeurope" 

peerSubId="your-peer-subscription-id" 

payload=$(cat <<EOF
{
    "location": "$location",
    "subscriptionIds": [
        "subscriptions/$peerSubId"
    ]
}
EOF
)

az rest --method post --uri '[https://management.azure.com/subscriptions/your-subscription-id/providers/Microsoft.Resources/checkZonePeers/?api-version=2022-12-01](https://management.azure.com/subscriptions/your-subscription-id/providers/Microsoft.Resources/checkZonePeers/?api-version=2022-12-01)' --body "$payload" 

Replace the placeholders with your actual values:

• location: The Azure region (e.g., “westeurope”).
• peerSubId: The ID of the subscription you want to compare with.
• your-subscription-id: The ID of your current subscription.

Example Output:

{
  "availabilityZonePeers": [
    {
      "availabilityZone": "1",
      "peers": [
        {
          "availabilityZone": "3",
          "subscriptionId": "your-peer-subscription-id" 
        }
      ]
    },
    {
      "availabilityZone": "2",
      "peers": [
        {
          "availabilityZone": "1",
          "subscriptionId": "your-peer-subscription-id" 
        }
      ]
    },
    {
      "availabilityZone": "3",
      "peers": [
        {
          "availabilityZone": "2",
          "subscriptionId": "your-peer-subscription-id" 
        }
      ]
    }
  ],
  "location": "westeurope",
  "subscriptionId": "your-subscription-id" 
}

This output shows that:

In your subscription, “zone 1” maps to “zone 3” in the peer subscription. “Zone 2” in your subscription maps to “zone 1” in the peer subscription, and so on.

Then, We were able to force deploy the VMs in the same physical Availability Zone in the two subscriptions.