Azure Virtual WAN vs. Hub-and-Spoke : La décision d'entreprise en 2026

Pour les architectes de réseau d'entreprise, le débat entre Azure Virtual WAN (vWAN) et une topologie hub-and-spoke autogérée n'est plus une simple question d'infrastructure gérée versus non gérée. À l'horizon 2026, la décision repose sur une compréhension nuancée des modèles de trafic, de la profondeur des fonctionnalités des appliances de sécurité requises et du coût total de possession à l'échelle. La promesse d'un contrôle quasi infini et programmable sur un fabric de transit global fait de vWAN la solution stratégique par défaut pour la plupart des grandes entreprises, déplaçant la conversation de la simple connectivité vers le réseau intelligent et basé sur des politiques.

Le Hub-and-Spoke Classique : Contrôle Maximum, Complexité Maximum

Le modèle Azure hub-and-spoke traditionnel est la traduction directe de la conception d'un data center on-premises. Un Virtual Network (VNet) hub central héberge des services partagés, dont le plus critique est une paire de Network Virtual Appliances (NVA) pour l'inspection du trafic et le contrôle du routage. Les spokes, qui hébergent les charges de travail des applications, sont connectés au hub via VNet peering. Le contrôle est explicite et granulaire, principalement via les User-Defined Routes (UDRs). Vous créez une table de routage, l'appliquez à un subnet et définissez le next hop pour des préfixes spécifiques — typiquement le load balancer interne qui protège votre paire de NVA.

Dans ce modèle, le NVA est roi. Qu'il s'agisse d'un Palo Alto Networks VM-Series exécutant PAN-OS 11.2, d'un FortiGate-VM sur FortiOS 7.6 ou d'un Cisco Catalyst 8000V, vous conservez un contrôle total sur sa configuration. Vous gérez le high availability (HA), le scaling (via VM Scale Sets) et les politiques de routage complexes directement sur l'appliance. C'est à la fois sa plus grande force et sa plus grande faiblesse. La charge opérationnelle liée à la gestion des paires HA, des tables de routage à travers des dizaines ou des centaines de spokes, et de l'infrastructure VM sous-jacente est substantielle. Un changement de politique de routage, comme l'introduction d'un nouveau service dans le hub, peut nécessiter la mise à jour des UDRs à travers chaque VNet spoke — un processus fragile et sujet aux erreurs, même avec des pratiques d'Infrastructure as Code (IaC) matures utilisant Terraform ou Bicep.

Virtual WAN : Azure en tant que Fournisseur de Transit Global

Azure Virtual WAN abstrait la plomberie réseau sous-jacente en un service géré par la plateforme. À la base, vWAN fournit une architecture de réseau de transit global qui simplifie la connectivité any-to-any entre les branches (VPN/SD-WAN), les utilisateurs distants, les data centers (ExpressRoute) et les VNets. Vous déployez un Virtual Hub dans chaque région Azure requise, et ce hub agit comme le centre de votre univers pour cette géographie. La connectivité n'est pas basée sur le peering mais sur des « connections » au hub. Le hub contient lui-même des routeurs gérés qui propagent automatiquement les routes entre toutes les entités connectées.

Le différenciateur clé est ce routage intégré. Lorsque vous connectez un VNet au hub vWAN, son espace d'adressage est appris par le routeur du hub. Lorsque vous connectez un circuit ExpressRoute, ses préfixes annoncés sont appris. Le routeur du hub annonce ensuite ces routes apprises à toutes les autres entités connectées en fonction de la politique. Cela élimine la nécessité d'une gestion manuelle des UDRs pour le routage de transit. L'ajout d'un nouveau VNet ou d'un nouveau bureau de branche ne vous oblige pas à toucher la configuration d'un spoke existant ; le routage est mis à jour dynamiquement. Il s'agit d'une solution au niveau de la plateforme au problème de scalabilité qui ronge les conceptions classiques de hub-and-spoke.

Secured Hub : Azure Firewall Premium vs. NVA Intégré

Le « Secured Virtual Hub » est l'endroit où la conversation sur la sécurité commence. Il s'agit d'un hub vWAN avec une appliance de sécurité intégrée. Vous avez deux choix principaux : Azure Firewall ou un NVA tiers du Azure Marketplace.

Azure Firewall Premium : Le Natif Capable

D'ici 2026, Azure Firewall Premium sera devenu un NGFW-as-a-Service formidable. Il fournit déjà des fonctionnalités essentielles de prévention des menaces comme l'IDPS basé sur des signatures, l'inspection TLS complète (une fonctionnalité notoirement difficile à implémenter dans le cloud), le filtrage d'URL et le filtrage par catégorie web. Pour l'inspection du trafic est-ouest entre les spokes ou l'égression nord-sud, il est souvent suffisant. Son principal avantage est d'être un véritable service de plateforme. Vous ne gérez pas les VMs sous-jacentes. Vous définissez une politique, l'associez au hub, et Azure gère le scaling et la résilience. Le throughput est défini par des déploiements basés sur des SKU, à partir de 20 Gbps et évoluant à la hausse.

Cependant, ce n'est pas un remplacement direct pour un NVA dédié de premier rang. Une équipe de sécurité habituée aux politiques granulaires App-ID d'un PA-5440 ou aux flux de menaces avancés sur un FortiGate 1800F trouvera les capacités d'Azure Firewall larges mais pas aussi profondes. Les ensembles de signatures, bien que robustes, peuvent ne pas être aussi spécialisés, et la personnalisation des profils de prévention des menaces est moins granulaire que ce qui est disponible sur un OS NVA dédié comme PAN-OS ou FortiOS.

NVA dans vWAN : Le Meilleur des Deux Mondes ?

Pour les organisations nécessitant leur marque spécifique de NGFW, vWAN permet le déploiement de NVAs directement dans le hub. Ce n'est pas la même chose que de déployer un NVA dans un VNet hub classique. Lorsque vous déployez un FortiGate ou un Palo Alto Networks NVA dans un hub vWAN, il fonctionne comme une application gérée. Azure gère le lifecycle, le scale-out et le high availability du VMSS sous-jacent. Surtout, le routage est géré via BGP peering entre le NVA et le routeur du hub vWAN. Vous n'appliquez plus d'UDRs pour forcer le trafic vers le NVA ; vous utilisez vWAN Routing Intent et Policies pour déclarer quels flux de trafic (Private, Internet) doivent être envoyés au NVA pour inspection en premier. Le NVA inspecte ensuite le trafic et, si permis, le route vers le routeur du hub pour une livraison ultérieure. Cela maintient le routage centralisé et dynamique de vWAN tout en permettant une inspection de sécurité best-in-class.

Analyse de Dimensionnement et de Coût : Deux Topologies, Deux Histoires

Modélisons un scénario réel pour comparer les coûts. Considérez une entreprise présente en East US 2 et en West Europe. Chaque région dispose d'un hub, de 50 VNets spokes, d'un circuit ExpressRoute de 10 Gbps et de 2 000 branches SD-WAN se connectant via VPN. Supposons 50 To de trafic inter-spoke (VNet-to-VNet) par mois au sein de chaque région.

Modèle de Coût Hub-Spoke Classique (par région)

• Cluster NVA : Deux instances FortiGate-VM08 (pour un throughput de protection contre les menaces d'environ 10 Gbps) avec une licence BYOL. Le coût de la VM seule est d'environ 1,50 $/heure * 2 * 730 heures/mois = ~2 190 $/mois. Ajoutez le coût de la licence logicielle à cela.
• Azure Standard Load Balancer (Internal/External) : ~50 $/mois.
• Public IPs : ~20 $/mois.
• VNet Peering (Le Tueur) : C'est le coût critique. Le trafic circulant de Spoke A -> Hub -> Spoke B est facturé pour l'ingress et l'egress sur le lien de peering. Pour 50 To de trafic : 50 * 1024 Go = 51 200 Go. Le coût est de 0,01 $ par Go. Donc, 51 200 Go * 0,01 $/Go * 2 (ingress/egress) = 1 024 $/mois. Ce coût augmente linéairement avec le volume de trafic.
• Frais de gestion : Ce coût caché est significatif. Les heures d'ingénierie nécessaires pour gérer les UDRs, les patchs/mises à niveau NVA et le basculement HA sont substantielles.

Modèle de Coût Azure Virtual WAN (par région)

• Hub vWAN Standard : ~1,25 $/heure * 730 heures = ~912,50 $/mois.
• VNet Connections : 50 connexions * 0,05 $/heure * 730 heures = 1 825 $/mois.
• Scale Units : Pour gérer environ 10 Gbps de trafic VNet, vous auriez besoin de 5 unités de mise à l'échelle (2 Gbps par unité). Celles-ci coûtent 0,25 $/heure chacune. 5 * 0,25 $/heure * 730 heures = 912,50 $/mois.
• Data Processing (VNet-to-VNet) : vWAN facture le trafic traité via le hub. Pour nos 50 To : 51 200 Go * 0,02 $/Go = 1 024 $/mois. C'est comparable au coût de peering mais plus prévisible et inclut l'infrastructure de routage.
• Azure Firewall Premium : Un déploiement avec une capacité de traitement de 10 Gbps et des fonctionnalités premium coûte environ 2 500 $/mois.

À première vue, les coûts des composants vWAN semblent plus élevés. Cependant, le modèle vWAN élimine entièrement les frais de VNet peering pour le trafic de transit. Plus important encore, il réduit considérablement les coûts opérationnels de la gestion du réseau complexe d'UDRs et de NVAs autogérés. Le Total Cost of Ownership (TCO) à grande échelle, en particulier dans les scénarios multirégionaux, favorise souvent vWAN.

Routage Multirégional : L'Avantage Inéquitable de vWAN

C'est ici que vWAN éclipse réellement le modèle classique. Dans une configuration traditionnelle, la connexion de deux hubs régionaux nécessite soit un autre ensemble de NVAs pour le VPN hub-to-hub, soit l'utilisation du Global VNet Peering. Le peering global est coûteux (environ 0,035 $ - 0,12 $/Go selon la région) et crée un maillage point-à-point qui ne scale pas. Avec vWAN, les hubs sont connectés via le Microsoft global backbone par défaut. Les routeurs des hubs régionaux échangent des routes, offrant une connectivité inter-hub transparente. Vous obtenez un réseau global entièrement routé géré par la plateforme. Étendre votre réseau à une nouvelle région est aussi simple que de déployer un nouveau hub vWAN et de le connecter ; le routage global se met à jour automatiquement.

Piège Courant : L'État d'Esprit NVA « Lift and Shift » dans vWAN

Une erreur fréquente consiste à tenter de gérer un NVA au sein d'un hub vWAN comme s'il se trouvait dans un VNet standard. Vous ne pouvez pas, par exemple, attribuer plusieurs interfaces réseau au NVA ou configurer manuellement le HA. La plateforme gère cela. Votre interaction ne se fait pas avec la VM, mais avec la session BGP peering qu'elle établit avec le routeur du hub et les politiques de Routing Intent. Votre objectif est d'influencer les décisions de routage du hub vWAN en annonçant des routes spécifiques depuis le NVA, et non de câbler manuellement le réseau avec des UDRs. Traiter le NVA comme un moteur de politiques qui reçoit le trafic via une politique déclarative est le bon modèle mental.

Quand NE PAS Utiliser Virtual WAN (Édition 2026)

Malgré ses avantages, vWAN n'est pas une solution universelle. Il existe des scénarios spécifiques où un hub-spoke classique ou même une topologie plus simple reste supérieure.

• Déploiements Petits et Monorégionaux : Si l'ensemble de votre empreinte cloud se compose de moins de 10 à 15 VNets dans une seule région avec un trafic modeste, vWAN est excessif. Le coût et la complexité d'un simple VNet hub avec Azure Firewall Basic/Standard ou une petite paire de NVA FortiGate/Palo Alto seront nettement inférieurs.
• Routage Hyper-Personnalisé : Le moteur de routage vWAN est puissant mais opinionné. Si votre architecture repose sur des comportements de routage complexes et non standard comme le Policy-Based Routing (PBR) basé sur l'adresse IP source ou les métriques de couche application qui ne peuvent pas être exprimés via BGP ou vWAN Routing Intent, vous aurez besoin du contrôle total d'un NVA dans un VNet hub classique (potentiellement avec Azure Route Server pour faciliter la propagation BGP).
• Topologies NVA Non Supportées : Si votre architecture de sécurité exige une fonctionnalité NVA très spécifique et non prise en charge — par exemple, un protocole de clustering propriétaire d'un fournisseur qui nécessite une adjacency de couche 2 ou une virtualisation multi-contextes qui ne correspond pas au modèle « NVA-as-an-appliance » dans vWAN — vous serez contraint à une architecture de hub DIY.

Conclusion : Le Choix Stratégique pour l'Échelle d'Entreprise

D'ici 2026, pour toute organisation opérant à une échelle significative dans plusieurs régions Azure, le choix est clair. L'agilité opérationnelle, le routage global automatisé et la scalabilité prévisible d'Azure Virtual WAN en font la fondation supérieure. Bien que le modèle hub-and-spoke classique offre un contrôle ultime, ce contrôle a le coût élevé de la complexité et de la fragilité opérationnelle. La capacité d'insérer des NGFW NVAs best-in-class dans le hub vWAN atténue le principal inconvénient historique, combinant l'échelle native de la plateforme avec une sécurité spécialisée. Le débat ne porte plus sur lequel offre le plus de fonctionnalités, mais sur lequel fournit la plateforme la plus intelligente et scalable pour un réseau d'entreprise mondial.

Pour concevoir votre réseau Azure de nouvelle génération et évaluer le TCO précis pour votre environnement, explorez nos services de conseil d'experts sur techleague.io. Vous pourriez également être intéressé par nos analyses approfondies sur Azure Route Server pour l'intégration avancée de NVA ou sur Sécurisation du peering privé ExpressRoute de bout en bout.