Microsoft AZ-305: Réseau et connectivité — Guide d'étude

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Solutions Architect Expert AZ-305 — 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.

Vue d’ensemble

Les conceptions de réseau et de connectivité dans Azure doivent équilibrer l’hygiène de l’espace d’adressage, l’accès sécurisé aux services PaaS, la connectivité hybride à grande échelle, la résolution de noms, la protection contre les menaces et l’observabilité approfondie. Une architecture robuste s’articule généralement autour d’un modèle de réseau virtuel en étoile (hub-and-spoke) ou d’un hub géré dans Azure Virtual WAN, avec un contrôle clair des routes, un accès privé aux services et un filtrage par pare-feu standardisé. Les sections suivantes détaillent les services et les capacités les plus fréquemment combinés dans les conceptions d’entreprise.

Réseaux virtuels, stratégie IP et accès privé aux services PaaS

Une planification robuste des adresses évite les remaniements et permet une mise à l’échelle hybride. Utilisez les plages RFC1918 avec des délimitations claires par environnement et par région. Évitez les préfixes qui se chevauchent entre les réseaux virtuels (VNets) et les réseaux sur site (on-prem) ; si des fusions ou une connectivité avec des partenaires sont probables, laissez une marge de manœuvre pour la sumarisation (par exemple, allouez un /16 par région et découpez des spokes en /20). Envisagez une double pile IPv4/IPv6 pour les applications exposées sur Internet et les régions réglementées. Conservez le GatewaySubnet à /27 ou plus si vous prévoyez une coexistence VPN/ExpressRoute et une mise à l’échelle future.

La conception des sous-réseaux segmente le trafic par fonction et par niveau de confiance. Chaque sous-réseau doit correspondre à une seule intention de sécurité, contrôlée par des NSG et des UDR. Dimensionnez correctement les préfixes (par exemple /26 à /24) pour éviter une renumérotation ; réservez des sous-réseaux distincts pour Azure Firewall, Application Gateway, Bastion et les Private Endpoints. Désactivez l’accès Internet sortant par défaut pour les sous-réseaux sensibles via une UDR vers un pare-feu.

Les points de terminaison de service (Service Endpoints) et les points de terminaison privés (Private Endpoints) sécurisent tous deux le trafic PaaS, mais avec un rayon d’impact et un routage différents :

Les Service Endpoints étendent l’identité de votre VNet aux services Azure sur le backbone Microsoft, tandis que le trafic cible toujours l’adresse IP publique du service. Vous pouvez verrouiller le service sur des VNets/sous-réseaux spécifiés et utiliser des stratégies de point de terminaison de service pour des listes d’autorisation granulaires de comptes de stockage. Ils sont simples à activer mais contrôlent l’accès au niveau du type de ressource ou du compte, plutôt que par carte réseau (NIC) d’instance.
Les Private Endpoints créent une carte réseau (NIC) avec une adresse IP privée dans votre sous-réseau, mappée à une ressource PaaS spécifique via Private Link. Cela fournit une isolation au niveau de l’instance et la protection la plus forte contre l’exfiltration de données, car le service n’est joignable que via l’adresse IP privée liée à votre ou vos points de terminaison. Planifiez soigneusement le DNS : surchargez les zones publiques (par exemple, privatelink.blob.core.windows.net, privatelink.database.windows.net) avec des zones Azure Private DNS liées à vos VNets ; les résolveurs sur site (on-prem) doivent transférer les requêtes vers Azure pour une résolution split-horizon. Private Link prend également en charge les scénarios consommateur/fournisseur inter-locataires (cross-tenant) avec des flux d’approbation, permettant un accès sécurisé pour les partenaires sans exposer de points de terminaison publics.

Connectivité hybride : VPN, ExpressRoute, Virtual WAN et contrôle des routes

Les références (SKU) d’Azure VPN Gateway définissent le débit et la mise à l’échelle. Utilisez des passerelles basées sur les routes (VpnGw1–VpnGw5 et leurs variantes redondantes interzones VpnGwXAZ) pour le site-à-site, le VNet-à-VNet et le BGP ; évitez la référence (SKU) Basic héritée pour la production. Le mode actif-actif déploie deux instances avec deux adresses IP publiques, augmentant la résilience et le débit agrégé. Le BGP avec des ASN privés permet un échange de routes dynamique, la convergence et un contrôle de chemin par tunnel (AS Path, MED) sur plusieurs liaisons. Azure utilise par défaut l’ASN 65515 sur la passerelle ; personnalisez-le en cas de connexion multihébergée (multihoming) à plusieurs fournisseurs.

ExpressRoute fournit une connectivité privée au backbone de Microsoft avec une latence prévisible et un débit élevé. Les références (SKU) de circuit déterminent la portée et les limites :

Local : sortie uniquement vers la même zone métropolitaine, coût inférieur, pas de connectivité VNet any-to-any au-delà de la zone métropolitaine.
Standard : connectivité aux régions Azure au sein de la même région géopolitique que le lieu de peering, limites de routes standard.
Premium : connectivité VNet globale au-delà des frontières géopolitiques et limites de routes/connexions plus élevées. Les types de peering incluent le peering privé (vers les VNets) et le peering Microsoft (vers les services SaaS/PaaS de Microsoft via des filtres de route). Le peering public est déprécié. ExpressRoute Global Reach vous permet de connecter des sites sur site (on-premises) via différents circuits ExpressRoute en utilisant le backbone de Microsoft. FastPath réduit la latence du plan de données en contournant la passerelle ExpressRoute pour les paquets entre votre périphérie et les VM ; il est activé par connexion VNet et pris en charge avec les passerelles ExpressRoute UltraPerformance ou ErGw3AZ sur le peering privé, avec le VNet directement attaché au circuit (sans transit par la passerelle).

La coexistence d’ExpressRoute et de VPN permet le basculement (failover) ou la répartition du trafic (split-traffic). Déployez les deux passerelles dans un GatewaySubnet de taille suffisante et utilisez BGP pour préférer ExpressRoute pour les préfixes qui se chevauchent (ExpressRoute a une préférence plus élevée que le VPN S2S lorsque les attributs de route sont égaux). Utilisez l’AS Path prepending ou les MED sur le VPN pour garantir un repli déterministe.

Azure Virtual WAN (vWAN) centralise la connectivité à grande échelle des succursales, des utilisateurs et des sites avec des hubs gérés. Choisissez le niveau Standard pour le routage inter-hub any-to-any et ExpressRoute ; activez un hub virtuel sécurisé lorsque vous avez besoin de l’intégration d’Azure Firewall. Les intentions de routage dans les hubs sécurisés dirigent les classes de trafic — Internet, Privé et Microsoft — vers les services de sécurité (par exemple, tout le trafic à destination d’Internet et le trafic Privé vers Azure Firewall Premium). vWAN simplifie l’intégration SD-WAN, l’automatisation des partenaires et les VPN P2S/S2S à grande échelle tout en fournissant des politiques cohérentes au niveau mondial.

Azure Route Server (ARS) injecte un routage dynamique dans un VNet hub-and-spoke classique sans déployer de NVA en tant que réflecteurs de route. ARS établit un peering BGP avec les NVA, partage les routes apprises avec le VNet et, avec l’échange de routes activé, peut propager les routes entre les NVA et la passerelle VPN/ExpressRoute. Cela supprime la maintenance manuelle des UDR pour les préfixes appris depuis l’environnement sur site (on-prem) ou annoncés par les NVA. ARS utilise l’ASN 65515 par défaut et prend en charge le filtrage des routes via des route maps pour contrôler l’annonce et prévenir les fuites de routes.

Résolution de noms, pare-feu et protection DDoS

Azure DNS fournit un hébergement faisant autorité pour les zones publiques et privées. Les zones publiques sont publiées sur Internet avec l’anycast mondial d’Azure. Les zones DNS privées offrent une résolution de noms « split-horizon » pour les ressources accessibles uniquement au sein des VNets liés. Activez l’enregistrement automatique sur un lien de zone DNS privée pour enregistrer et mettre à jour dynamiquement les enregistrements A des machines virtuelles Azure dans ce VNet, simplifiant ainsi les opérations de cycle de vie.

Azure DNS Private Resolver fournit un service managé de redirection DNS entrante et sortante. Déployez des points de terminaison entrants pour recevoir les requêtes des résolveurs sur site (on-prem) via une IP privée, et des points de terminaison sortants ainsi que des ensembles de règles (rulesets) pour transférer les requêtes des VM Azure vers le DNS sur site pour les zones d’entreprise. Liez les ensembles de règles à plusieurs VNets pour standardiser la résolution dans une topologie hub-spoke. C’est le point d’ancrage pour la résolution de noms des Private Endpoints depuis l’environnement sur site, permettant aux redirecteurs conditionnels sur site d’atteindre les zones DNS privées d’Azure via le résolveur.

Azure Firewall centralise le filtrage du trafic sortant (egress), entrant (DNAT) et est-ouest. La référence (SKU) Standard fournit un filtrage L3-L4, des étiquettes FQDN et un filtrage basé sur le renseignement sur les menaces (threat intelligence). La référence Premium ajoute l’inspection TLS (sortante et entrante avec des certificats stockés dans Key Vault), un IDPS avec détection/prévention basée sur les signatures, et le filtrage d’URL avec des catégories et des stratégies au niveau du chemin (path). Déployez-le dans un hub virtuel sécurisé pour vWAN ou en tant qu’instance de pare-feu dans un VNet hub. Utilisez des stratégies de pare-feu gérées dans Azure Firewall Manager avec une hiérarchie de stratégies parent/enfant pour appliquer des bases de référence globales et des règles régionales ou spécifiques à une application ; les priorités des groupes de collections de règles déterminent l’ordre d’évaluation. Planifiez les ports SNAT avec plusieurs adresses IP publiques sur les hubs à haut débit pour éviter l’épuisement des ports lorsque de nombreuses connexions éphémères sont attendues.

Azure DDoS Protection protège les ressources à adresse IP publique. Le niveau Basic est toujours actif et géré par la plateforme. Le niveau Standard est un plan que vous activez par VNet ; il ajuste automatiquement les stratégies d’atténuation pour chaque IP publique protégée (Load Balancer, Application Gateway, cartes réseau de VM), fournit une protection des coûts pendant les attaques et expose la télémétrie. Configurez les alertes et la diffusion en continu (streaming) vers Log Analytics pour recevoir des rapports d’atténuation, des métriques d’attaque (pps/bps, vecteurs) et un support rapide via DDoS Rapid Response. Combinez-le avec un WAF et une limitation de débit (rate-limiting) pour une résilience au niveau L7.

Observabilité et analyse du trafic

Azure Network Watcher offre une visibilité approfondie sur la santé et le trafic du réseau. Connection Monitor teste en continu la joignabilité et la performance entre des sources et des destinations (VM Azure, points de terminaison sur site, URL) via ICMP, TCP ou HTTP/S, en corrélant les changements d’état de la topologie avec les pannes. Les journaux de flux NSG (NSG Flow Logs) enregistrent les flux 5-tuple et la décision (autoriser/refuser) au niveau des interfaces NSG ; exportez-les vers un compte de stockage et activez Traffic Analytics dans Log Analytics pour obtenir des informations sur les principaux communicateurs (top talkers), les ports ouverts et les détections de menaces. Packet Capture effectue une capture de paquets sur la carte réseau d’une VM à l’aide d’une extension, à la demande ou de manière planifiée, avec des filtres pour les expressions de type BPF et une sortie vers le stockage ; utilisez-le pour dépanner les problèmes de MTU, de handshake ou de routage asymétrique. Associez ces outils aux métriques d’Azure Monitor pour les passerelles, les circuits ExpressRoute et les hubs vWAN afin de détecter la saturation, l’instabilité BGP (BGP flap) ou la perte de résilience.

Scénarios Private Link inter-locataires et nuances DNS

Private Link permet des modèles consommateur-fournisseur sécurisés entre les locataires. Le fournisseur expose un service Private Link ou une ressource PaaS ; le consommateur crée un Private Endpoint et demande une approbation. Pour le PaaS, l’approbation se fait au niveau de l’instance de ressource, offrant un contrôle strict du rayon d’impact. Le DNS doit résoudre le FQDN public du service vers l’adresse IP du Private Endpoint du consommateur. Dans le locataire du consommateur, créez ou utilisez la zone privatelink.<zone> appropriée et liez-la au VNet consommateur ; pour les utilisateurs sur site (on-prem), transférez ces zones vers les points de terminaison entrants d’Azure DNS Private Resolver. Lorsque les fournisseurs exigent des domaines personnalisés (vanity domains), utilisez des CNAME vers le nom du point de terminaison public afin que les substitutions split-horizon fonctionnent de manière transparente. Validez qu’il n’existe pas de Private Endpoints qui se chevauchent pour le même FQDN dans différents VNets sans une portée intentionnelle, car les clients résolvent vers la zone liée la plus proche en fonction du chemin de la requête DNS.

Scénario de problème pratique

Siemens AG construit une plateforme de fabrication mondiale dans Azure, avec des usines régionales se connectant via MPLS et Internet. Les exigences incluent un accès privé à Azure SQL et Storage, une connectivité hybride résiliente qui privilégie le réseau principal (backbone) privé, une inspection de sécurité centralisée avec déchiffrement TLS et IDPS, une résolution DNS standardisée depuis les usines vers les Private Endpoints Azure, et une surveillance approfondie de la connectivité. Des partenaires dans un locataire Azure distinct doivent consommer en privé une sélection d’API hébergées par Siemens.

Implémentez une topologie hub-and-spoke par région avec un hub virtuel sécurisé dans Azure Virtual WAN Standard.

Pourquoi : vWAN fournit une connectivité S2S/P2S/ER gérée et évolutive, ainsi qu’un routage any-to-any entre les hubs. Un hub sécurisé intègre Azure Firewall Premium avec des intentions de routage (routing intents) pour diriger le trafic Internet et privé vers l’inspection à l’échelle mondiale.

Établissez des circuits ExpressRoute avec la référence (SKU) Premium en Europe et en Amérique du Nord ; activez Global Reach entre eux. Déployez des passerelles ExpressRoute UltraPerformance ou ErGw3AZ et activez FastPath pour les VNets directement connectés aux circuits.

Pourquoi : La référence Premium permet une connectivité inter-géopolitique pour les VNets et des limites de routes plus élevées ; Global Reach fournit une connectivité privée de site à site (on-prem to on-prem) sur le réseau principal de Microsoft. FastPath réduit la latence et les goulots d’étranglement de la passerelle pour le trafic du plan de données (data-plane).

Ajoutez des passerelles Azure VPN Gateways (VpnGw5AZ) en mode actif-actif dans chaque région comme solution de secours pour ExpressRoute ; configurez BGP avec l’ajout au chemin AS (AS Path prepending) sur le VPN pour privilégier ExpressRoute.

Pourquoi : Le mode actif-actif combiné à BGP offre un basculement résilient. Les attributs de chemin (Path attributes) imposent un routage déterministe afin qu’ExpressRoute soit toujours le chemin principal.

Déployez Azure Firewall Premium dans chaque hub sécurisé avec des stratégies de pare-feu parent/enfant via Azure Firewall Manager ; activez l’inspection TLS et l’IDPS ; allouez plusieurs adresses IP publiques pour la mise à l’échelle du SNAT.

Pourquoi : Une sécurité centralisée et uniforme avec déchiffrement et prévention des menaces basée sur les signatures répond aux exigences d’inspection à grande échelle. La hiérarchie des stratégies impose une base de référence mondiale tout en autorisant des variations régionales.

Utilisez des Private Endpoints pour Azure SQL Database et Storage ; créez des zones DNS privées Azure pour privatelink.database.windows.net et privatelink.blob.core.windows.net, liez-les aux spokes, et activez Azure DNS Private Resolver dans le hub avec des points de terminaison entrants et sortants et des ensembles de règles de transfert (forwarding rulesets).

Pourquoi : Les Private Endpoints fournissent une isolation au niveau de l’instance et éliminent le risque d’exfiltration de données. DNS Private Resolver standardise la résolution de noms split-horizon pour les réseaux Azure et ceux des usines sans nécessiter d’appliances DNS personnalisées.

Les serveurs DNS sur site (on-prem) transfèrent les zones Azure Private Link vers le point de terminaison entrant du résolveur ; pour les zones d’entreprise nécessaires dans Azure, créez des règles sortantes vers les DNS sur site.

Pourquoi : Ce transfert bidirectionnel assure une résolution de noms cohérente à travers les frontières avec une administration minimale.

Pour l’accès des partenaires, exposez les API Siemens derrière un équilibreur de charge interne et publiez-les via un service Private Link ; les partenaires dans leur propre locataire créent des Private Endpoints et obtiennent une approbation. Fournissez des instructions DNS spécifiques aux partenaires pour substituer les noms publics par les adresses IP de leurs Private Endpoints.

Pourquoi : Le Private Link inter-locataires fournit un accès privé, limité à l’instance, sans exposer de points de terminaison publics ni gérer d’identités invitées.

Déployez Azure Route Server dans les VNets du hub qui hébergent des NVA (appliances virtuelles réseau) pour le routage spécialisé, et activez l’échange de routes avec la passerelle ExpressRoute.

Pourquoi : Route Server orchestre le partage dynamique des routes entre les NVA et les passerelles, éliminant les mises à jour fragiles des UDR (routes définies par l’utilisateur) et assurant une convergence rapide.

Activez Azure DDoS Protection Standard sur les VNets du hub protégeant les adresses IP publiques (Azure Firewall et points de terminaison entrants) ; configurez des alertes et intégrez-les avec Log Analytics.

Pourquoi : L’atténuation automatique et ajustée des couches L3/L4, avec télémétrie et support, réduit les risques et offre une visibilité sur les attaques avec une protection des coûts.

Activez Azure Network Watcher Connection Monitor pour les chemins clés (usine vers Azure SQL via ER, VM Azure vers Storage via Private Endpoint), les journaux de flux NSG (NSG Flow Logs) avec Traffic Analytics sur les sous-réseaux des spokes, et la capture de paquets à la demande (on-demand Packet Capture) sur les VM critiques.

Pourquoi : Les tests de joignabilité en continu, l’établissement de bases de référence du trafic (baselining) et l’analyse forensique au niveau des paquets donnent aux équipes opérationnelles la visibilité nécessaire pour diagnostiquer rapidement les anomalies de performance et de routage.

← Calcul et architecture applicative · Tous les domaines · Haute disponibilité →

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