Search for a command to run...
I work in the Customer Architecture & Engineering team at Microsoft. We help customers around the globe build the best solutions on Azure. The content of this blog should be considered personal opinion and is not an official Microsoft publication.
No comments yet. Be the first to comment.
Using Azure Chaos Studio to put your cloud applications to the test
...by turning your metrics and telemetry into a unified score!
...and why your traditional dashboard may not be good enough
And some fun with Azure Functions and Powershell along the way
Availability Zones are a critical feature in Azure, providing high availability and resilience by physically separating resources across distinct datacenter locations within a region. Leveraging Availability Zones helps safeguard your applications and data against localized failures, supporting business continuity.
To achieve zone redundancy, it is essential that all resources in your solution are configured to be zone redundant—overlooking a single resource may result in failure when a zone becomes unavailable.
With the new az zones CLI extension, you gain the capability to easily validate zone redundancy for your Azure resources, ensuring that every resource within a given scope is set up for high availability. This extension empowers you to quickly identify gaps, verify compliance, and confidently architect resilient cloud solutions by providing comprehensive validation.
az zones is a community extension to the official Azure CLI. Before it can be used, it must be installed first. Assuming you’ve already installed the Azure CLI, use the following command to use az zones:
az extension add --name zones
After you've logged into Azure, try out the validation. Make sure you first identify which resources are part of your production deployment, and ensure you have read permission on those resources. You can select an entire subscription, one or more resource groups, or select specific resources based on a set of tags:
// Log into Azure
az login
// validate resources in a specific resource group:
az zones validate --resource-groups my-resource-group
// validate resources in the active subscription:
az account set --subscription "My Application - Production"
az zones validate
// validate resources that have all specified tags:
az zones validate --tags env=prod
az zones validate --tags env=prod,criticality=high
// Output in human readable table rather than json
az zones validate --ouput table
The results you will see will look something like this:
| Location | Name | ResourceType | ZoneRedundant |
| global | myFrontDoor | microsoft.cdn/profiles | Always |
| uksouth | myLoadtest | microsoft.loadtestservice/loadtests | Never |
| uksotuh | myVMSS | microsoft.compute/virtualmachinescalesets | Yes |
| uksouth | myAppGateway | microsoft.network/applicationgateways | No |
You'll recognize a list of your resources, which can have the following values for ZoneRedundant:
| Always | Resources of this type are always Zone Redundant |
| Never | Resources of this type cannot be Zone Redundant |
| Yes | The resource was successfully configured for Zone Redundancy |
| No | The resource was not configured for Zone Redundancy, but could be in a different configuration. You should take action on this. |
| Dependent | This resources does not have its own Zone Redundancy status, but depends on a parent or related resource. |
| NoZonesInRegion | The resource was deployed to a region that does not support Zones |
| Unknown | This resource type is currently not supported by az zones. You’ll have to validate its status manually |
Ideally, you'll want all your resources to be Yes or Always, since that means you're protected. Resources that show Never can sometimes be made ZR by deploying multiple of them to different zones. Alternatively, architect your application in a way that critical flows do not have a synchronous dependency on them.
Resources that show No are of interest, because No means that you could make them ZR if you configure them differently.
Some resources show Dependent, which means they do not have a Zone Redundancy status of their own, because it is configured on the parent or related resource. These are included to provide a complete resource list, but may not be relevant to for your query or subsequent actions. In that case, you can add the --omit-dependent flag to the command to hide them in the results.
Common scenarios for using this would be manual validations against your production environment, or automated validation during pipeline executions. For example, you could call az zones validate in a pipeline step and fail the step if any of the resources show values other than Always or Yes.
jobs:
test-infrastructure:
runs-on: ubuntu-latest
steps:
- name: Setup PowerShell Core
uses: powershell-core/setup-powershell-core@v1
- name: Validate Zone Redundancy
run: |
$(az zones validate --tags env=prod --output json) `
| ConvertFrom-Json `
| Where-Object `
{ $_.zoneRedundant -ne 'Yes' -and $_.zoneRedundant -ne 'Always'} `
| % { Write-Error "oh oh! $($_.name) not ZR!" }
The az zones extension currently supports around 35 common resource providers, with more being added in future releases.
If you need support or have questions, please raise an issue on the azure-cli-extensions Github repo.