ExpressRoute Plus VPN: Which Failure Domains Do You Cover?

An IPsec tunnel running over ExpressRoute private peering adds encryption to a transport that already exists. A second tunnel improves endpoint availability, and it does nothing at all for the carrier path underneath both of them. That distinction is easy to lose when the dashboards show two green tunnels and the design review asks a different question: which failures must this connection survive? Answer that first, then count tunnels, because the number of green indicators is a property of the encryption layer and the number of failure domains is a property of the whole path.

Start with failures, not with green tunnels

Write four rows before you draw anything: one VPN endpoint or peer instance failing, one local router or first-mile connection failing, the shared ExpressRoute path failing, and IPsec becoming unavailable while private peering still carries traffic. Each row names what the design must preserve, and each one is answered by a different mechanism.

Microsoft documents private-IP Site-to-Site VPN over ExpressRoute private peering, and supported coexistence with internet-based Site-to-Site connections. That coexistence is a different underlay design, and it does not appear merely because you added another private tunnel endpoint.

Failure domain 1: the VPN endpoint

Two tunnels on one gateway are usually active-active pairs terminating on the same Azure-side resource. They protect against a single tunnel or instance problem, and they do not protect against that resource being unavailable, reconfigured or out of capacity. Endpoint redundancy means a second supported endpoint, with its own path and its own configuration, plus a route that can reach it.

Check what you actually deployed rather than what the diagram says, because the portal groups these resources in ways that hide their relationship:

az network vpn-connection show -g rg-connectivity -n vpn-to-hub   --query '{conn:connectionStatus,tunnels:tunnelConnectionStatus}'
az network vnet-gateway show -g rg-connectivity -n gw-hub   --query '{sku:sku.name,activeActive:enableBgp,peers:bgpSettings.peers}'

If both tunnels point at one gateway with one public IP, you have endpoint redundancy of a specific and limited kind. That may be exactly what the requirement asks for, and it should be stated that way instead of being described as a redundant connection.

Failure domain 2: the local path and the carrier

Underneath the encryption sits a physical and commercial reality: a customer edge device, a cross-connect, a provider network and a peering location. The ExpressRoute availability guidance is explicit that end-to-end redundancy includes the customer and service-provider segments, not just the Microsoft side. Two logical paths that share a router, a power feed or a first-mile connection still share that dependency.

This is where a design usually fails an honest review. Two circuits from the same provider, terminating in the same building, on equipment from the same purchase order, are not two failure domains. They are one failure domain with two invoices.

Ask the carrier question in writing: which of these paths diverge, where, and what is the documented behaviour when the shared segment fails? A verbal assurance during a design call does not survive the outage you are designing for.

Failure domain 3: the route that survives without IPsec

Private peering and IPsec can offer competing routes to the same application prefix. If the protected route disappears, a surviving direct ExpressRoute route may still be usable, without the encryption layer the tunnel was providing. Whether that is acceptable is a policy decision, and it is the decision most often left implicit.

Encryption requirements and availability requirements can genuinely conflict here. "Any surviving route counts as success" is an availability statement that quietly answers the encryption question with "no". Write down which one wins, for which prefixes, and who approved it.

az network vnet-gateway list-advertised-routes -g rg-connectivity -n gw-hub --peer 10.0.0.1
az network vnet-gateway list-learned-routes -g rg-connectivity -n gw-hub -o table

Compare the learned routes with the prefixes you expected. A fallback that carries a small administrative workload may be perfectly adequate for that workload and nowhere near the capacity the production demand needs, so record the capacity assumption alongside the route.

Record three separate rows, not one verdict

Keep endpoint redundancy, transport redundancy and disaster recovery as separate entries in the design record, each with its own mechanism, its own verification and its own owner. When an incident review asks why the connection survived a gateway restart but not a fibre cut, three rows answer in one sentence; a single "redundant" checkbox cannot.

Then test the rows you can test cheaply. Fail one tunnel and confirm the traffic moves and re-encrypts. Withdraw one route and confirm the surviving path is the one you intended, then confirm whether it is still encrypted. Document the failures you could not simulate, because an untested row is an assumption and should be labelled as one.

The useful output is a short table plus a sentence per row. If a row has no mechanism, that is the finding, and it is much cheaper to discover in a design review than during a carrier outage that both tunnels were never going to survive.