Cloud Levels

// Exploring all things IT one level at a time…

Tag: AZs

  • Azure Availability Zones

    Azure Availability Zones

    What is an Azure Availability Zone?

    Azure Availability Zones are a great way of providing redundancy to your Azure resources.

    Each Availability Zone (AZ) essentially contains multiple physically separate Azure datacentres. Every Availability Zone has independent network infrastructure, power and cooling.

    The majority of Azure regions provide and support Availability Zones (AZs). Generally speaking, every Azure region will have a minimum of two Availability Zones, and each Availability Zone has a minimum of one datacentre.

    Although, generally most regions have at least three Availability Zones and each AZ has multiple datacentres (DCs), it is always recommended to check what is available in your chosen region before the solution is designed. For example, correct at the time of writing, Availability Zones are available in the UK South region but not the UK West region.

    Every region’s zones are generally labelled Zone 1, Zone 2 and Zone 3.

    The above graphic helps to visualise the physical architecture of regions, Availability Zones and Data Centres.

    Which Availability Zone and how many you actually choose to utilise will depend on the redundancy requirements at the time of design.

    To be able to provide some examples lets assume we have an Azure Virtual Machine (VM) located in the UK South region called VM1.

    First example, the business requirement is to ensure VM1 is protected against a zone failure within the UK South region. To ensure this requirement is achieved, the VM would need to be deployed to at least two Availability Zones, this is also known as a zone-redundant resource (a resource available within Availability Zones).

    Lets say VM1 was deployed across two zones, Zone 1 and Zone 2, this means the resource is protected from a complete zone failure. E.g. all datacentres fail within Zone 1 the resource will still be available via Zone 2.

    Second example, the businesses requirement is to ensure VM1 is protected against a single data centre failure within the UK South region. To ensure this requirement is achieved, the VM would need to be deployed to one Availability Zone of choice, this is also known as a zonal resource (a resource available from only one Availability Zone).

    Lets say VM1 was deployed to Zone 1 only, if one of the datacentres failed within Zone 1, the resource would still be available via the other datacentres in Zone 1. If the entire Zone 1 failed then the resource would not be available as it is only located in one Availability Zone.

    Example of an Azure VM being configured in only one Availability Zone.

    Please note, resources located in an Availability Zones still benefit from protections against smaller localised issues, i.e. each individual resource located in a specific data centre is still protected against rack failure.

    The Availability Zone service itself is free of charge to utilise which includes bandwidth costs within the same Availability Zone. Please note, if you deploy an Azure VM to multiple Availability Zones, multiple VMs will be created and you will be charged for each VM individually. For example, if you create 1 x standard D4s v3 VM and deploy it to three Availability Zones, three VMs will be created and billed to the subscription.

    Network bandwidth between different Availability Zones is also chargeable. Correct at the time of writing, network traffic flowing between different availability zones (egress and ingress), is charged at £0.008 per GB. This applies to traffic between any VMs, for example, if you had two VMs in the UK South region but one was in Zone 1 and the other in Zone 3, if these VMs were to communicate with each other the above charges would apply.

    There are a number of other points that you need to be aware of when it comes to Availability Zones:

    • Trusted launch VMs are not supported within Availability Zones.
    • Availability Zones are a method to provide an Azure resource with better redundancy and resiliency within the same region.
      • If a VM is deployed to an Availability Zone it will become what is known as a Zonal VM, which means the VM will be available across multiple datacentres within the single zone, all within the same region.
      • If a VM is deployed to multiple Availability Zones it will become what is known as a Zone redundant VM, which means the VM will be available across multiple datacentres and across multiple zones, all within the same region.
    • It is possible to move a pre-existing VM to an Availability Zone instead of creating a new VM from scratch. However, please note the following:
      • This process will copy and transfer the VM over to the selected zone. This requires the VM to be offline causing a small window of downtime.
      • The VM will keep the same VM name.
      • The process will mean the new zonal/zone-redundant VM will have a new virtual NIC created. The vNIC will be created with the same network settings as the old vNIC and will be connected to the source VNET and Network Security Group (NSG).
      • Depending on the sources public IP address SKU, if the source was a regional public IP address, this IP address will not be compatible with an Availbility Zone VM.
      • As of 2024, Azure standard SKU public IP addresses are zonal by default, meaning they can be used across availability zones. So depending on the public IP address in use at the time (assuming the source VM has one), your Azure public IP address should be compatible with the new VM type. If not the process will create a new public IP address object for the new VM.
      • You will need to re-configure the new zonal/zone-redundant VM within any applicable Azure Backup, disaster recovery (DR), role based access control (RBAC) and extensions and policies (if required) as it will be seen as a new VM.
      • Once the process is fully complete and you have tested to ensure everything is up and running on the new VM, the source VM and move collection (which is created as part of the move process), can be deleted from Azure as they are no longer required.

    Hope this helps and thanks for reading!