Posts Understanding Physical and Logical Azure Availability Zones
Post
Cancel

Understanding Physical and Logical Azure Availability Zones

When and How to Use Azure Resource Locks Without Causing Yourself Trouble

Azure provides high availability and resilience through its Availability Zones, which are designed to ensure fault isolation while maintaining low-latency connectivity. However, there is often confusion between physical zones and logical zones when deploying resources in Azure. In this article, we’ll clarify these concepts, explain their usage, and highlight key considerations when architecting solutions.

What Are Azure Availability Zones?

Azure Availability Zones (AZs) are physically separate data centers within an Azure region, each equipped with independent power, cooling, and networking. By deploying resources across multiple AZs, organizations can achieve higher availability and fault tolerance.

  • Each Availability Zone is an isolated data center.
  • They are interconnected with high-speed, low-latency networking.
  • Not all Azure regions support Availability Zones; they are currently available in the following regions:
AmericasEuropeMiddle EastAfricaAsia Pacific
Brazil SouthFrance CentralIsrael CentralSouth Africa NorthAustralia East
Canada CentralGermany West CentralQatar Central Central India
Central USItaly NorthUAE North China North 3
East USNorth Europe  East Asia
East US 2Norway East  Indonesia Central*
Mexico CentralPoland Central  Japan East
South Central USSpain Central  Japan West
US Gov VirginiaSweden Central  Korea Central
West US 2Switzerland North  New Zealand North
West US 3UK South  Southeast Asia
 West Europe   

Use Cases for Availability Zones

  • Mission-critical applications requiring high uptime (e.g., financial services, healthcare).
  • Multi-zone VM deployments for resilience (e.g., using Availability Zone VMs and load balancers).
  • Geo-redundant storage solutions with zone-redundant storage (ZRS).
  • Managed services with built-in zone redundancy, such as Azure Kubernetes Service (AKS) and SQL Hyperscale.

Physical vs. Logical Availability Zones

Physical Availability Zones

  • Physically separate data centers within an Azure region.
  • Fixed per region, meaning they do not change over time.
  • Microsoft assigns specific data centers to specific Availability Zones (e.g., Zone 1, Zone 2, Zone 3).

Logical Availability Zones

  • When deploying resources, users select logical zones (Zone 1, Zone 2, Zone 3).
  • Logical zones are mapped differently per subscription.
    • Example: Zone 1 for Subscription A might be mapped to a different physical data center than Zone 1 in Subscription B.
  • Azure randomizes these mappings to distribute workloads and maintain resiliency.

Microsoft does this to keep things balanced and prevent everyone from always picking the same Availability Zone. By mixing up which physical data centers match each logical zone in different subscriptions, Azure helps spread workloads more evenly. This way, no single zone gets overloaded, and everything runs more smoothly across the region.

While that works for them, it can also mean that we end up with resources in different Availability Zones.

Ensuring the Same Availability Zone Across Subscriptions

If you have a multi-subscription environment, ensuring that all resources are placed in the same physical Availability Zone can be challenging due to the randomization of logical zone mappings. There are three main strategies to address this:

Using Availability Sets with Proximity Placement Groups

If Availability Zones are not a strict requirement, Availability Sets provide high availability within a single data center by distributing VMs across fault domains and update domains.

  • Fault Domains (FDs): Separate racks to ensure hardware redundancy.
  • Update Domains (UDs): Separate groups to prevent simultaneous reboots during maintenance.

Use Availability Sets when:

  • You need redundancy but don’t require cross-zone deployments.
  • You want a predictable placement of resources in the same subscription.

Using Proximity Placement Groups (PPGs)

For workloads requiring low-latency communication, Azure offers Proximity Placement Groups (PPGs), which allow VMs to be placed as close as possible within the same physical data center.

  • How PPGs work:
    • When a Proximity Placement Group is created, all VMs within that group are deployed in the same physical location.
    • This is particularly useful for latency-sensitive applications, such as high-performance computing (HPC), databases, and SAP HANA.
  • Combining PPGs with Availability Sets
    If you want both low latency and high availability, you can use Availability Sets inside a Proximity Placement Group:
    • Ensures fault tolerance within the same physical location.
    • Balances redundancy and performance.
  • Use PPGs when:
    • You need ultra-low latency between VMs (e.g., database clusters).
    • Your workload requires strict placement control within a physical data center.

⚠️ Important: Proximity Placement Groups do not work across Availability Zones. They only apply within a single physical zone or data center.

Mapping Physical and Logical Zones

The more precise way to ensure all resources in different subscriptions land in the same physical Availability Zone is to manually determine the mapping of logical to physical zones.

Azure allows you to query the physical zone of an existing VM, and based on that information, you can construct a mapping table.

Example of Logical to Physical Zone Mapping Table:

SubscriptionLogical ZonePhysical Zone
Subscription AZone 1Physical Zone 3
Subscription AZone 2Physical Zone 1
Subscription AZone 3Physical Zone 2

Here is the PowerShell script that you can use to make a report for all of your subscriptions:

Once you determine this mapping, you can manually assign workloads to the same physical zones across all subscriptions.

💡 Key Takeaway: The logical zone numbers shown in the Azure portal do not correspond to the same physical zone across subscriptions. Mapping them allows for controlled workload placement.

How to Use Availability Zones Effectively

Deploying Virtual Machines Across Zones

1
2
3
4
New-AzVM `
  -ResourceGroupName "MyResourceGroup" `
  -Location "East US" `
  -Zone "1"

Tip: Use a Load Balancer or Application Gateway to distribute traffic across multiple zones.

High-Availability Storage Solutions

  • Zone-Redundant Storage (ZRS): Ensures data is replicated across multiple zones.
  • Geo-Zone-Redundant Storage (GZRS): Combines ZRS with geo-redundancy for further protection.

Azure Kubernetes Service (AKS) in Multiple Zones

  • AKS allows node pools to be deployed across multiple Availability Zones for fault tolerance.
  • Azure Load Balancer ensures requests are evenly distributed.

Understanding Pricing & Cost

  • Deploying across Availability Zones may increase costs due to inter-zone bandwidth charges.
  • Consider using regionally redundant services where possible to balance cost and availability.

Availability Zones in Azure provide a way to ensure high availability by distributing workloads across physically separate data centers within a region. However, the logical zone numbers you see in the Azure portal don’t always match the same physical zones across different subscriptions, so it’s important to map them manually if you need consistency. Availability Sets offer redundancy within a single data center, while Proximity Placement Groups help optimize for low-latency workloads within the same physical zone. Understanding these options allows you to design resilient architectures while keeping an eye on performance and cost. By planning your deployments carefully, you can take full advantage of Azure’s infrastructure for high availability and disaster recovery.

Thanks for reading, and keep clouding around! 🚀

Vukasin Terzic

This post is licensed under CC BY 4.0