Microsoft AZ-700: Azure Virtual WAN et Hub-Spoke — Guide d'étude

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Network Engineer AZ-700 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Virtual WAN versus hub-and-spoke classique : choisir le bon modèle de transit

La conception d’un transit mondial nécessite de choisir entre Azure Virtual WAN (vWAN) et une architecture hub-and-spoke traditionnelle construite à partir de VNets, de NVAs et d’appairages. Virtual WAN fournit une dorsale mondiale gérée par Microsoft avec des vHubs qui hébergent nativement la connectivité VPN, ExpressRoute et P2S et prennent en charge la propagation automatisée des routes, la mise à l’échelle de site à site et les intégrations de partenaires SD‑WAN. Pour les organisations nécessitant de nombreuses connexions de succursales, un routage mondial et un modèle opérationnel simple, vWAN réduit le travail d’orchestration et améliore la résilience. En revanche, un modèle hub-and-spoke manuel (un VNet avec un Azure Firewall ou un NVA tiers dans un hub central et des spokes appairés) offre un contrôle maximal sur le flux de paquets, des fonctionnalités NVA personnalisées et souvent un coût en régime permanent plus faible pour les petits déploiements. Les principaux compromis sont le débit et la prévisibilité par rapport au contrôle granulaire : les hubs vWAN abstraient de nombreux détails et offrent une mise à l’échelle quasi mondiale, mais ajoutent des coûts de service géré et une personnalisation moins flexible du chemin des paquets. Les pièges courants incluent le fait de supposer que vWAN fournit automatiquement un appairage transitif vers des VNets non explicitement connectés ; chaque spoke ou VNet doit être connecté et associé aux tables de routage du hub. Une autre erreur fréquente est de négliger la gouvernance et les contraintes de nommage des sous-réseaux (par exemple, l’exigence d’un AzureFirewallSubnet pour Azure Firewall) qui interrompent les déploiements automatisés si elles ne sont pas respectées.

Hub virtuel sécurisé, intégration d’Azure Firewall et de NVA

Le modèle de hub virtuel sécurisé ajoute des couches d’inspection et de politique à vWAN en intégrant Azure Firewall (ou un NVA tiers) et Firewall Manager pour centraliser la sécurité, le NAT et le routage pour les spokes et les sites sur site. Azure Firewall doit être déployé dans le sous-réseau dédié AzureFirewallSubnet et vous devez choisir entre les références (SKU) d’Azure Firewall en fonction des fonctionnalités. Planifiez soigneusement les tables de routage : les tables de routage du hub contrôlent les flux vers les spokes, les sites VPN, P2S et Internet. Pour forcer le tunneling du trafic vers un NVA, vous associez la connexion du spoke à une table de routage du hub qui dirige 0.0.0.0/0 vers le NVA/Firewall. Tenez compte de la haute disponibilité et du débit : Azure Firewall est zonal et prend en charge la mise à l’échelle automatique avec les références (SKU) Standard et Premium, mais la référence Premium est requise pour l’inspection TLS et l’IDPS. Évitez de placer des points de terminaison Application Gateway ou Private Link dans des sous-réseaux partagés avec l’infrastructure du pare-feu ; ils nécessitent leurs propres sous-réseaux. Surveillez l’épuisement des ports NAT et SNAT pour les flux sortants à grande échelle ; mettez en œuvre le pooling SNAT, Azure Firewall avec des règles DNAT, ou utilisez NAT Gateway le cas échéant.

Azure Firewall Standard vs Premium : Standard prend en charge le pare-feu avec état (stateful), le filtrage FQDN, le SNAT/DNAT de base ; Premium ajoute l’inspection TLS, l’IDPS, le filtrage d’URL et les exclusions de balises de nom de domaine complet (FQDN).
Load Balancer Basic vs Standard : Standard prend en charge la redondance de zone, les sondes d’intégrité du backend et est requis pour le service Private Link ILB ; Basic ne dispose pas de la résilience de zone et a des règles de sécurité plus strictes.
Références (SKU) de VPN Gateway : VpnGw1/2/3 (débit et tunnels simultanés croissants) ; utilisez des niveaux supérieurs pour plus de tunnels S2S ou un débit agrégé plus élevé.

Modèles de connectivité privée : Private Link, points de terminaison privés et points de terminaison de service

Private Link et les points de terminaison privés fournissent un accès PaaS de premier ordre sans router le trafic sur Internet ; les points de terminaison de service sécurisent l’accès au service mais conservent la sortie via la dorsale du service public. Utilisez un point de terminaison privé lorsque vous avez besoin d’adresses IP privées par ressource et d’une intégration DNS ; utilisez des points de terminaison de service lorsque vous avez besoin d’un contrôle d’accès plus simple au niveau du sous-réseau et que vous êtes à l’aise avec l’exposition de la sortie du service à la dorsale du service. Les détails opérationnels importants incluent la résolution DNS : les points de terminaison privés nécessitent la mise à jour du DNS sur site ou des Azure DNS Private Zones pour que les clients résolvent l’adresse IP privée ; les redirecteurs conditionnels vers les serveurs DNS sur site sont courants pour les réseaux connectés en S2S. Les scénarios de service Private Link inter-abonnements sont pris en charge si les ressources se trouvent dans le même tenant Azure AD ; déployez le service Private Link derrière un Standard internal Load Balancer (ILB) pour la mise à l’échelle et la redondance de zone. Un piège fréquent consiste à utiliser un Basic ILB ou une référence (SKU) incorrecte, ce qui limite l’intégrité et la mise à l’échelle du backend. Pour un service Private Link prenant en charge un volume de connexions élevé, utilisez un Standard ILB, des backends en groupe de machines virtuelles identiques (scale-set) et envisagez plusieurs cartes réseau de point de terminaison par instance de backend. Pensez également à la protection DDoS : activez DDoS Protection Standard pour les cartes réseau exposées publiquement et planifiez la mise à l’échelle des ports SNAT et NAT Gateway là où de nombreuses connexions sortantes sont initiées.

Tables de routage du hub vWAN et conception pratique des routes

vWAN utilise les tables de routage du hub pour diriger le trafic entre les spokes connectés, les sites sur site et Internet. Chaque connexion (site, VNet, P2S) peut être associée à une table de routage du hub ; les priorités de route et les règles de propagation déterminent le transfert final. Une bonne conception commence par une table de routage du hub par défaut qui transfère le trafic destiné à Internet vers Azure Firewall ou une NVA, et des tables de routage spécialisées pour les succursales qui nécessitent une sortie locale sur site. Le protocole BGP des appareils VPN sur site propage les préfixes dans le hub, et vous pouvez les redistribuer aux spokes ou les filtrer avec des tables de routage. Un écueil courant est la présence de routes définies par l’utilisateur (UDRs) conflictuelles dans les VNets spokes qui tentent de supplanter la propagation du hub ; dans vWAN, les tables de routage du hub ont la priorité pour les interconnexions, mais les UDRs sur les spokes affectent toujours la sortie locale. Pour le tunneling forcé, associez les connexions des spokes à une table de routage du hub dirigeant 0.0.0.0/0 vers l’appareil d’inspection de votre choix. Surveillez et planifiez les limites de routes : les hubs vWAN ont un nombre maximum de préfixes appris et annoncés — concevez la sumarisation des préfixes et utilisez des communautés ou des filtres BGP pour rester dans les limites. Testez toujours la résolution DNS et le split-DNS pour les points de terminaison privés, et documentez le comportement de basculement pour les conceptions multi-hub actif/actif afin de respecter les SLA de résilience.

Problème pratique : Scénario d’utilisation

Scénario : Contoso Manufacturing exploite une empreinte Azure mondiale avec une architecture VNet en étoile (hub-and-spoke) existante dans deux régions, plusieurs sites sur site connectés via SD-WAN, et une exigence de centraliser la sécurité et de fournir une connectivité PaaS privée entre les abonnements.

Défi : Ils ont besoin d’un transit mondial géré et évolutif qui centralise l’inspection (inspection TLS, IDPS), prend en charge de nombreuses connexions de succursales via SD-WAN, et expose plusieurs ressources PaaS de stockage et de base de données de manière privée aux spokes et aux sites sur site sans les exposer publiquement.

Approche recommandée :

Déployez Azure Virtual WAN (vWAN) et créez des hubs virtuels sécurisés dans chaque région. Dans chaque hub, activez Azure Firewall Premium (pour l’inspection TLS et l’IDPS) et intégrez-le avec Firewall Manager. Associez le hub aux connexions SD-WAN partenaires du vWAN pour un accès direct des succursales.
Configurez les tables de routage du hub pour diriger le trafic destiné à Internet et inter-régions vers Azure Firewall Premium ; créez des tables de routage spécialisées pour les succursales qui doivent sortir via l’infrastructure sur site. Utilisez le BGP du SD-WAN pour annoncer les préfixes sur site dans vWAN et appliquez des filtres de préfixes pour éviter l’inflation des routes.
Pour les services PaaS, provisionnez des services Private Link dans un VNet dédié par région derrière un Standard Internal Load Balancer, et exposez des Private Endpoints dans les VNets spokes et sur site via la connectivité vWAN. Utilisez des Azure DNS Private Zones et des redirecteurs conditionnels pour assurer la résolution depuis les sites sur site.
Activez DDoS Protection Standard sur les points de terminaison publics, déployez NAT Gateway pour les besoins importants de SNAT sortant sur les spokes, et surveillez les métriques SNAT/DNAT. Utilisez les stratégies de Firewall Manager pour la distribution centralisée des règles et configurez la journalisation vers un espace de travail Log Analytics central.

Justification : Cette approche tire parti de vWAN pour une connectivité évolutive des succursales et un transit mondial, utilise Azure Firewall Premium pour l’inspection avancée et centralisée requise par la politique de sécurité, et Private Link pour un accès sécurisé aux services PaaS sans exposition publique — équilibrant ainsi la facilité de gestion, la sécurité et l’échelle opérationnelle.

← Surveillance et dépannage du réseau · Tous les domaines

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →