Availability zones in Azure

Introduction: Region redundant deployment of the public cloud resources are quite popular because it builds resilience and improves availability. However, regions are quite far apart for 2ms latency perimeter. Availability zones are within the same region but distinct from one another. Each zone comprises of one or more data centers. Each region may have three availability zones. These zones maintain synchronous replication, withstand datacenter failures and ensure minimal customer impact. This article describes what it takes to get a service ready for Azure availability zones.

Description: Availability Zones (AZs) are easy to opt into and guarantee 99.99% uptime SLA. Though they sound like Availability sets, the AZs comprise of datacenters with independent power, cooling and networking and the availability sets are logical groupings of virtual machines. AZ is a combination of both a fault domain as well as an update domain, so changes do not occur at the same time. Services that support availability zones fall under two categories: zonal services – where a resource is pinned to a specific zone and a zone-redundant service for a platform that replicates automatically across zones. Business continuity is established with a combination of zones and azure region pairs.

Azure classifies services into three categories - foundational, mainstream and specialized. Service categories are assigned at general availability. They start their lifecycle as a specialized service and as demand and utilization increases, it may be promoted to mainstream or foundational. A specialized service has demand driven ability across regions. It might require customizations.  A mainstream service is one that is available in all recommended regions. A foundational service is one that is available in all regions where the region is generally available. Some examples of services that support zone-redundant services under each of the three categories can be listed as below:

Zone-resilient:

        - Foundational service: Application gateway v2, Cosmos DB, Express Route, Disk Storage, Key Vault, Load Balancer, Service Bus, Service Fabric, Virtual Network, VPN Gateway.

        - Mainstream service: Azure Cognitive Search, Active Directory services, Azure API management, Data Explorer, Firewall, Site recovery, Power BI, Virtual WAN.

        - Specialized service:  OpenShift, Bot Service, Front Door, Managed applications, Resource Graph, Azure Stack, Microsoft Graph, security center and Traffic manager

The availability zones can be queried from SDK, and they are mere numbers within a location. For example: az vm list-skus --location eastus2 --output table will list vm skus based on region and zones. The zones are identified by numbers such as 1, 2, 3 and these do not mean anything other than that the zones are distinct. The numbers don’t change for the lifetime of the zone, but they don’t have any direct correlation to physical zone representations.

There are ways in which individual zone-resilient services can allow zone-redundancy to be configured.

The clients in the sdk for these services have a builder pattern where there is an option to specify the redundancy rules as well as a supported region via the location parameter.  Resources can also be requested to be created in a zone redundant service at a specific location by mentioning a supported region where the availability zones are present. This might entail other resources to be collocated in the same region.