Azure Virtual Network Routing Appliance : arrêter de demander à son firewall de jouer au routeur

Dans un hub-and-spoke Azure, le firewall du hub fait presque toujours deux métiers : inspecter le trafic, et router le trafic entre spokes faute de mieux. Depuis le 4 août 2026, Azure Virtual Network Routing Appliance (VNRA) est en disponibilité générale.

Dans les landing zones que je conçois ou que j'audite, le constat est presque toujours le même. C'est un Azure Firewall dimensionné pour absorber le pic du trafic est-ouest, des réplications de bases et des sauvegardes inspectées sans raison, ou une paire de NVA sur VM qui atteint sa limite de connexions le jour d'une migration.

D'où la question qui structure cet article : pour chaque flux, faut-il le router ou l'inspecter ? VNRA traite le premier cas, le firewall le second. Ce qu'il faut retenir :

1. Ce que c'est : un routeur managé, sur le matériel réseau dédié d'Azure, jusqu'à 200 Gbps par instance.
2. Ce que ça résout : le transit est-ouest entre spokes, sans détourner un firewall ou une NVA de son rôle.
3. Ce que ça ne fait pas : ni inspection L7, ni NAT. Il soulage le firewall, il ne le remplace pas.
4. Ce que ça demande : un subnet dédié, une ressource, des UDR.

Le service : un routeur managé, pas une NVA de plus

Ce que c'est. VNRA est un périphérique de routage managé par Azure, déployé dans un VNet. Il sert de couche de transfert haut débit pour le trafic routé, sans VM de routage à gérer.

Ce qui le distingue. Il ne tourne pas sur des VM mais sur le matériel réseau spécialisé d'Azure, les « SDN appliances ». Latence basse, débit élevé, aucun OS à maintenir.

Ses caractéristiques :

• Subnet dédié nommé obligatoirement VirtualNetworkApplianceSubnet.
• Haute disponibilité intégrée et résilience aux zones de disponibilité par défaut.
• IPv4, IPv6 et dual-stack
• Intégration native avec les NSG, les admin rules d'Azure Virtual Network Manager, les UDR et NAT Gateway.
• Métriques Azure Monitor.

À noter. La facturation est horaire et dépend du palier (tarifs Virtual Network). Le palier ne se modifie pas après coup : dimensionnez-le avec la croissance en tête, et chiffrez-le dans le calculateur Azure pour votre région.

Le problème : un firewall qui joue au routeur

Le cas d'usage est classique : une landing zone hub-and-spoke dans une région, un hub de connectivité et une quarantaine de spokes applicatifs (métier, data, AKS, plateforme IA), chacun peeré au hub.

Pourquoi il faut un équipement dans le hub. Le peering VNet est non transitif par conception. Le spoke A voit le hub, le spoke B voit le hub, mais A ne voit pas B. Pour que A parle à B, il faut un équipement dans le hub qui reçoit le paquet et le renvoie vers l'autre spoke.

Avec ça on ne tient pas à l'échelle : avec 40 spokes, c'est 780 peerings à maintenir, et le contrôle central disparaît.

Comment on fait aujourd'hui. Dans la grande majorité des designs, cet équipement est le firewall du hub : Azure Firewall ou une NVA tierce (Palo Alto, Fortinet, Check Point). Des UDR sur chaque spoke envoient 0.0.0.0/0 ou les plages RFC1918 vers son IP privée, et le transit fonctionne.

Ce que ça coûte.

• Un goulot d'étranglement. Tout le trafic est-ouest passe par le firewall, y compris des flux qui n'ont pas besoin d'inspection : réplication de bases, sauvegardes, transferts de datasets vers un spoke IA.
• De l'inspection payée pour du routage. Azure Firewall facture le volume traité ; une NVA tierce coûte des licences et des VM dimensionnées pour le pic.
• Les plafonds des VM. Débit par instance, limites de connexions actives, haute disponibilité à construire soi-même derrière un load balancer interne.
• Une exploitation lourde. Patchs, symétrie du routage, sessions perdues lors d'un basculement.

On finit par dimensionner le firewall pour le volume du trafic interne, pas pour le besoin d'inspection. On demande à un équipement de sécurité de faire le travail d'un routeur, simplement parce qu'Azure n'avait pas de routeur natif à proposer dans un VNet. C'est exactement ce trou que VNRA comble.

L'architecture cible : un routeur pour router, un firewall pour filtrer

Avec VNRA, le hub retrouve une séparation saine des rôles : VNRA route le trafic privé à haut débit, le firewall inspecte et sort vers Internet. Chaque équipement a une raison d'exister.

Microsoft documente trois patterns de routage.

Les autres usages

Le transit spoke-to-spoke est le cas d'école, mais VNRA a d'autres cartes en main.

• Transit privé vers l'on-premises. VNRA peut porter tout le routage privé, spokes et on-prem, pendant que la sortie Internet va directement au firewall sans passer par lui.
• Remplacer une NVA « routeur pur ». Beaucoup de hubs hébergent une paire de VM Linux ou de routeurs virtuels qui ne font que du forwarding. VNRA les remplace sans OS à patcher ni HA à construire.
• Private Endpoints à grande échelle. VNRA supporte les private endpoints globaux et inter-régions. Microsoft le positionne aussi pour dépasser la limite des 20 000 private endpoints de l'HSPE (High Scale Private Endpoints).
• Architectures multi-régions. Un VNRA dans le hub de chaque région fournit une couche de routage centralisée et homogène entre régions.
• IPv6 et dual-stack. Une option native pour router de l'IPv6 dans le hub, là où beaucoup de designs bloquaient faute de solution managée.
• Plateformes IA et data. Les flux massifs (datasets vers un cluster GPU, synchronisation entre stockage et inférence) n'ont pas toujours besoin d'inspection L7. Microsoft met d'ailleurs explicitement en avant la montée en charge réseau qui accompagne les investissements IA.

Déployer VNRA : quatre étapes

Le déploiement tient en quatre étapes : un subnet, la ressource, le routage, la vérification.

Étape 1 — Créer le subnet dédié

Dans le VNet hub, créez un subnet nommé exactement VirtualNetworkApplianceSubnet. Si vous déployez plusieurs instances, elles partagent ce même subnet.

az network vnet subnet create \
  --resource-group rg-connectivity-hub \
  --vnet-name vnet-hub-weu \
  --name VirtualNetworkApplianceSubnet \
  --address-prefixes <prefixe-du-subnet>

Étape 2 — Créer l'appliance

Dans le portail, cherchez routing appliance, puis ouvrez Azure Virtual Network routing appliances et cliquez sur + Créer. Renseignez :

Paramètre	Valeur
Souscription, groupe de ressources	Ceux de votre hub de connectivité
Nom	Par exemple vnra-hub-weu-01
Région	La région du hub
Capacité	10, 50, 100 ou 200 Gbps
Réseau virtuel	Le VNet hub qui contient le subnet dédié

En option, vous pouvez associer dès la création un NSG et une table de routage au subnet de l'appliance. Une fois la ressource créée, relevez son adresse IP privée : c'est elle que vos UDR vont cibler.

Étape 3 — Orienter le trafic avec des UDR

VNRA ne fait rien tant que le routage ne lui envoie pas de trafic. Sur les subnets des spokes, ajoutez une route avec le next hop Virtual appliance vers l'IP de VNRA. Exemple avec le pattern 3 :

# Plages privées vers VNRA
az network route-table route create \
  --resource-group rg-spoke-app1 \
  --route-table-name rt-spoke-app1 \
  --name to-azure-private \
  --address-prefix 10.0.0.0/8 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address <ip-privee-vnra>

# Route par défaut vers le firewall
az network route-table route create \
  --resource-group rg-spoke-app1 \
  --route-table-name rt-spoke-app1 \
  --name default-to-firewall \
  --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address <ip-privee-firewall>

Vérifiez aussi que le trafic transféré est autorisé sur les peerings hub-spokes :

az network vnet peering update \
  --resource-group rg-spoke-app1 \
  --vnet-name vnet-spoke-app1 \
  --name peer-to-hub \
  --set allowForwardedTraffic=true

En production, poussez ces routes par Azure Virtual Network Manager ou par Azure Policy plutôt qu'à la main sur chaque spoke.

Étape 4 — Vérifier et surveiller

Les métriques remontent dans Azure Monitor sans configuration : octets et paquets envoyés ou reçus, flux entrants et sortants actifs, taux de création de flux.

Limitations : ce qu'il faut savoir avant de l'intégrer

VNRA est en GA. Voici ce qu'il faut avoir en tête avant de l'intégrer à un design de référence.

Ce que VNRA ne fait pas

• Pas d'inspection, pas de filtrage L7, pas d'IDPS. C'est un routeur, pas un firewall. Le filtrage passe par les NSG et les admin rules (L3/L4).
• Pas de NAT. VNRA ne peut pas être votre sortie Internet à lui seul. Il peut en revanche transmettre une route par défaut vers un équipement qui fait le NAT.

Conclusion

VNRA comble un manque ancien d'Azure : un routeur natif, managé et performant pour le hub. Il ne remplace pas le firewall, il lui rend son vrai métier. Avant de basculer un flux, gardez en tête que le sortir du firewall est aussi une décision de sécurité. Un routeur pour router, un firewall pour filtrer : chaque équipement a enfin une seule raison d'exister.

Sources

• VNRA : vue d'ensemble, patterns et limitations
• VNRA : créer une appliance
• VNRA : annonce de la disponibilité générale
• Virtual Network : tarifs
• Virtual Network : peering
• Azure Virtual Network Manager : security admin rules