Running Zone-Redundant ExpressRoute Circuits with External Storage for Azure VMware Solution

You might have landed on this blog post because of the email Microsoft recently sent to affected customers:

Figure - Email shared to affected Azure customers

What Changed in Azure

For Azure Public IP resources, Microsoft has more options how to deploy from resiliency perspective. In August 2024, Azure announced that any newly created Public IP will now be zone-redundant by default.

How It Relates to Azure VMware Solution (AVS)

Azure VMware Solution offers two models of integration with a customer’s private Azure virtual network:

Direct virtual network integration – an AVS SDDC is directly available from virtual network. Available only with the latest AVS generation SKU, AV64 Gen 2
ExpressRoute Circuit integration – required for all other SKUs. This establishes a private connection (similar to a “VPN”) between the virtual network and the AVS SDDC via internal ExpressRoute circuit. This circuit itself is provided at no additional cost (included in the AVS pricing) and is not metered.

How an ExpressRoute Circuit Is Deployed

This post won’t go into the full details of deploying an ExpressRoute (you can find that in the official documentation). Instead, let’s look at the high-level steps:

To connect an AVS SDDC to your virtual network, the first step is to prepare a virtual network and create a dedicated subnet called GatewaySubnet.
This subnet is then used by another Azure resource: Azure Virtual Network Gateway. This resource enables secure connectivity between different networks - such as other Azure virtual networks, on-premises environments, or even AWS VPC.
If you’ve worked with the Azure VPN Gateway, that’s essentially a specific type of Virtual Network Gateway.
With the Virtual Network Gateway in place, you can connect multiple networks to a single Azure virtual network.
The gateway requires an associated Azure Public IP address resource. This assignment gives the gateway an external presence, enabling connections to be established between the source network and the target Azure virtual network - it’s used for control/management plane. This Public IP is used for control/management plane, but it’s not used for traffic itself - but if that IP fails, the gateway resource can fail due to not available control/management plane.
Once the connection is established, both networks become routable with each other via theirs private IP addresses.

graph LR
  %% Styles
  classDef azure fill:#eef6ff,stroke:#4f7dbd,stroke-width:1px;
  classDef comp fill:#ffffff,stroke:#7e8aa2,stroke-width:1px;
  classDef mgmt fill:#fef9e7,stroke:#d4ac0d,stroke-width:1px,color:#000000;

  %% Azure VNet + Gateway
  subgraph AZURE_VNET["🟦 Azure Virtual Network (vNET)"]
    direction TB
    subgraph GWSUB["🧩 GatewaySubnet"]
      direction TB
      VNG["🔗 Virtual Network Gateway"]
    end
  end
  class AZURE_VNET,GWSUB azure
  class VNG comp

  %% External connections (left side)
  AVS["☁️ Azure VMware Solution (SDDC)"]
  ONPREM["🏢 On-Premises Network"]
  PIP["🌐 Public IP (control-plane)"]
  class AVS,ONPREM comp
  class PIP mgmt

  %% Data plane
  AVS --- VNG
  ONPREM --- VNG

  %% Control plane dependency
  PIP --- VNG

AVS Networking with External Storage

A typical deployment that uses external storage - such as Pure Cloud Block Store or Pure Storage Cloud Azure Native - looks like this:

graph LR
  %% Styles
  classDef azure fill:#eef6ff,stroke:#4f7dbd,stroke-width:1px;
  classDef comp fill:#ffffff,stroke:#7e8aa2,stroke-width:1px;
  classDef pure fill:#F04E23,stroke:#C43E19,stroke-width:1px,color:#ffffff;
  classDef mgmt fill:#fef9e7,stroke:#d4ac0d,stroke-width:1px,color:#000000;

  %% Azure VNet + Gateway
  subgraph AZURE_VNET["🟦 Azure Virtual Network"]
    direction TB
    PURE["🛢️ Pure Storage Cloud (external storage)"]
    subgraph GWSUB["🧩 GatewaySubnet"]
      direction TB
      VNG["🔗 Virtual Network Gateway"]
    end
  end
  class AZURE_VNET,GWSUB azure
  class VNG comp
  class PURE pure

  %% External connections (left side)
  AVS["☁️ Azure VMware Solution (SDDC)"]
  ONPREM["🏢 On-Premises Network"]
  PIP["🌐 Public IP (control-plane)"]
  class AVS,ONPREM comp
  class PIP mgmt

  %% Data plane
  AVS --- VNG
  ONPREM --- VNG
  VNG --- PURE

  %% Control plane dependency
  PIP --- VNG

Impacts on Resiliency

Now we get to the real topic. We are in the cloud environment and everything still comes back to the fundamental building blocks - availability zones (AZs).

When you deploy an AVS resource, you must choose the availability zone where the AVS SDDC will reside. AVS also supports deploying nodes across multiple zones (using the AVS Stretched Cluster feature). However, in this configuration any external storage solution is not supported.

Because of that limitation, let’s design a Zonal deployment (and repeat in another AZ to spread across AZs) and the best practice is to place your storage in the same AZ as your AVS deployment. Otherwise, you increase the risk of downtime:

If you deploy storage in a different AZ and the AVS’s zone goes down → your workloads are down.

If the storage’s zone goes down → your workloads are also down.

By keeping AVS and storage in the same AZ, you reduce the probability of a cross-AZ dependency failure. That’s why I strongly recommend explicitly specifying the AZ for all related resources and deploying them consistently in the same zone.

Networking

So far, we haven’t looked at the deployment architecture from a resiliency perspective.

Virtual network gateway (ExpressRoute)

Azure offers multiple ExpressRoute gateway SKUs - Standard, High Performance, Ultra Performance, and the AZ-enabled SKUs (ErGw1AZ / ErGw2AZ / ErGw3AZ).
The AZ SKUs are zone-redundant; they deploy gateway instances across availability zones and are designed to survive a single-AZ failure. Non-AZ SKUs are regional and don’t provide zone-level redundancy.

At Pure Storage, we recommend ErGw3AZ SKU for AVS environments that rely on external storage.
It delivers the highest capacity in the AZ family and supports ExpressRoute FastPath, which lets data bypass the gateway for lower latency and higher throughput.

The last puzzle piece: the Public IP

The Public IP attached to the ExpressRoute gateway is what is going on here.

By default, any Public IP was defaultly deployed as a multi-zonal - in all AZs. But this deployment creates distinct per-zone IP instances and the gateway binds to one of them at startup; it does not failover to the sibling IPs in other zones during an outage and might make your connection to an external storage unavailable.

To address this, Microsoft introduced the Zone-redundant Public IP type. This is a single logical IP that automatically spans all zones. With it, the ExpressRoute gateway remains reachable even if one AZ fails - fully aligning with the zone-redundant design of the AZ-enabled (such as ErGw3AZ) SKUs.

Impact to New AVS Deployments

As announced by Microsoft, Azure has changed the default behavior for new deployments.
When you deploy a new Virtual Network Gateway, the associated Public IP will now default to zone-redundant mode.

In this configuration, the Public IP is not shown as a separate resource in your subscription—it is created as a hidden, Microsoft-managed resource. This ensures resiliency by default.

No additional action is required for new AVS deployments.

Impact to Existing AVS Deployments

For existing environments, it is important to validate the resiliency of your AVS external storage setup to avoid potential outages.

Also verify, that the gateway’s Public IP is not a Basic SKU.

Inherited Basic IPs are a legacy artifact from older deployments.
The Basic SKU has been discontinued, and migration to a Standard SKU is required by the end of September 2025.

Microsoft has prepared a guide on how migrate the associated Virtual Network Gateway and its associated Public IP. More details can be found in this KB. Please be sure you make this change during a maintenance window, since it might introduce couple minutes of downtime.