Microsoft AZ-900: Réseau — Guide d'étude

By Laurynas Brazys · 22 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure AZ-900 — 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.

La mise en réseau Azure constitue le fondement pour connecter de manière sécurisée les charges de travail, les utilisateurs et les services entre les régions, ainsi qu’entre les environnements sur site et cloud. Elle englobe les réseaux privés définis par logiciel, la connectivité hybride, la distribution de trafic mondial et des défenses en couches contre les menaces. Les conceptions robustes commencent par une planification claire des adresses, des limites d’isolement et la résolution de noms, puis ajoutent la bonne combinaison de connectivité et de protection pour atteindre les objectifs de performance et de conformité.

Réseau virtuel de base : VNets, subnets, adressage IP et DNS

Un réseau virtuel (VNet) est la limite d’isolement pour la mise en réseau privée dans Azure. Les VNets s’étendent sur une seule région, sont limités à un abonnement et utilisent des espaces d’adressage RFC1918 que vous définissez. Au sein d’un VNet, les subnets segmentent l’espace d’adressage en niveaux logiques (par exemple, web, application et données). Les subnets prennent en charge des stratégies réseau telles que les groupes de sécurité réseau (NSG), les tables de routage, les points de terminaison de service et la délégation à des services PaaS spécifiques. Une planification CIDR réfléchie évite les chevauchements avec les réseaux sur site et d’autres VNets que vous pourriez appairer à l’avenir. L’adressage IP dans Azure inclut des adresses privées et publiques. Les adresses IP privées s’attachent aux cartes réseau (NIC) des machines virtuelles et autres ressources pour le trafic est-ouest à l’intérieur d’un VNet ou via le peering et VPN/ExpressRoute. Les adresses IP privées peuvent être dynamiques ou statiques au sein d’un subnet. Les adresses IP publiques exposent des ressources à Internet ou fournissent une connectivité sortante via NAT. Les adresses IP publiques Standard sont redondantes entre les zones là où c’est disponible, sont fermées au trafic entrant par défaut et doivent être combinées avec des équilibreurs de charge (load balancers), des Application Gateways ou Azure Firewall plutôt que d’être attribuées directement à des VM, sauf justification solide. La résolution de noms est gérée par défaut par le résolveur DNS fourni par Azure (168.63.129.16), qui résout les noms d’hôte au sein d’un VNet. Pour les points de terminaison privés et la résolution de noms hybride, les zones Azure Private DNS mappent les noms de domaine complets (FQDN) privés (par exemple, privatelink.database.windows.net) à des adresses IP privées. Vous pouvez lier des zones DNS privées à plusieurs VNets. Si vous utilisez des serveurs DNS personnalisés, assurez-vous que le transfert conditionnel couvre les zones Azure Private DNS afin que les ressources résolvent les points de terminaison privés au lieu des points de terminaison de service publics.

• Portée
  • IP privée : Au sein des réseaux VNet/appairés/hybrides
  • IP publique : Exposée à Internet
• Attribution
  • IP privée : Dynamique ou statique par NIC/subnet
  • IP publique : Dynamique ou statique ; SKU Standard recommandé
• Usages courants
  • IP privée : VM à VM, Private Link, équilibrage de charge interne
  • IP publique : Entrant via LB/App Gateway ; sortant via SNAT/NAT Gateway
• Posture de sécurité
  • IP privée : Contrôlée par les NSG, UDR
  • IP publique : Fermée par défaut (Standard) ; à restreindre avec les NSG/Firewall

Connectivité hybride et privée : VPN Gateway, ExpressRoute, Peering de réseaux virtuels et Private Link

Azure VPN Gateway établit des tunnels chiffrés utilisant IPsec/IKE pour les connexions de site à site (S2S), de point à site (P2S) et de VNet à VNet. C’est un moyen économique d’étendre votre réseau sur site vers Azure via l’Internet public tout en maintenant les données chiffrées en transit. Le débit et le nombre de tunnels évoluent avec la SKU VpnGw, et la haute disponibilité est assurée par défaut avec des instances actif/passif. Le support actif/actif et BGP permet un routage dynamique et un débit agrégé plus élevé. ExpressRoute fournit une connectivité privée de couche 3 (Layer 3) vers Microsoft, garantie par un SLA, via la périphérie d’un partenaire ou un peering direct. Le trafic reste en dehors de l’Internet public, offrant une latence prévisible et des options de bande passante plus élevées. Les circuits ExpressRoute prennent en charge plusieurs peerings (Azure private, Microsoft et Microsoft 365 le cas échéant) et utilisent des connexions redondantes doubles. C’est l’option privilégiée pour les scénarios critiques et à haut débit, souvent combinée avec une topologie en étoile (hub-and-spoke) où le VNet hub héberge la passerelle ExpressRoute ou VPN Gateway. Le peering de réseaux virtuels (VNet peering) relie des VNets sur le réseau principal de Microsoft avec une faible latence et une bande passante élevée, permettant aux ressources de communiquer en utilisant des adresses IP privées comme si elles étaient sur le même réseau. Le peering n’est pas transitif : le trafic n’est pas automatiquement acheminé via un VNet pairé vers un troisième VNet. Le transit de passerelle peut être activé pour que les VNets spoke utilisent la passerelle VPN ou ExpressRoute du hub. Pour accéder aux services PaaS via une adresse IP privée, Private Link crée un point de terminaison privé (une NIC dans votre sous-réseau) qui correspond à une instance de service spécifique telle qu’Azure Storage, SQL Database ou un service privé que vous publiez. Le trafic circule entièrement sur le réseau principal d’Azure, et le DNS est essentiel pour garantir que les clients résolvent l’adresse du point de terminaison privé. Le choix entre ces options dépend des exigences : VPN Gateway pour une connectivité chiffrée sur Internet, ExpressRoute pour des circuits privés haute performance, le VNet peering pour une connectivité privée intra-Azure, et Private Link pour un accès privé aux services PaaS ou partenaires sans exposer de points de terminaison publics.

• VPN Gateway
  • Couche de connectivité : L3 (IPsec/IKE)
  • Portée : Sur site <-> Azure ; VNet <-> VNet
  • Bande passante typique : De centaines de Mbps à plusieurs Gbps (par SKU)
  • Chiffrement : Oui (IPsec)
  • Points forts : Économique, flexible, P2S/S2S
  • Cas d’usage principaux : Extension hybride, dev/test, activation rapide
• ExpressRoute
  • Couche de connectivité : Circuit privé L3
  • Portée : Sur site <-> Azure (via partenaire)
  • Bande passante typique : 50 Mbps–100 Gbps (par circuit)
  • Chiffrement : Circuit privé (IPsec non requis)
  • Points forts : Latence prévisible, haut débit, SLA
  • Cas d’usage principaux : Hybride critique, réplication de données, conformité
• VNet Peering
  • Couche de connectivité : Réseau principal Azure
  • Portée : VNet <-> VNet (même région ou global)
  • Bande passante typique : Limitée par la NIC/l’hôte de la VM ; faible latence
  • Chiffrement : Non (réseau principal privé)
  • Points forts : Simple, rapide, support multi-locataire
  • Cas d’usage principaux : Hub-spoke, maillage de VNets régional/global
• Private Link
  • Couche de connectivité : Point de terminaison L7 via NIC privée
  • Portée : VNet client <-> Service PaaS/Privé
  • Bande passante typique : Dépend de l’application ; limitée par la NIC
  • Chiffrement : Isolation du réseau principal
  • Points forts : Élimine l’exposition publique, granulaire
  • Cas d’usage principaux : Accès privé à Storage, SQL, Key Vault, applications partenaires

Distribution et accélération du trafic : Load Balancer, Application Gateway, Front Door, Traffic Manager et CDN

Azure Load Balancer opère au niveau 4 pour TCP/UDP et fournit un équilibrage de charge haute performance et à faible latence au sein d’une région. Il prend en charge les scénarios entrants et sortants, les règles NAT entrantes et les sondes de santé (health probes). Le Standard Load Balancer est conscient des zones (zone-aware) et peut s’étendre sur plusieurs zones dans une région pour la résilience. C’est le bon choix pour les protocoles non-HTTP, les backends de jeux et les scénarios nécessitant des ports HA ou du SNAT pour la connectivité sortante à grande échelle via des règles de sortie ou une NAT Gateway. Application Gateway fournit un routage HTTP/HTTPS de niveau 7 avec des fonctionnalités telles que le routage basé sur le chemin d’URL et sur l’hôte, l’affinité de cookie et le déchargement SSL (SSL offload). Lorsqu’il est activé avec la SKU Web Application Firewall (WAF), il offre des ensembles de règles OWASP gérés pour aider à protéger contre les exploits et les bots courants. Application Gateway est un service régional et est souvent utilisé devant des VM Scale Sets, des conteneurs ou des App Services dans des configurations de réseau privé, en particulier lorsque un routage HTTP riche et une inspection WAF sont requis. Azure Front Door est un point d’entrée global de niveau 7, basé sur anycast, qui accélère et protège les applications web exposées sur Internet. Il fournit un équilibrage de charge global avec un basculement instantané, un routage intelligent (smart pathing) et un WAF intégré. Front Door Standard/Premium intègre des capacités de CDN pour l’accélération de contenu statique et dynamique en périphérie (at the edge), et peut avoir pour origine des Application Gateways, des App Services ou des comptes de stockage (Storage). Traffic Manager complète ces services en effectuant une distribution globale basée sur le DNS vers n’importe quel point de terminaison (HTTP ou non-HTTP), en utilisant des méthodes telles que le routage par priorité, par performance, pondéré, géographique, par sous-réseau et à valeurs multiples. Pour le déchargement de contenu statique, Azure CDN (y compris Front Door Standard/Premium ou Azure CDN from Microsoft/Verizon/Akamai) met en cache le contenu au plus près des utilisateurs, réduit la charge sur l’origine et améliore les performances. La combinaison de services est courante. Une conception typique exposée sur Internet utilise Azure Front Door avec WAF pour l’entrée globale (global ingress), avec pour origine des Application Gateways régionales (avec ou sans WAF) qui routent vers les charges de travail internes. Pour les protocoles autres que HTTP/HTTPS, associez Traffic Manager pour le basculement DNS avec des Load Balancers régionaux. Placez les adresses IP publiques uniquement sur ces services de périphérie gérés, en gardant les VM d’application privées.

• Azure Load Balancer
  • Couche : L4
  • Portée : Régionale
  • Protocoles : TCP/UDP
  • Support WAF : Non
  • Affinité de session : Non (au niveau L7)
  • Cas d’usage courants : Charges de travail non-HTTP, équilibrage de charge interne, SNAT sortant
• Application Gateway
  • Couche : L7
  • Portée : Régionale
  • Protocoles : HTTP/HTTPS
  • Support WAF : Oui (WAF v2)
  • Affinité de session : Oui (basée sur les cookies)
  • Cas d’usage courants : Applications web dans des VNets, déchargement SSL, routage par chemin/hôte
• Azure Front Door
  • Couche : L7
  • Portée : Globale
  • Protocoles : HTTP/HTTPS
  • Support WAF : Oui (WAF)
  • Affinité de session : Oui (cookie d’affinité)
  • Cas d’usage courants : Point d’entrée global, accélération en périphérie, basculement instantané
• Traffic Manager
  • Couche : DNS
  • Portée : Globale
  • Protocoles : Tous (basé sur le DNS)
  • Support WAF : Non
  • Affinité de session : Non
  • Cas d’usage courants : Basculement/distribution de charge inter-régions pour tout point de terminaison
• Azure CDN
  • Couche : Cache L7
  • Portée : Globale
  • Protocoles : HTTP/HTTPS
  • Support WAF : Non (utiliser le WAF de Front Door)
  • Affinité de session : S/O
  • Cas d’usage courants : Mise en cache de contenu statique, déchargement de l’origine, performance

Sécurité réseau et accès sécurisé : NSG, Azure Firewall, DDoS Protection, Bastion et Just-in-Time

Les groupes de sécurité réseau (NSG) appliquent un filtrage avec état (stateful) de couches 3/4 aux sous-réseaux et aux cartes réseau (NIC). Les règles autorisent ou refusent le trafic en fonction de paramètres 5-tuples, avec la prise en charge des étiquettes de service (service tags) et des groupes de sécurité d’application pour simplifier la gestion. Les NSG sont idéaux pour segmenter les niveaux (tiers), restreindre les ports de gestion et appliquer le moindre privilège entre les sous-réseaux. Ils sont rapides et distribués, mais ne fournissent pas de filtrage de couche applicative, de prévention des intrusions ou de DNAT/SNAT centralisé. Azure Firewall est un service de pare-feu et de sécurité réseau géré et avec état (stateful) qui fournit à la fois des règles réseau et des règles d’application (filtrage FQDN). La référence (SKU) Premium ajoute l’inspection TLS, l’IDPS et le filtrage d’URL. Il prend en charge le DNAT/SNAT, le filtrage basé sur le renseignement sur les menaces (threat intelligence) et s’intègre aux tables de routage pour un point de contrôle de sortie central dans les topologies en étoile (hub-and-spoke). Azure Firewall complète les NSG : les NSG appliquent une micro-segmentation est-ouest locale, tandis que le pare-feu applique des politiques centralisées nord-sud et de sortie Internet. Azure DDoS Protection est disponible en offres Basic et Standard. L’offre Basic est une protection au niveau de la plateforme, appliquée automatiquement aux services Azure sans configuration client. L’offre Standard ajoute un réglage adaptatif, la télémétrie, des alertes et une atténuation rapide pour les ressources avec des adresses IP publiques au sein d’un VNet protégé, ainsi que des crédits de protection des coûts lors d’attaques documentées. Pour l’accès administratif sans adresses IP publiques, Azure Bastion fournit un accès RDP/SSH sur TLS directement depuis le portail Azure (et les clients natifs pris en charge dans Bastion Standard), éliminant ainsi l’exposition entrante. L’accès aux machines virtuelles juste-à-temps (JIT), activé via Microsoft Defender for Cloud, maintient les ports de gestion fermés dans les NSG et n’ouvre l’accès que pour une durée limitée aux utilisateurs et adresses IP sources approuvés, minimisant ainsi la surface d’attaque tout en préservant l’accès opérationnel.

Problème pratique : Déploiement mondial pour la vente au détail de Contoso Outdoors : réseau sécurisé, privé et hautement disponible

Scénario : Contoso Outdoors lance une nouvelle plateforme de e-commerce basée sur des microservices fonctionnant sur Azure dans les régions East US et West Europe. L’entreprise doit maintenir toutes les VM d’application privées, fournir un accès administratif sécurisé et permettre aux partenaires de téléverser des fichiers d’inventaire vers Azure Storage sans passer par l’internet public. L’ERP sur site à Chicago nécessite une connectivité privée à faible latence vers les services de la région East US. Le front-end web doit être résilient à une défaillance régionale unique et protégé contre les exploits web courants et les attaques volumétriques.

Défi : Concevoir un réseau qui combine des espaces d’adressage privés, une connectivité hybride, une distribution HTTP mondiale, un accès privé au PaaS et une sécurité en couches sans exposer les adresses IP publiques des VM.

Approche recommandée :

1. Créer une architecture en étoile (hub-and-spoke) dans chaque région. Déployer un VNet hub avec l’espace d’adressage 10.0.0.0/16 et des spokes pour les niveaux web, applicatif et données en utilisant des sous-réseaux /24 non superposés. Associer des NSG à chaque sous-réseau pour appliquer le principe du moindre privilège entre les niveaux.
2. Déployer Azure Firewall Premium dans chaque hub. Configurer des UDR (User Defined Routes) dans les spokes pour router tout le trafic à destination d’Internet vers le pare-feu pour le contrôle de sortie (egress), l’inspection TLS et le filtrage basé sur le renseignement sur les menaces.
3. Établir une connectivité hybride depuis le datacenter de Chicago vers le hub East US avec ExpressRoute (peering privé). Activer des connexions doubles pour la redondance et BGP pour le routage dynamique. Utiliser temporairement un VPN de site à site comme solution de basculement si nécessaire.
4. Appairer les spokes régionaux à leurs VNets hub locaux en utilisant le VNet peering. Activer le transit de passerelle (gateway transit) pour que les spokes consomment la passerelle ExpressRoute/VPN du hub. Utiliser le VNet peering mondial pour connecter les hubs East US et West Europe pour le trafic du plan de contrôle et de réplication.
5. Publier le site de e-commerce avec Azure Front Door Premium et son WAF. Configurer deux origines : les Application Gateways des régions East US et West Europe. Activer les stratégies WAF gérées par Front Door et la protection contre les bots. Activer la mise en cache de Front Door pour les ressources statiques.
6. Dans chaque région, déployer Application Gateway WAF v2 dans le spoke web, assurant la terminaison TLS et le routage basé sur le chemin et l’hôte vers les pools backend (VM Scale Sets ou App Services) dans des sous-réseaux privés. Utiliser des Standard Load Balancers en interne pour les microservices non-HTTP.
7. Pour l’accès privé des partenaires et de service à service, créer des Private Endpoints vers Azure Storage et Azure SQL Database dans les spokes de données. Lier les zones Azure Private DNS appropriées à tous les spokes et hubs, et configurer le DNS sur site pour transférer les zones privatelink vers Azure pour une résolution de noms cohérente.
8. Protéger les surfaces exposées publiquement avec Azure DDoS Protection Standard en l’activant sur les VNets hub qui contiennent les ressources d’IP publiques pour les origines Application Gateway et Front Door. Surveiller les métriques d’attaque et configurer des alertes.
9. Fournir une administration sécurisée en déployant Azure Bastion Standard dans chaque VNet hub. Supprimer toutes les adresses IP publiques des VM. Activer l’accès Juste-à-temps (JIT) aux VM dans Defender for Cloud afin que l’accès RDP/SSH soit limité dans le temps et par la source lorsqu’il est tunnelisé via Bastion.
10. Instrumenter le réseau avec les journaux de flux NSG, les journaux Azure Firewall et les journaux d’accès de Front Door/Application Gateway vers Log Analytics. Configurer des sondes d’intégrité (health probes) et des tests synthétiques pour valider la disponibilité de bout en bout et le comportement de basculement.

Justification Azure : Cette conception maintient les plans applicatifs privés et contrôlés tout en présentant une périphérie mondiale renforcée. ExpressRoute fournit une connectivité privée et prévisible pour le système ERP, avec le VNet peering et le transit de passerelle étendant l’accès à tous les spokes. Azure Front Door avec son WAF assure la distribution HTTP mondiale, le basculement instantané et la sécurité en périphérie, tandis que les Application Gateways régionales gèrent le routage L7 et le WAF au plus près des charges de travail. Private Link élimine l’exposition publique pour Storage et SQL, soutenu par le DNS privé pour une résolution transparente depuis Azure et les environnements sur site. Les NSG appliquent la micro-segmentation ; Azure Firewall centralise la sortie (egress), le DNAT/SNAT et l’inspection avancée ; DDoS Protection Standard atténue les attaques volumétriques contre les points de terminaison publics. Azure Bastion et l’accès JIT fournissent un accès administratif sécurisé et auditable sans ouvrir de ports de gestion ni attribuer d’adresses IP publiques aux VM, répondant aux objectifs de sécurité et de conformité sans sacrifier l’opérabilité.

← Calcul et services d’application · Tous les domaines · Stockage et bases de données →

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

Parcourir Microsoft →