Azure Availability Zone Mappings for Subscriptions

Key insights

• Availability Zones: Azure regions use physically separate datacenters grouped as zones, but subscriptions see zones as logical labels (AZ1, AZ2, AZ3).
  Logical labels can map to different physical datacenters across subscriptions, so identical zone names do not guarantee physical separation.
• Availability Zone Peering: Register this feature in one subscription to query the physical zone mappings of other subscriptions from that single subscription.
  This lets you retrieve mappings for multiple subscriptions without registering the feature in each one, and Microsoft does not charge for using the feature.
• Logical vs physical mappings: Zone names are assigned when a subscription is created and cannot be changed later.
  Because mappings are immutable, you must verify physical mappings before deploying zone-redundant resources across subscriptions to avoid accidental co-location.
• REST API and script usage: Call the REST API (or use provided PowerShell helpers) to request logical-to-physical zone mappings by subscription ID and region.
  Example shown in the video: . .\Read-AzureAZs.ps1 then read-azureazs eastus, westus2 to get mappings for those regions.
• Design and resilience benefits: Knowing exact physical mappings prevents single-point failures and improves disaster recovery planning.
  Use this data to place replicas and storage (for example, zone-aware volumes or ZRS) so resources truly span distinct datacenters.
• Practical recommendations: Query mappings before major deployments and when adding subscriptions to your architecture.
  Treat mapping results as authoritative for long-term planning and combine them with zone-redundant services and failover strategies for robust multi-subscription designs.

Overview: Video Breakdown and Context

In a new YouTube presentation, John Savill's [MVP] explains how to interpret Azure availability zone mappings across subscriptions and why those mappings matter for resilient cloud design. The video opens with a concise refresher on what Availability Zones are and then moves to practical examples and a script demonstration. Consequently, viewers gain both conceptual clarity and a hands-on way to verify mappings. Overall, the presentation aims to reduce the risk of accidental co-location when deploying resources across subscriptions.

Key Concepts and Why They Matter

First, the video stresses that Azure labels such as AZ1, AZ2, and AZ3 are logical names rather than fixed physical locations. Moreover, Savill emphasizes that the physical datacenters behind those labels can differ between subscriptions, which means simply choosing distinct AZ labels may not give true physical separation. Therefore, understanding the actual physical mapping is critical when you design multi-zone redundancy or disaster recovery strategies. In short, the logical labels are convenient, but they can mask important differences that affect availability.

New Tooling: Availability Zone Peering and the Script

The central practical takeaway is the demonstration of the Availability Zone Peering capability and a small PowerShell helper script called Read-AzureAZs.ps1. Savill shows how registering the peering feature in one subscription lets you query the physical zone mapping of other subscriptions programmatically. As a result, architects can confirm whether their replicas actually sit in different physical zones before finalizing designs.

During the walkthrough, he runs the script against regions such as eastus and westus2 to illustrate how the mappings appear in real output. The video also covers REST API calls that return the mapping information for up to five subscriptions from a single registered subscription. Consequently, teams that manage multiple subscriptions gain a practical, centralized way to validate cross-subscription zone alignment without registering the feature everywhere.

Operational Tradeoffs and Challenges

While the peering feature brings visibility, it also introduces tradeoffs around administration and access control. For example, registering the feature and querying other subscriptions requires appropriate permissions and careful handling of credentials, so teams must balance convenience with strict role-based access policies. Furthermore, the feature supports mapping for a limited number of subscriptions per requester, which means very large enterprises may need to plan a strategy for broad coverage.

Another challenge is that the zone mapping is assigned when a subscription is created and cannot be changed later, so architects must query existing mappings early and document them for long-term planning. In addition, relying on programmatic mapping calls creates operational dependencies; thus, teams should include these checks in deployment pipelines to avoid surprises. Ultimately, these tradeoffs highlight the need to combine technical verification with governance and process controls.

Implications for Architecture and Resilience

With confirmed physical mappings, teams can make better decisions about where to place replicas, how to configure zone-redundant services, and how to sequence maintenance to minimize risk. For instance, storage systems that support zone awareness can be matched to physical mappings so data replicas truly occupy distinct datacenters. In turn, this improves failover behavior and reduces the chance of correlated failures across subscriptions.

Moreover, Savill points out that Azure designs inter-zone connectivity to keep latency low, which benefits cross-zone application designs. Nevertheless, architects should still weigh latency, cost, and data residency requirements when choosing zones and regions. In other words, physical separation enhances resilience but does not remove the need to balance performance, cost, and operational complexity.

Practical Steps and Recommendations

Finally, the video offers a clear set of steps for teams to adopt: register the Availability Zone Peering feature in a central subscription, run the provided script or REST calls to collect mappings, and use those results to validate multi-zone deployments. Additionally, Savill suggests integrating these checks into deployment automation so mapping verification becomes routine rather than an afterthought. Consequently, organizations reduce the risk of accidental co-location and improve their overall reliability posture.

In conclusion, the video by John Savill's [MVP] combines conceptual explanation, tooling, and a demo to make a strong case for verifying zone mappings across subscriptions. By following the procedures shown, teams can design more predictable, resilient multi-subscription architectures while managing the administrative and operational tradeoffs involved.

Keywords

Azure availability zone mapping, Azure subscription availability zones, map availability zones to subscription, Azure zone mapping guide, understanding Azure availability zones, subscription zone mapping Azure, how to map Azure availability zones, Azure regional availability mapping