High Availability in Azure: Availability Zones

Azure Availability Zones

In the opening post of this blog series we talked about availability zones and how resources can be classified as zone-redundant, zonal (zone-specific) or non-zonal (regional). If you haven't seen that post, please take a minute to do so.

Availability zones exist to shield your resources against a datacenter-level disaster.

As of the time of writing this blog post, only a few Azure regions support availability zones.

Availability zones are free (you're only charged for the VMs and resources placed in the availability zones).

Supported Azure Resources

Only a few Azure resource types support availability zones (we're highlighting a couple of important ones below. The complete list is available here).

• Virtual Machines: During creation, a VM can be configured as zonal. Its managed disk and public IP address (standard sku only) are then automatically placed in that same zone.

• Managed Disks: During creation, a managed disk can be configured as zonal or non-zonal. Snapshots of any managed disks (zonal or otherwise) can be be persisted to zone-redundant storage.

• Public IPs: During creation, a Public IP address (standard sku only) can be configured as zone-redundant (default) or zonal. Public IPs with basic sku are non-zonal.

• Storage Accounts: With zone-redundant storage, your data is replicated across three availability zones within the same region. We already covered ZRS storage in part 5 of this blog series.

• Load Balancers (standard sku only): During creation, load balancers (standard sku only) can be configured as zone-redundant or zonal. Load balancers with basic sku are non-zonal.

Availability Sets vs Availability Zones

• Availability sets provide redundancies within a datacenter, while availability zones provide redundancies within a region. The former shields you against hardware failures in a physical rack, while the latter shields you against a datacenter-level disaster.

• SLA for VMs in availability zones is predictably higher (99.99% uptime guarantee) than that of VMs in availability sets (99.95% uptime guarantee). Full SLA details here.

• With an availability set, all VMs in it must belong to the same VNET and same resource group. However an availability zone imposes no such restrictions (zonal VMs can belong to any VNET and any resource group within the region).

• When placing a VM in an availability set, you cannot specify its placement (fault domain, update domain etc). However when placing a VM in an availability zone, you have to specify its zone.

Caveats, restrictions, gotchas & tidbits

• Zonal resources, once created, cannot be moved to other availability zones within the region. It is however possible to use Azure Site Recovery to move non-zonal VMs to availability zones in another region.

• All VMs in an availability zone need not be identical

• To ensure redundancies in all tiers of your n-tier application, each tier should ideally be placed in a separate availability zone.

• Some additional caveats with zonal VMs:

  • A zonal VM can only attach to a public IP address that is zone-redundant or zonal (i.e. standard sku only. Basic skus don't have zonal support).
  • A zonal VM can only attach a managed disk from the same availability zone. A non-zonal VM can however attach any managed disk from the same region, irrespective of whether it's zonal or not.
  • It's not possible for a zonal VM to use unmanaged disks.

• Pro tip: Pair zonal VMs with a zone-redundant load balancer (standard sku) for traffic equi-distribution amongst the VMs in that availability zone. All the zonal VMs must be connected to the same VNET.