For those that haven’t yet come across availability zones (they’re not available in all regions currently but Microsoft are slowly rolling these out) they offer the next level of protection after availability sets. Where an availability set is an anti-affinity solution – you’re instructing Azure to not put VMs in the same availability set into the same hardware etc. to protect against host reboots for updates and faults.
Using Azure Availability Zones takes the Availability set concept a step further by placing the VM into a unique physical location within the region with their own independent cooling, power and networking. In this scenario, if you create three (or more) VMs in three zones your VMs are distributed across three fault domains and three update domains. This will give an SLA of 99.99%, an industry-leading figure.
Availability Zones are, of course, a fantastic feature to the arsenal of Azure availability tools but they do have their limitations. This limitation mainly comes in the form of several key Azure services not understanding their concept.
One of the best examples I’ve seen of this is the Azure Advisor. The go-to place for many people to understand their environment will actually tell you that your VMs are not in a highly available configuration if you use Availability Zones! This is because Advisor looks to check your VMs are in an availability set and as they won’t be (VMs in different zones cannot be in an availability set, that wouldn’t make sense) Advisor gives you the warning.
I’m sure Microsoft will work through these little quirks with many of its services but for now, be prepared to defend some of your decisions in the quest to make your services as highly available as possible.
Availability Zone availability and qhat services support it can be found here – https://docs.microsoft.com/en-us/azure/availability-zones/az-overview.