Microsoft AZ-700: Conception d'Azure Virtual Network — 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.

Planification de l’espace d’adressage et des sous-réseaux

Un plan d’adressage IP rigoureux prévient les remaniements futurs et évite les collisions avec les réseaux sur site ou d’autres VNets. Utilisez des blocs CIDR hiérarchiques (par exemple, un /16 par grande unité commerciale, /24 par VNet, /26–/22 par sous-réseau selon le rôle) et réservez des plages contiguës pour l’expansion, le peering et les mappages de sites VPN/S2S. Azure impose des exigences de nom et de sous-réseau pour plusieurs services de plateforme : GatewaySubnet doit exister (et être dimensionné pour inclure la passerelle VPN et ses unités de mise à l’échelle), AzureFirewallSubnet doit être dédié et nommé AzureFirewallSubnet, et AzureBastionSubnet doit être un sous-réseau dédié de /27 ou plus. Application Gateway et de nombreuses appliances virtuelles de réseau (NVA) nécessitent également des sous-réseaux dédiés (sans autres ressources). Planifiez le non-chevauchement des adresses entre les VNets appairés et les plages sur site ; des espaces d’adressage qui se chevauchent interrompent le peering, le VPN et le routage. Envisagez la délégation de sous-réseau lors du déploiement de services de plateforme (AKS, instances managées Azure Database) et évitez de placer des NSG ou des UDR qui entrent en conflit avec les routes de plateforme requises pour ces services. Un piège courant est de sous-dimensionner le GatewaySubnet ou l’AzureFirewallSubnet ; ces services peuvent se mettre à l’échelle et nécessiter des adresses IP supplémentaires au fil du temps. Compromis : des CIDR plus petits économisent de l’espace d’adressage mais augmentent le risque de reconfiguration future ; des CIDR plus grands ne coûtent rien mais augmentent la surface de gestion. Documentez toutes les attributions et réservez des blocs pour les points de terminaison privés PaaS, les hôtes de rebond, les agents de surveillance et la capacité NAT de sortie.

Peering de VNet, transit par passerelle et précédence des routes

Le peering de VNet fournit une connectivité à faible latence et à large bande passante, mais n’est pas transitif : le trafic provenant d’un spoke appairé n’est pas automatiquement acheminé via un second VNet appairé pour atteindre les ressources sur site. Pour centraliser la connectivité sur site, vous devez déployer un VNet hub avec une passerelle VPN Gateway ou ExpressRoute. Configurez le peering du hub avec l’option allowGatewayTransit activée et configurez le peering du spoke avec l’option useRemoteGateways activée ; la VPN Gateway ne doit exister que dans le hub. N’oubliez pas que le peering nécessite des espaces d’adressage qui ne se chevauchent pas et prend en charge le peering régional et mondial (le peering mondial entraîne des coûts de transfert de données et une latence légèrement plus élevée). La précédence des routes est importante : les routes définies par l’utilisateur (UDR) priment sur les routes apprises par BGP et les routes système ; les routes BGP priment sur les routes système. Si vous avez besoin de tunneling forcé pour l’inspection du trafic sortant, créez des UDR qui pointent vers une VirtualAppliance (NVA) ou un Azure Firewall, puis annoncez les routes appropriées vers les réseaux sur site via BGP si nécessaire. Les pièges courants incluent l’oubli de définir allowGatewayTransit sur le hub ou useRemoteGateways sur les spokes, l’échec du re-téléchargement des configurations client P2S après l’ajout de spokes (les clients P2S ont besoin de routes mises à jour), et le fait de supposer que le peering est transitif. Choisissez les SKU de VPN Gateway en fonction du débit et des fonctionnalités P2S : envisagez VpnGw1/2/3 pour la production P2S et BGP ; la version Basic manque de nombreuses fonctionnalités.

SKU de VPN Gateway : VpnGw1 — débit modéré, prend en charge OpenVPN/IKEv2/P2S ; VpnGw2 — débit plus élevé et mise à l’échelle TLS ; VpnGw3 — débit le plus élevé et plus grande échelle. Basic — fonctionnalités limitées et non recommandé pour les scénarios de hub.

Points de terminaison de service vs points de terminaison privés et implications DNS

Les points de terminaison de service étendent l’identité de votre VNet aux services PaaS d’Azure (Storage, SQL, Cosmos DB) afin que le trafic utilise le réseau principal de Microsoft, tandis que le point de terminaison public du service est sécurisé pour les sous-réseaux sélectionnés. Les points de terminaison privés placent une interface réseau dans votre sous-réseau qui est mappée à l’adresse IP privée de la ressource PaaS, offrant une véritable connectivité privée. Choisissez les points de terminaison de service lorsque vous souhaitez un contrôle d’accès simple au niveau du sous-réseau sans modification DNS ; choisissez les points de terminaison privés lorsque vous avez besoin d’un accès par ressource, d’une isolation au niveau du VNet ou de désactiver complètement l’accès au réseau public. Les points de terminaison privés créent une ENI et doivent être associés à une zone DNS privée (privatelink.<service>.azure.com) ou nécessitent des enregistrements DNS A manuels — un piège fréquent est de négliger le DNS, ce qui amène les clients à résoudre l’adresse IP publique au lieu de celle du point de terminaison privé. Sachez également que les points de terminaison privés consomment une adresse IP du sous-réseau cible ; planifiez la capacité en adresses IP. Les points de terminaison de service ne suppriment pas le point de terminaison public — pour verrouiller complètement un compte de stockage, vous devez désactiver l’accès au réseau public après avoir activé le point de terminaison privé. Compromis en termes de coût et d’exploitation : les points de terminaison privés augmentent la gestion (DNS par ressource et approbations) et une légère complexité opérationnelle, mais offrent une isolation plus forte ; les points de terminaison de service sont plus simples et moins coûteux, mais moins granulaires.

Passerelle NAT, Azure Firewall et compromis de conception des routes

Pour un SNAT sortant prévisible et une gestion simplifiée de la sortie (egress), déployez Azure Virtual Network NAT (Standard NAT Gateway) sur des sous-réseaux ou des cartes réseau (NIC) et attachez des adresses IP publiques Standard ou des préfixes (SKU standard uniquement). La passerelle NAT (NAT Gateway) décharge la gestion des ports éphémères ; si vous prévoyez un grand nombre de connexions sortantes, attachez plusieurs préfixes d’adresses IP publiques pour augmenter le nombre de ports SNAT disponibles et éviter l’épuisement des ports, un problème courant avec de nombreuses machines virtuelles ou hôtes de conteneurs. Azure Firewall fournit une inspection d’état (stateful) centralisée et entièrement gérée, des renseignements sur les menaces (threat intelligence) et un filtrage des applications/FQDN ; choisissez Azure Firewall Standard pour un filtrage fondamental et le SKU Premium pour l’inspection TLS, l’IDPS et des capacités de protection contre les menaces améliorées. Les appliances virtuelles de réseau (NVA tierces) offrent une richesse fonctionnelle ou des alternatives de coût, mais nécessitent une gestion, une configuration de haute disponibilité (HA) et une planification de la mise à l’échelle. Les UDR pointant vers une VirtualAppliance ou Internet/NAT doivent être évaluées par rapport aux routes système d’Azure, car des UDR incorrectes peuvent interrompre le trafic des services de la plateforme (par exemple, en bloquant le trafic des points de terminaison de service ou les sondes d’intégrité gérées par la plateforme). Pour une haute disponibilité et des performances élevées, envisagez les SKU redondants interzones (Application Gateway v2, Firewall dans des zones de disponibilité) et les capacités de mise à l’échelle automatique (autoscaling) par rapport aux appliances à coût fixe. Pièges courants : attacher une passerelle NAT à la fois à un sous-réseau et à une carte réseau (NIC) entraîne une précédence inattendue ; oublier qu’une passerelle NAT nécessite une ou des adresses IP publiques Standard ; nommer et dimensionner incorrectement l’AzureFirewallSubnet ; et supposer que les UDR seront ignorées — elles remplacent les routes système.

Problème pratique : Scénario d’utilisation

Scénario : Contoso Enterprises exploite un réseau Azure en étoile (hub-and-spoke). Le hub dans la région West US héberge une passerelle ExpressRoute et une VpnGw2 (GatewaySubnet). Plusieurs spokes contiennent des sous-réseaux d’application et des points de terminaison privés pour les services PaaS. Les employés distants se connectent via un VPN Point-to-Site (P2S) au hub.

Défi : Les utilisateurs distants peuvent accéder aux ressources dans le hub mais ne peuvent pas atteindre les ressources VNet dans les spokes après de récents ajouts de spokes, et certains clients P2S affichent des ensembles de routes obsolètes.

Approche recommandée :

Dans le VNet du hub, assurez-vous que la passerelle VPN est une VpnGw2 déployée dans un GatewaySubnet correctement dimensionné (au moins /27) ; validez qu’il s’agit de la seule passerelle dans la topologie appairée et qu’ExpressRoute coexiste via l’échange de routes.
Sur l’appairage (peering) du hub vers le spoke, définissez allowGatewayTransit = true du côté du hub. Sur chaque appairage de spoke, définissez useRemoteGateways = true et assurez-vous que les espaces d’adressage ne se chevauchent pas.
Régénérez et distribuez la configuration client VPN P2S mise à jour depuis la passerelle VPN du hub (incluez IKEv2/OpenVPN) et demandez aux utilisateurs distants de réinstaller le client afin que leurs tables de routage incluent les nouveaux préfixes des spokes.
Si les spokes doivent router leur trafic sortant via le hub pour inspection, ajoutez des UDR dans les tables de routage des spokes dirigeant 0.0.0.0/0 vers l’appliance virtuelle du hub ou vers Azure Firewall (déployé dans l’AzureFirewallSubnet) et annoncez les routes nécessaires en retour via BGP sur ExpressRoute/VPN.

Justification : L’activation du transit de passerelle avec useRemoteGateways centralise le routage sur site (on-prem) et P2S via la passerelle du hub sans créer de passerelles supplémentaires, tandis que la réémission des configurations client P2S met à jour les tables de routage des clients pour que les nouveaux préfixes des spokes soient accessibles ; les UDR et BGP assurent une sortie (egress) contrôlée et une visibilité pour l’inspection.

← ExpressRoute et connectivité WAN · Tous les domaines · Réseau hybride →

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