topologie de réseau Azure Virtual WAN

Cet article explique comment concevoir un réseau avec Azure Virtual WAN. Virtual WAN fournit une infrastructure hub gérée par Microsoft avec le routage automatique, l’intégration de SD-WAN native et le transit global intégré entre les hubs.

Présentation de cet article

Cet article couvre Virtual WAN architecture hub, le routage automatique et la propagation des itinéraires, la comparaison des niveaux entre Basic et Standard, l’intention de routage pour l’inspection du trafic, les modèles d’intégration SD-WAN et le modèle de coût Virtual WAN.

Qui a besoin de cet article

Lisez cet article si une ou plusieurs de ces conditions s’appliquent :

  • Vous avez besoin d’un transit géré entre de nombreuses branches, sites, utilisateurs distants ou réseaux virtuels connectés.
  • Vous souhaitez une connectivité des succursales et un routage gérés par Microsoft, plutôt que de créer et d’exploiter vous-même un hub de transit personnalisé.
  • Vous devez comparer Azure Virtual WAN avec hub-and-spoke avant de vous engager dans une topologie.
  • Vous vous attendez à ce que votre réseau augmente au-delà d’un petit nombre de périphéries de connectivité managées manuellement.

Tip

Suivre le parcours du scénario ? Sélectionnez votre scénario en haut de la page pour obtenir des conseils personnalisés. Les conseils fondamentaux qui suivent s’appliquent à tous les lecteurs.

Priorité au lift-and-shift : ignorez cet article dans le cadre d'une migration lift-and-shift standard. La plupart des environnements lift-and-shift comptent moins de 30 connexions de succursales et fonctionnent dans une ou deux régions. Une topologie hub-and-spoke traditionnelle avec passerelle VPN fournit une connectivité suffisante. N’envisagez Virtual WAN que si vous avez de nombreux sites de succursale ou planifiez une expansion rapide.

Focus de modernisation : Cet article devient pertinent lorsque votre programme de modernisation comprend des exigences en matière de transport en commun à l’échelle de la branche ou à plusieurs régions. Une architecture hub-and-spoke double, dotée de passerelles VPN dans chaque région, prend en charge la plupart des scénarios de modernisation. Virtual WAN devient pertinent lorsque vous dépassez la complexité du routage que la gestion manuelle des UDR peut maintenir.

Priorité aux environnements intercloud : Virtual WAN est le modèle de transit recommandé lorsque vous disposez de plusieurs clouds privés virtuels (VPC), succursales, régions ou périphéries cloud. Virtual WAN sert d'équivalent Azure à AWS Transit Gateway, fournissant une gestion centralisée du routage et de la connectivité à grande échelle. Si vous migrez à partir d'un environnement AWS qui utilise Transit Gateway, Virtual WAN mappe directement à ce modèle.

Azure services et fonctionnalités

Le tableau suivant répertorie les services et fonctionnalités Azure qui prennent en charge une topologie Virtual WAN :

Service ou fonctionnalité Rôle dans Virtual WAN Learn more
Azure Virtual WAN Fournit le réseau de transit global géré et l’infrastructure hub Vue d’ensemble de Virtual WAN
Hub virtuel réseau virtuel géré par Microsoft qui héberge le routage et les services de passerelle Routage de hub virtuel
passerelle VPN (dans le hub) Connectivité VPN de site à site et de point à site pour les filiales Virtual WAN passerelle VPN
Passerelle ExpressRoute (dans le hub) Connectivité privée à partir de centres de données locaux via des circuits ExpressRoute Virtual WAN ExpressRoute
Gestionnaire de Pare-feu Azure Gestion centralisée des stratégies de sécurité pour les hubs virtuels sécurisés Vue d’ensemble du Gestionnaire de pare-feu
Intention de routage Diriger automatiquement le trafic via une solution de sécurité sans tables de routage personnalisées Intention de routage

Fonctionnement

Diagramme montrant une topologie Virtual WAN avec deux hubs régionaux, réseaux virtuels spoke, sites de branche connectés via VPN et circuits ExpressRoute. Le routage inter-hub transite par le Microsoft principal.

Dans une topologie Virtual WAN :

  1. Une ressource Virtual WAN agit comme conteneur de niveau supérieur qui regroupe un ou plusieurs hubs virtuels entre les régions.
  2. Chaque hub virtuel est un réseau virtuel géré par Microsoft. Le hub contient des points de terminaison de service pour les services VPN, ExpressRoute et pare-feu. Vous ne déployez pas ou ne gérez pas directement le réseau virtuel hub.
  3. Les réseaux virtuels spoke se connectent à un hub virtuel via des connexions de réseaux virtuels (similaires au peering dans une architecture hub-and-spoke traditionnelle). Le routeur de hub virtuel gère automatiquement tout le routage.
  4. Les sites de branche se connectent via un VPN de site à site ou des passerelles ExpressRoute déployées à l’intérieur du hub virtuel.
  5. Lorsque vous déployez plusieurs hubs, ils s’interconnectent automatiquement sur le Microsoft principal, ce qui permet un transit global sans routage géré par le client.

Routage de hub virtuel

Le routeur de hub virtuel gère tout le routage entre les réseaux virtuels connectés, les branches et d’autres hubs. Comportements clés :

  • Transit automatique : Les réseaux virtuels connectés au même hub peuvent communiquer sans UDR. Le routeur hub propage les itinéraires entre toutes les connexions par défaut.
  • Transit inter-hub : Les itinéraires se propagent automatiquement entre les hubs dans la même Virtual WAN. Le trafic entre les régions transite via le réseau principal de Microsoft.
  • Tables de routage : Pour les scénarios d’isolation avancés (tels que l’isolation du développement à partir de la production), vous pouvez créer des tables de routage personnalisées au sein du hub pour contrôler la propagation des itinéraires.
  • Débit agrégé : Le routeur de hub virtuel prend en charge jusqu’à 50 Gbits/s de débit agrégé lorsqu’il est configuré avec le maximum de 50 unités d’infrastructure de routage. Le déploiement par défaut utilise 2 unités d’infrastructure de routage (3 Gbits/s). Vous augmentez le débit en augmentant les unités d’infrastructure de routage dans les paramètres du hub.

Note

Le routage automatique s’applique à la connectivité de transit standard. Les scénarios personnalisés qui routent le trafic via des appliances virtuelles réseau dans le hub peuvent nécessiter des tables de routage personnalisées.

Comment choisir

Cette section vous aide à sélectionner la topologie et le niveau appropriés pour votre environnement.

Hub-spoke comparé à Virtual WAN

Utilisez ce tableau pour déterminer si une topologie hub-spoke traditionnelle ou Virtual WAN est le bon choix pour votre environnement :

Facteur Hub-and-spoke (traditionnel) Azure Virtual WAN
Gestion Réseau virtuel hub géré par le client Infrastructure hub gérée par Microsoft
Idéal pour Jusqu’à ~30 connexions de branche VPN 30 branches VPN ou de nombreuses régions Azure
Routage Le client configure les UDR pour le trafic entre spokes. Routage automatique dans le hub virtuel
Intégration SD-WAN Déploiement et configuration manuels de l’appliance réseau virtuelle (NVA) Intégration native des partenaires SD-WAN
Transit mondial Nécessite un routage interrégion géré par le client Intégré : tous les hubs s’interconnectent automatiquement
Modèle de coût Ressources de réseau virtuel hub payées séparément (Pare-feu, passerelle, Bastion) Tarification de l’unité de déploiement et de l’unité d’échelle

Tip

Virtual WAN est une alternative évolutive au hub-spoke, pas un remplacement. Les organisations ayant moins de 30 branches, une seule région et un besoin de contrôle total sur les ressources hub doivent utiliser une topologie hub-and-spoke traditionnelle.

Considérations relatives à la migration : Si vous passez d'un hub-spoke traditionnel à Virtual WAN, planifiez une migration parallèle. Déployez un hub Virtual WAN en même temps que votre hub existant, migrez les connexions spoke de manière incrémentielle et validez le routage après chaque migration de connexion. Virtual WAN ne prend pas en charge l'importation de configurations UDR existantes. Vous devez donc redéfinir le routage pour utiliser le modèle de propagation automatique du routeur hub.

Quand rester avec hub-spoke : Choisissez le hub-spoke traditionnel si vous avez besoin d’un contrôle granulaire sur le réseau virtuel hub (par exemple, le déploiement d’appliances virtuelles virtuelles personnalisées directement dans le sous-réseau du hub), si votre organisation fonctionne dans une seule région avec moins de 10 branches, ou si les exigences de conformité imposent l’infrastructure de routage gérée par le client.

Standard comparé au niveau de base

Virtual WAN offre deux niveaux. Choisissez le niveau qui correspond à vos besoins de routage et de connectivité :

Fonctionnalité Basic Standard
VPN de site à site ✅ ✅
VPN de point à site ❌ ✅
ExpressRoute ❌ ✅
Transit VNet à VNet ❌ ✅
Transit entre hubs ❌ ✅
Pare-feu Azure dans le hub ❌ ✅
NVA dans un hub ❌ ✅

Important

Vous pouvez passer de l’offre Base à l’offre Standard, mais vous ne pouvez pas revenir de l’offre Standard à l’offre Base. Choisissez Standard si vous avez besoin d’un routage de transit, d’une connectivité ExpressRoute ou d’une intégration de sécurité.

Modèle de coût

Virtual WAN utilise la tarification basée sur une unité qui diffère de celle du hub-spoke traditionnel :

  • Unités de déploiement (hub) : Vous payez un tarif par heure pour le hub virtuel lui-même. Ces frais sont un coût fixe pour l’infrastructure de hub managé.
  • Unités d’échelle (passerelles) : Les passerelles VPN et ExpressRoute sont facturées en fonction du nombre d’unités d’échelle que vous approvisionnez. Plus d’unités d’échelle augmentent la capacité de bande passante et le coût proportionnellement.
  • Unités d’infrastructure de routage : Le routeur hub est facturé par unité d’infrastructure de routage. Le déploiement par défaut comprend deux unités (3 Gbits/s). Vous pouvez effectuer un scale-up jusqu’à 50 unités (50 Gbits/s) pour les environnements à haut débit.
  • Traitement des données : Vous payez le traitement des données transitant par le hub, y compris le trafic VNet à VNet, le trafic entre les branches et le réseau virtuel, ainsi que le trafic entre hubs. Le trafic lié à Internet routé via Pare-feu Azure a des frais de traitement des données distincts.
  • Module complémentaire Virtual Hub sécurisé : Lorsque vous déployez Pare-feu Azure via Firewall Manager, les frais de Pare-feu Azure standard s’appliquent également aux coûts de Virtual WAN hub.

Comparez les coûts par rapport à une topologie hub-spoke traditionnelle. Pour les petits déploiements avec des branches minimales, un hub géré par le client peut être plus rentable. Pour les grands nombres de branches (30+), l'automatisation et l'infrastructure managée de Virtual WAN ont généralement compensé la tarification par unité. Pour obtenir des tarifs détaillés, consultez Virtual WAN concepts de tarification.

Hub virtuel sécurisé : quand utiliser Firewall Manager

Un hub virtuel sécurisé intègre Pare-feu Azure (ou une NVA prise en charge) à Firewall Manager pour une stratégie centralisée :

Configuration À utiliser lorsque Benefit
Hub virtuel standard (aucun pare-feu) Connectivité uniquement entre les succursales et les réseaux virtuels, la sécurité étant gérée au niveau des spokes. Déploiement le plus simple, coût le plus bas
Hub virtuel sécurisé avec Firewall Manager Inspection centralisée du trafic pour le trafic privé et Internet Stratégie cohérente : l’intention de routage élimine le besoin d’UDR
Hub virtuel sécurisé avec un partenaire NVA Investissement de pare-feu tiers existant, exigences spécifiques en matière de fonctionnalités Utiliser les outils et l’expertise existants des fournisseurs

Intention de routage

L’intention de routage simplifie le contrôle du trafic dans Virtual WAN en guidant automatiquement le trafic via une solution de sécurité (Pare-feu Azure ou NVA prise en charge) sans tables de routage personnalisées ou UDR.

Lorsque vous activez l’intention de routage, vous déclarez des stratégies pour deux types de trafic :

  • Trafic Internet : Tout le trafic à destination d’Internet provenant des réseaux virtuels connectés transite par la solution de sécurité dans le hub.
  • Trafic privé : Tout le trafic entre les réseaux virtuels, les branches et les autres hubs passe par la solution de sécurité.

L’intention de routage supprime la nécessité de gérer manuellement les tables de routage. Le plan de contrôle de Virtual WAN configure automatiquement tous les itinéraires nécessaires entre tous les hubs connectés et les réseaux virtuels spoke.

Note

L’intention de routage nécessite un hub virtuel sécurisé avec Pare-feu Azure ou un partenaire NVA pris en charge. Il n’est disponible que sur le niveau Standard.

Warning

Les modifications que l’intention de routage apporte à la table de routage sont irréversibles. Vous pouvez supprimer l’intention de routage, mais la suppression ne restaure pas automatiquement votre configuration defaultRouteTable précédente. Enregistrez un instantané de votre configuration avant d’activer l’intention de routage, car vous devez restaurer manuellement les itinéraires précédents si vous le supprimez ultérieurement.

Limites de connexion et scalabilité

Virtual WAN prend en charge les déploiements à grande échelle :

  • Jusqu’à 1 000 connexions VPN de site à site par hub virtuel.
  • Plusieurs hubs par Virtual WAN (un par région ou plusieurs par région pour l’isolation).
  • Jusqu’à 50 Gbits/s de débit agrégé par routeur hub (nécessite un maximum de 50 unités d’infrastructure de routage. La valeur par défaut est de 2 unités à 3 Gbits/s.
  • Connectivité de type any-to-any sur toutes les connexions VNet, les branches VPN et les circuits ExpressRoute au sein du même hub.

Pour les organisations qui dépassent les limites d’un hub unique, déployez des hubs supplémentaires dans les mêmes régions ou différentes. Le Virtual WAN gère automatiquement le routage entre hubs.

intégration des partenaires SD-WAN

Virtual WAN fournit une intégration native avec des appareils partenaires SD-WAN. Les appareils partenaires peuvent :

  • Exportez les informations d’appareil de branche vers Azure par programme.
  • Téléchargez automatiquement la configuration Azure.
  • Établissez une connectivité IPsec/IKE au hub virtuel sans configuration manuelle.

Cette automatisation réduit le temps de déploiement de branche de jours à minutes à grande échelle. Pour obtenir la liste actuelle des partenaires pris en charge, consultez Virtual WAN partenaires.

Comment fonctionne l’automatisation des partenaires

Les partenaires SD-WAN utilisent l’API d’automatisation de la connectivité Virtual WAN pour gérer programmatiquement le cycle de vie des appareils de succursale :

  • Inscription de l’appareil : Le contrôleur partenaire inscrit des appareils de branche avec la ressource Virtual WAN, y compris les métadonnées de l’appareil et les exigences de bande passante.
  • Téléchargement de la configuration : La plateforme partenaire extrait la configuration de la passerelle hub (adresses IP, clés pré-partagées, paramètres BGP) sans interaction manuelle du portail.
  • Établissement de tunnel : L’appareil partenaire établit des tunnels IPsec vers la passerelle VPN du hub virtuel à l’aide de la configuration téléchargée.
  • Surveillance continue de l’état de santé : La plateforme partenaire surveille l’état de santé des tunnels et peut rétablir la connexion en cas d’interruption des tunnels.

Les partenaires tels que VMware SD-WAN, Fortinet SD-WAN, Cisco Viptela et Versa Networks prennent en charge ce modèle d’automatisation. Chaque partenaire implémente sa propre couche d’orchestration au-dessus de l’API Virtual WAN. Évaluez les fonctionnalités spécifiques aux partenaires, telles que le routage prenant en charge les applications, l’optimisation du trafic et le breakout Internet local avant de sélectionner un partenaire.

Considérations relatives à la conception

Pour la plupart des migrations lift-and-shift, Virtual WAN n'est pas la topologie de départ. Évaluez quand il est justifié :

  • Quand Virtual WAN devient justifié. Si votre environnement lift-and-shift comprend plus de 30 sites de succursales, s'étend sur trois régions Azure ou plus, ou nécessite une intégration SD-WAN, le routage automatisé de Virtual WAN réduit la surcharge opérationnelle par rapport à la gestion des UDR sur de nombreux peerings hub-and-spoke.
  • Une architecture hub-and-spoke suffit pour les environnements de plus petite taille. Un seul hub avec passerelle VPN prend en charge jusqu'à 30 connexions site à site et 500 peerings de spokes. Si votre migration reste dans ces limites, le hub-spoke traditionnel est plus simple et plus économique.
  • Le chemin de migration existe. Si vous commencez avec hub-spoke et que vous avez besoin ultérieurement de Virtual WAN, vous pouvez migrer en déployant un hub Virtual WAN en même temps que vos connexions hub et spoke existantes de manière incrémentielle.

Les déploiements multirégions ne nécessitent pas automatiquement Virtual WAN. Évaluez la complexité de votre routage :

  • Le double hub-spoke suffit souvent. Pour les architectures actif-actif sur deux régions, déployez un hub dans chaque région avec un peering de réseaux virtuels entre les hubs. Ce modèle gère la plupart des scénarios de modernisation sans surcharge tarifaire par unité de Virtual WAN.
  • Lorsque la complexité pousse vers Virtual WAN. Si votre modernisation dépasse deux régions, ajoute une connectivité de branche entre les régions ou nécessite une propagation automatique d’itinéraires inter-hubs sans gestion manuelle des UDR, Virtual WAN simplifie les opérations.
  • Ne confondez pas l'agrégation multirégion avec Virtual WAN. La décision d’utiliser Virtual WAN dépend du nombre de branches, du nombre de régions et de la complexité du routage. La multirégion seule n’est pas suffisante.

Virtual WAN fournit le Azure équivalent de AWS Transit Gateway pour le transit centralisé et évolutif :

  • Équivalence de Transit Gateway Le hub virtuel de Virtual WAN fonctionne comme AWS Transit Gateway : il achemine automatiquement le trafic entre les réseaux virtuels connectés, les succursales et les tunnels VPN intercloud. Si vous migrez à partir d’AWS, ce mappage simplifie la traduction de votre architecture.
  • Hub virtuel sécurisé (hub virtuel sécurisé). Déployez Pare-feu Azure via Firewall Manager dans le hub virtuel. Activez l’intention de routage pour diriger tout le trafic privé et Internet via le pare-feu. Cela fournit une inspection centralisée du trafic intercloud entrant Azure.
  • Connexions VPN à Google Cloud et AWS. Créez des connexions VPN de site à site à partir du hub Virtual WAN vers google Cloud VPN (VPN HA) et des passerelles privées virtuelles AWS. Virtual WAN prend en charge jusqu’à 1 000 connexions VPN par hub, ce qui offre une marge de croissance lorsque vous migrez plus de charges de travail.
  • Planification multirégion. Déployez des hubs virtuels dans chaque région Azure où les applications migrées atterrissent. Le routage inter-hub se propage automatiquement sur le réseau principal de Microsoft, reproduisant le modèle d’appairage de Transit Gateway dans AWS.

Prerequisites

Avant d’implémenter une topologie Virtual WAN :

  • Comprendre les concepts de l'architecture hub-and-spoke. Virtual WAN s’appuie sur le modèle hub-spoke. Passez en revue la topologie hub-and-spoke pour connaître les concepts fondamentaux.
  • Recensez vos sites de succursales. Documentez le nombre de branches, leur distribution géographique et la connectivité actuelle (VPN, MPLS, SD-WAN).
  • Définissez votre stratégie de région. Déterminez les Azure régions qui hébergent des charges de travail et où vous avez besoin de hubs virtuels.
  • Choisissez votre niveau. Choisissez entre Basic (VPN de site à site uniquement) et Standard (transit complet, ExpressRoute, pare-feu) en fonction du tableau de comparaison de niveaux de cet article.
  • Évaluez les exigences de sécurité. Déterminer si une inspection centralisée (hub virtuel sécurisé) ou une sécurité par spoke est plus appropriée.

Considérations relatives à la sécurité

  • Hub virtuel sécurisé. Déployez Pare-feu Azure via Firewall Manager pour appliquer des stratégies de sécurité cohérentes sur tous les réseaux virtuels et branches connectés. Firewall Manager fournit une gestion centralisée des règles sur plusieurs hubs sécurisés.
  • Intention de routage. Activez l’intention de routage pour diriger automatiquement le trafic privé et Internet via votre solution de sécurité. Cette approche empêche le trafic de contourner l’inspection en éliminant la configuration manuelle du routage.
  • Limitations des NVA dans le hub. Les appliances virtuelles réseau déployées dans le hub ont des fonctionnalités différentes de Pare-feu Azure. Vérifiez la parité des fonctionnalités avec vos exigences de sécurité avant de choisir un partenaire NVA.
  • Modèle de sécurité SD-WAN. Lorsque vous intégrez SD-WAN appareils partenaires, la sécurité du trafic dépend de l’implémentation du partenaire. Évaluez les fonctionnalités de chiffrement, d’authentification et d’inspection du trafic du partenaire.
  • Isolation du trafic inter-hub. Le trafic entre les hubs virtuels transite par le Microsoft principal et ne traverse pas l'Internet public. Le réseau principal est un réseau privé, mais le trafic n’est pas chiffré au niveau de la couche réseau par défaut. Utilisez le protocole TLS de couche application pour les données interrégions sensibles.

Learn more

Étapes suivantes

Tip

Vous explorez vous-même ? Revenez au navigateur de vue d’ensemble pour trouver votre prochain article par fonctionnalité.

Étape suivante de votre parcours lift-and-shift :

Connectivité hybride : connectez vos charges de travail migrées à l’environnement local via passerelle VPN ou ExpressRoute.

Ensuite, dans votre parcours de modernisation :

Planifiez votre déploiement multirégion : étendez votre conception à plusieurs régions pour une résilience actif-actif.

Prochaine étape de votre parcours multi-cloud :

Concevoir les réseaux virtuels de votre zone d'atterrissage Azure : construisez la base des réseaux virtuels Azure pour vos charges de travail connectées et migrées.

  • Last updated on