Finding Availability Zone Mapping Across Azure Subscription

Azure, like most other cloud providers, employs the concept of both physical and logical availability zones (AZ) to enhance service availability. These zones are essentially distinct data centers with their own power, cooling, and networking infrastructure. In your Azure subscription, physical zones are mapped to logical zones, although this mapping can vary across different subscriptions. This mapping process is automatically carried out when your Azure subscription is created.

It’s worth noting that the idea of logical zones isn’t unique to Azure; it’s a practice adopted by many public cloud providers. Why do they do this? Well, primarily to prevent all users from flocking to a single availability zone (typically AZ-1), which could lead to overloading. Consequently, cloud providers shuffle the assignments of logical to physical zones on a per-subscription basis. This means that when you select AZ-1 in your subscription, it could correspond to physical zone 1, 2, or 3.

Why would this matter for you cloud deployment? Well, it depends on the deployment scenario, and since I stumbled upon one, which led me to write this article.

Azure VMware Solution Use Case

Consider the scenario of deploying Azure VMware Solution (AVS). In this case, you can select the region, and the AVS resource provider will deploy the AVS private cloud in an AZ randomly. Now, if you need to connect this private cloud to a Virtual Network (VNet) within your region in the same subscription, such as connecting Pure Cloud Block Store (CBS) to AVS for datastore storage provisioning, it’s essential to align the deployment of Pure CBS in the same physical AZ. This alignment ensures the best performance of the AVS and CBS integration. In the context of a single subscription, it’s as straightforward as selecting the same AZ number - a simple choice for an optimal setup!

Now let us consider another common scenario, which is more common than one might think, involves having multiple subscriptions with hub and spoke topology. You might have AVS deployed in one subscription and need to connect zonal resources in other subscription like Azure Virtual Network Gateway, Pure CBS, or other Azure native resources from within VNet to AVS. In this case, mapping AVS AZ to other Azure resource AZ can be tricky and is not obvious. You might only discover the issue when you encounter high latency, assuming that your AVS AZ 1 in Sub 1 corresponds to AZ 1 in Sub 2. This is where understanding the zone mapping and identifying peers becomes crucial for achieving your workload performance and business objectives.

How do you Find the Zone Mapping Peers?

Currently, Microsoft only provides REST API endpoint to retrieve this peer information. I’ve utilized these APIs in combination with the Azure tools described below:

Azure CLI

Once you login to azure via your local machine or opening Azure CloudShell, copy the below and make sure to define the region you want to check and peer subscription ID.

# Define the variables for the payload data
location="eastus"
PeerSubscriptionId="/subscription/xxxxxx-xxxxx-xxxx-xxxx-xxxxx"

# Define the payload JSON
payload=$(cat <<EOF
{
    "location": "$location",
    "subscriptionIds": ["$PeerSubscriptionId"]
}
EOF
)

# Use az rest to send a POST request and get the zone peers
az rest --method post \
--uri 'https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Resources/checkZonePeers/?api-version=2022-12-01' \
--body "$payload" 

Azure PowerShell

Once you login to azure via your local machine or opening Azure CloudShell. Switch to PowerShell console, then define the region you want to check and peer subscription ID.

$subscriptionId = (Get-AzContext).Subscription.ID
$PeerSubscriptionId = "xxxxxx-xxxxx-xxxx-xxxx-xxxxx"


# Define the variables for the payload data
$location = "eastus"
$subscriptionIds = @("/subscription/$PeerSubscriptionId")

# Create a PowerShell hashtable to represent the payload
$payload = @{
    "location" = $location
    "subscriptionIds" = $subscriptionIds
}

# Convert the payload hashtable to JSON format
$payloadJson = $payload | ConvertTo-Json

# Use Invoke-AzRestMethod with the POST method and pass the payload variables
$response = Invoke-AzRestMethod -Method POST `
-Path "/subscriptions/$subscriptionId/providers/Microsoft.Resources/checkZonePeers/?api-version=2022-12-01" `
-Payload $payloadJson
$response.Content | ConvertFrom-Json | ConvertTo-Json -Depth 100 

Here is an output of the powershell example above.

To conclude

Understanding Azure’s availability zones, their logical-to-physical mappings, and their implications for your specific deployment scenarios is essential for optimizing performance and ensuring high availability and redundancy for your cloud-based application across different zones in different subscriptions.

• ← Previous Post
• Next Post →