Microsoft recently added support for availability zones to Azure firewall in regions that offer this higher level of SLA. In this post, I will explain how you can convert an existing Azure Firewall to availability zones.
Before We Proceed
There are two things you need to understand:
- If you have already deployed and configured Azure Firewall then there is no easy switch to turn on availability zones. What I will be showing is actually a re-creation.
- You should do a “dress rehearsal” – test this process and validate the results before you do the actual migration.
The Process
The process you will do will go as follows:
- Plan a maintenance window when the Azure Firewall (and dependent communications) will be unavailable for 1 or 2 hours. Really, this should be very quick but, as Scotty told Geordi La Forge, a good engineer overestimates the effort, leaves room for the unexpected, and hopefully looks like a hero if all goes to the unspoken plan.
- Freeze configuration changes to the Azure Firewall.
- Perform a backup of the Azure Firewall.
- Create a test environment in Azure – ideally a dedicated subscription/virtual network(s) minus the Azure Firewall (see the next step).
- Modify the JSON file to include support for availability zones.
- Restore the Azure Firewall backup as a new firewall in the test environment.
- Validate that that new firewall has availability zones and that the rules configuration matches that of the original.
- Confirm & wait for the maintenance window.
- Delete the Azure Firewall – yes, delete it.
- Restore the Azure Firewall from your modified JSON file.
- Validate the restore
- Celebrate – you have an Azure Firewall that supports multiple zones in the region.
Some of the Technical Bits
The processes of backing up and restoring the Azure Firewall are covered in my post here.
The backup is a JSON export of the original Azure Firewall, describing how to rebuild and re-configure it exactly as is – without support for availability zones. Open that JSON and make 2 changes.
The first change is to make sure that the API for deploying the Azure Firewall is up to date:
{
"apiVersion": "2019-04-01",
"type": "Microsoft.Network/azureFirewalls",
The next change is to instruct Azure which availability zones (numbered 1, 2, and 3) that you want to use for availability zones in the region:
{
"apiVersion": "2019-04-01",
"type": "Microsoft.Network/azureFirewalls",
"name": "[variables('FirewallName')]",
"location": "[variables('RegionName')]",
"zones": [
"1",
"2",
"3"
],
"properties": {
"ipConfigurations": [
{
And that’s that. When you deploy the modified JSON the new Azure Firewall will exist in all three zones.
Note that you can use this method to place an Azure Firewall into a single specific zone.
Costs Versus SLAs
A single zone Azure Firewall has a 99.95% SLA. Using 2 or 3 zones will increase the SLA to 99.99%. You might argue “what’s the point?”. I’ve witnessed a data center (actually, it was a single storage cluster) in an Azure region go down. That can have catastrophic results on a service. It’s rare but it’s bad. If you’re building a network where the Azure Firewall is the centre of secure, then it becomes mission critical and should, in my opinion, span availability zones, not for the contractual financial protections in an SLA but for protecting mission critical services. That protection comes at a cost – you’ll now incur the micro-costs of data flows between zones in a region. From what I’ve seen so far, that’s a tiny number and a company that can afford a firewall will easily absorb that extra relatively low cost.
