Azure réseaux virtuels et sous-réseaux

Azure réseaux virtuels et sous-réseaux sont les blocs de construction fondamentaux de chaque réseau Azure. Cet article explique comment les réseaux virtuels fournissent une isolation, comment les sous-réseaux organisent les ressources et comment dimensionner et structurer votre réseau pour les charges de travail de production.

Présentation de cet article

Cet article traite des limites d’isolation du réseau virtuel, du dimensionnement des sous-réseaux et des adresses réservées, des sous-réseaux de plateforme dédiée pour les services tels que Pare-feu Azure et Application Gateway, le peering de réseaux virtuels et les modèles de disposition réseau courants.

Qui a besoin de cet article

Lisez cet article si vous :

  • Déployez votre première charge de travail sur Azure et devez comprendre le fonctionnement de la mise en réseau avant de créer des ressources.
  • Planifiez un environnement à plusieurs charges de travail et devez décider du nombre de réseaux virtuels et de sous-réseaux à créer.
  • Vous migrez des charges de travail sur site vers Azure et avez besoin de comprendre en quoi le réseau Azure diffère du réseau physique.
  • Vous devez dimensionner correctement les sous-réseaux pour Azure services de plateforme tels que Pare-feu Azure, passerelle VPN ou Azure Kubernetes Service (AKS).
  • Vous souhaitez comprendre quand il faut séparer les charges de travail dans différents VNets ou les conserver dans le même VNet.

Priorité au lift-and-shift : reproduisez la segmentation de vos sous-réseaux locaux dans Azure. Associez les VLAN existants et les zones de sécurité aux sous-réseaux, maintenez des espaces d’adressage cohérents avec les plages que votre équipe utilise déjà et dimensionnez généreusement les sous-réseaux afin d’éviter de devoir renuméroter l’adressage lors de la migration.

Moderniser le focus : Concevoir des sous-réseaux autour des services de plateforme et de l’automatisation. Dimensionnez correctement les sous-réseaux pour AKS, les points de terminaison privés et les services de plateforme dédiés, et prévoyez Azure Virtual Network Manager pour appliquer une configuration cohérente sur de nombreux réseaux virtuels.

Priorité au multicloud : Planifiez des plages d’adresses qui ne se chevauchent pas entre Azure, AWS et Google Cloud avant de créer un VNet. Réservez des plages CIDR qui n’entrent pas en conflit avec les VPC existants afin de pouvoir interconnecter des clouds par peering ou via VPN sans NAT.

Azure services et fonctionnalités

Les services et fonctionnalités suivants constituent la base de mise en réseau virtuelle dans Azure :

Service ou fonctionnalité Ce qu’il fournit Quand l′utiliser ?
Réseau virtuel Azure (réseau virtuel) Un réseau privé isolé dans Azure. Toute la mise en réseau dans Azure commence ici. Les ressources du même réseau virtuel peuvent communiquer par défaut ; les ressources dans différents réseaux virtuels ne peuvent pas communiquer, sauf si vous les connectez explicitement. Toujours : chaque charge de travail nécessitant une connectivité réseau nécessite un réseau virtuel.
Sous-réseau Partition de l’espace d’adressage du réseau virtuel. Les sous-réseaux constituent le périmètre d’association des groupes de sécurité réseau (NSG) et des tables de routage. Toujours : organisez les composants de charge de travail en sous-réseaux par fonction ou limite de sécurité.
Peering de réseaux virtuels Faible latence, connectivité privée entre deux réseaux virtuels dans la même région ou entre les régions. Le trafic reste sur le réseau principal de Microsoft. Le peering n’est pas transitif ; chaque peering est un lien direct. Lorsque les ressources dans des réseaux virtuels distincts doivent communiquer. Pour le peering interrégional, consultez Connectivité interrégionale.
Peering de sous-réseaux (préversion) Peering entre des sous-réseaux spécifiques plutôt qu'entre des réseaux virtuels entiers. Fournit un contrôle granulaire sur les sous-réseaux qui participent aux relations de peering. Lorsque vous avez besoin d’un contrôle de peering affiné entre des sous-réseaux spécifiques dans différents réseaux virtuels. Consultez la section contraintes .
Table de routage / Itinéraires définis par l’utilisateur (UDR) Remplacez les itinéraires système par défaut dans Azure pour contrôler où le trafic est envoyé. Appliqué au niveau du sous-réseau. Lorsque vous devez forcer le trafic via un pare-feu ou une appliance virtuelle réseau (NVA). Requis pour le contrôle du trafic de sortie dans une architecture hub-and-spoke. Consultez la conception d’Pare-feu Azure et la topologie en étoile (hub-and-spoke).
Azure Virtual Network Manager (AVNM) Créez, gérez et appliquez de façon centralisée des configurations réseau aux VNets sur plusieurs abonnements. Lors de la gestion de nombreux VNets répartis sur plusieurs abonnements. Consultez la gestion centralisée du réseau.

Diagramme montrant le réseau virtuel avec des sous-réseaux de charge de travail pour les niveaux web, d’application et de données, ainsi que les sous-réseaux de plateforme dédiés pour la passerelle, le pare-feu et Bastion

Comment choisir

Qu’est-ce qu’un réseau virtuel ?

Un réseau virtuel (VNet) est un réseau isolé défini par logiciel dans Azure. Considérez-le comme votre réseau privé dans Azure. Contrairement à un réseau physique qui utilise des câbles, des commutateurs et des routeurs, un réseau virtuel est entièrement défini par logiciel. Vous la créez, affectez-lui un espace d’adressage et déployez des ressources dans celle-ci.

Principales caractéristiques :

  • Limité à une région : Un VNet existe dans une seule région Azure. Toutes les ressources de ce réseau virtuel doivent se trouver dans la même région. Un réseau virtuel couvre les zones de disponibilité de cette région.
  • Isolation par défaut : les ressources d’un réseau virtuel ne peuvent pas communiquer avec les ressources d’un autre réseau virtuel, sauf si vous créez explicitement une connexion (peering ou VPN).
  • Connectivité interne par défaut : les ressources au sein du même réseau virtuel peuvent communiquer entre elles par défaut par le biais d’itinéraires système qui Azure fournit.

Qu’est-ce qu’un sous-réseau ?

Un sous-réseau est une plage d’adresses IP au sein de votre réseau virtuel. Les sous-réseaux vous permettent de :

  • Segmentez votre réseau par composant de charge de travail (par exemple, la couche Web, la couche Application, la couche Données).
  • Appliquer des règles de sécurité : Les NSG s’appliquent au niveau du sous-réseau pour filtrer le trafic.
  • Contrôle du routage : les tables de routage sont associées au niveau du sous-réseau pour diriger le trafic.

Azure réserve cinq adresses IP dans chaque sous-réseau : les quatre premières adresses et la dernière adresse. Par exemple, dans un sous-réseau /24 (256 adresses), seuls 251 sont utilisables. Tenez compte de cette réserve dans vos calculs de dimensionnement.

Exemple : application à trois niveaux

Une application web classique à trois niveaux utilise trois sous-réseaux pour séparer les préoccupations et appliquer des règles de sécurité distinctes :

Sous-réseau Plage CIDR Objectif Exemples de ressources
web-subnet 10.0.1.0/24 Serveurs web frontaux qui acceptent le trafic HTTP/HTTPS entrant à partir d’Internet ou d’Application Gateway Azure App Service Environment, Virtual Machine Scale Sets exécutant NGINX
app-subnet 10.0.2.0/24 Logique d’application de niveau intermédiaire. Accepte le trafic uniquement à partir du sous-réseau web. Azure Functions (intégrée au réseau virtuel), machines virtuelles exécutant la logique métier
data-subnet 10.0.3.0/24 Magasins de données. Accepte le trafic uniquement à partir du sous-réseau de l’application. Aucun accès direct à Internet. Azure SQL Managed Instance, points de terminaison privés pour Azure SQL Database ou Cosmos DB

Cette disposition vous permet d’appliquer un groupe de sécurité réseau à chaque sous-réseau qui limite le trafic uniquement à ce dont ce niveau a besoin. Le sous-réseau web autorise le protocole HTTPS entrant (port 443). Le sous-réseau d’application autorise le trafic entrant uniquement à partir de la plage d’adresses IP du sous-réseau web. Le sous-réseau de données autorise le trafic entrant uniquement à partir de la plage d’adresses IP du sous-réseau d’application.

Pour un modèle de modernisation basé sur AKS, vous pouvez utiliser un sous-réseau aks-nodes, tel que 10.0.4.0/24, pour les groupes de nœuds du cluster lorsque vous déployez Azure CNI Overlay. Dans ce modèle, seuls les nœuds consomment des adresses IP de réseau virtuel à partir du sous-réseau. Les pods utilisent un CIDR de superposition distinct, ce qui vous permet de conserver le sous-réseau de nœud plus petit qu’une conception AKS à réseau plat.

Modèles courants

Les dispositions de sous-réseau suivantes couvrent les scénarios de déploiement Azure les plus courants :

Modèle Sous-réseaux Quand utiliser
Application web simple web + data Applications à deux niveaux avec un serveur frontal et une base de données. Complexité minimale.
Entreprise à trois niveaux web + app + data + management Charges de travail d'entreprise traditionnelles comportant des niveaux distincts ainsi qu'un sous-réseau de jump box ou Bastion pour l'administration.
AKS avec des services partagés aks-nodes + aks-ingress + appgw + shared Charges de travail Kubernetes avec un sous-réseau dédié au contrôleur d'entrée et Application Gateway pour le WAF.
Trafic de sortie hub-and-spoke AzureFirewallSubnet + GatewaySubnet + AzureBastionSubnet + management Le réseau virtuel hub dans une topologie hub-and-spoke. Services partagés via lesquels les réseaux virtuels spoke acheminent leur trafic. Consultez la topologie hub-and-spoke.
Charge de travail de données compute + data + private-endpoints + management Les charges de travail d’analyse et de plateforme de données où les points de terminaison privés pour le stockage et les bases de données ont besoin de leur propre sous-réseau pour la clarté de la planification IP.

Combien de réseaux virtuels et de sous-réseaux ?

Le principe de guiding est simple : utilisez un réseau virtuel par application et un sous-réseau par composant (niveau). Cette valeur par défaut conserve chaque charge de travail isolée, facilite le contrôle du trafic entre les niveaux avec les groupes de sécurité réseau et laisse la place à la croissance. Ajustez à partir de là en fonction des services partagés, des exigences d’isolation et de la mise à l’échelle.

Utilisez cette table de décision pour déterminer votre stratégie de réseau virtuel et de sous-réseau :

Votre situation Approche recommandée
Charge de travail unique, équipe unique, aucun service partagé n’est nécessaire Un réseau virtuel avec des sous-réseaux par composant d’application (web, logique d’application, données). Consultez la topologie à charge de travail unique.
Plusieurs charges de travail indépendantes qui partagent une passerelle ou un pare-feu Un réseau virtuel hub pour les services partagés + un réseau virtuel spoke par charge de travail. Consultez Topologie hub-and-spoke.
Isolation stricte entre les charges de travail (rayon d’explosion, exigences de conformité) Un réseau virtuel par charge de travail sans peering entre eux.
Environnement de très grande taille avec de nombreux abonnements et régions Azure Virtual WAN avec la gestion automatisée du hub. Consultez Virtual WAN topologie.

Informations de référence sur le dimensionnement de sous-réseau dédié

De nombreux services de plateforme Azure nécessitent leur propre sous-réseau dédié avec un nom et une taille minimale spécifiques. Le schéma suivant montre les règles de nommage et les tailles minimales pour les sous-réseaux dédiés de la plateforme :

Diagramme montrant les tailles de sous-réseau minimales pour cinq sous-réseaux de plateforme dédiés, notamment la passerelle, le pare-feu, Bastion et le serveur de routage

Utilisez ce tableau lors de la planification de votre espace d’adressage :

Service d'Azure Taille minimale du sous-réseau Nom de sous-réseau requis Remarques
Pare-feu Azure /26 (59 adresses IP utilisables) AzureFirewallSubnet Obligatoire pour toutes les références SKU de pare-feu. Consultez la conception d’Pare-feu Azure.
passerelle VPN /27 (27 adresses IP utilisables) GatewaySubnet Microsoft recommande un /27 ou plus grand afin de disposer d'une marge pour la montée en charge.
Azure Bastion /26 (59 adresses IP utilisables) AzureBastionSubnet Minimum /26 pour tous les déploiements créés après novembre 2021.
Application Gateway v2 /24 recommandé (251 adresses IP utilisables) Aucun nom obligatoire Un /24 est fortement recommandé afin de prendre en charge la mise à l’échelle automatique. Le minimum est calculé selon la formule (instances + 5 adresses réservées + 1 adresse IP frontend privée).
Environnement de service d'application /24 (production), /23 (échelle maximale) Aucun nom obligatoire La mise à l’échelle consomme des adresses IP à partir du sous-réseau. Utilisez /23 si vous prévoyez de monter en charge à l’approche de la limite maximale de 200 instances.
Serveur de routes Azure /26 (59 adresses IP utilisables) RouteServerSubnet Requis pour l'échange d'itinéraires BGP avec les NVA.
Programme de résolution privé Azure DNS /28 minimum par sous-réseau de point de terminaison Sous-réseaux entrants et sortants dédiés Nécessite des sous-réseaux distincts pour les points de terminaison entrants et sortants. Impossible de partager avec d’autres ressources.
AKS (Azure Kubernetes Service) Basé sur des formules (dépendant de CNI) Aucun nom obligatoire Consultez les conseils de dimensionnement AKS.

Note

Les points de terminaison privés consomment des adresses IP à partir de sous-réseaux existants. Ils ne nécessitent pas de sous-réseau dédié. Facteurz cette consommation d’adresses IP dans le dimensionnement de votre sous-réseau. Pour une planification détaillée des adresses IP, consultez la planification des adresses IP.

Dimensionnement du sous-réseau AKS

Le dimensionnement du sous-réseau AKS dépend de votre choix de plug-in CNI (Container Networking Interface). Il n’existe aucune taille minimale unique :

  • Azure CNI Overlay : le sous-réseau n’a besoin de pouvoir accueillir que les nœuds, car les pods utilisent un bloc CIDR privé distinct (routage interdomaine sans classe). Un sous-réseau nettement plus petit est acceptable par rapport à la mise en réseau plate.
  • Azure CNI (réseau plat) : le sous-réseau doit prendre en charge les deux nœuds ET les pods. Formule : (nodes + surge) × (max_pods + 1). Un /21 ou plus est courant pour les clusters avec 50 nœuds ou plus.
  • Kubenet : seuls les nœuds consomment des adresses IP de sous-réseau de réseau virtuel. Les pods obtiennent des adresses IP internes de cluster.

Pour connaître les formules de dimensionnement par option CNI, consultez Planifier l’adressage IP de votre cluster AKS.

Contraintes du peering de sous-réseaux

Le peering de sous-réseaux connecte des sous-réseaux spécifiques entre des VNets au lieu d’espaces d’adressage entiers. Cette approche fournit un contrôle granulaire sur les sous-réseaux qui participent aux relations de peering.

Important

Le peering de sous-réseaux est actuellement en préversion et présente les contraintes suivantes :

  • Nécessite l’ajout d’un abonnement à une liste approuvée (pas l’inscription en libre-service)
  • CLI, modèle ARM, Terraform ou PowerShell uniquement (aucune prise en charge du portail)
  • Les références SKU V5 basées sur Intel (ou AMD Gênes/Cobalt 100) sont requises pour une utilisation en production afin d’éviter un bogue connu sur les références SKU de ancienne génération : consultez Configurer le peering de sous-réseaux pour connaître les exigences matérielles actuelles
  • 200 sous-réseaux maximum par côté et par lien de peering
  • Maximum de 1 000 sous-réseaux totaux sur tous les liens de peering par réseau virtuel
  • Les sous-réseaux doivent appartenir à des espaces d’adressage uniques et sans chevauchement

Pour connaître les limitations et l’inscription actuelles, consultez Configurer le peering de sous-réseaux.

Note

Azure Virtual Network Manager (AVNM) ne peut pas distinguer le peering de sous-réseaux du peering de réseaux virtuels. Si vous utilisez AVNM pour gérer les configurations d’appairage, sachez que les relations d’appairage au niveau du sous-réseau apparaissent comme un appairage VNet standard dans AVNM.

Considérations relatives à la conception

Priorité de conception des réseaux virtuels et sous-réseaux pour le lift-and-shift

  • Recréez votre segmentation locale : mappez chaque réseau local virtuel ou zone de sécurité à un sous-réseau afin que les limites de pare-feu existantes et la propriété opérationnelle soient conservées avec une nouvelle conception minimale.
  • Dimensionnez les sous-réseaux en prévoyant une marge de capacité. La réécriture après la migration est perturbatrice. Par conséquent, allouez des plages CIDR plus importantes que votre nombre actuel d'hôtes pour absorber la croissance et les cinq adresses réservées de Azure par sous-réseau.
  • Conservez les espaces d’adressage Azure alignés sur les plages d’adresses locales lorsque cela est possible afin de simplifier le routage et d’éviter les chevauchements lors de la connexion via passerelle VPN ou ExpressRoute.
  • La valeur par défaut est d’un réseau virtuel par application migrée avec un sous-réseau par niveau. Cette conception reflète les dispositions locales classiques à trois niveaux et maintient le déplacement prévisible.

Moderniser le focus de conception du réseau virtuel et du sous-réseau

  • Concevoir d’abord des sous-réseaux autour des services de plateforme : sous-réseaux dédiés pour Pare-feu Azure, Application Gateway et Bastion, ainsi que les sous-réseaux correctement dimensionnés pour AKS en fonction de votre choix CNI.
  • Utilisez Azure CNI Overlay pour AKS afin de conserver des sous-réseaux de nœuds de petite taille, car les pods utilisent une plage CIDR de superposition distincte plutôt que l’espace d’adressage du réseau virtuel.
  • Réservez un sous-réseau dédié pour les points de terminaison privés afin que la consommation d’adresses IP reste prévisible lorsque vous adoptez davantage de services PaaS Azure.
  • Adoptez Azure Virtual Network Manager tôt pour appliquer des groupes réseau, une connectivité et des configurations de sécurité de manière cohérente à mesure que votre nombre de réseaux virtuels augmente dans les abonnements.

Accent sur la conception des VNets et des sous-réseaux en environnement multicloud

  • Établissez un plan d’adresse globale avant de créer un réseau virtuel. Réservez pour Azure des blocs CIDR qui ne se chevauchent pas et n’entrent pas en conflit avec les VPC AWS existants ni avec les réseaux VPC Google Cloud. Cette réservation est obligatoire pour le VPN routé ou l’interconnexion.
  • Mappez les primitives réseau de chaque cloud à Azure : un réseau AWS VPC ou Google Cloud VPC correspond à un réseau virtuel Azure, et les groupes de sécurité correspondent aux groupes de sécurité réseau.
  • Réservez de l’espace de sous-réseau pour les composants de connectivité entre les clouds, tels qu’un GatewaySubnet pour passerelle VPN ou le hub utilisé par Azure Virtual WAN, afin que l’infrastructure de transit dispose d’une capacité d’échelle.
  • Normaliser le nommage et le balisage de sous-réseau entre les clouds afin que les équipes d’opérations puissent mettre en corrélation des niveaux équivalents lorsqu’elles résolvent le trafic multicloud.

Prerequisites

Avant de concevoir la disposition de votre réseau virtuel et de votre sous-réseau, vérifiez que vous disposez des éléments suivants :

  • abonnement Azure : un abonnement actif Azure disposant des autorisations nécessaires pour créer des ressources réseau (rôle Contributeur réseau ou version ultérieure).
  • Groupe de ressources : groupe de ressources dans votre région cible pour contenir des ressources de réseau virtuel.
  • Décision de la région : choisissez votre région principale Azure en fonction de la proximité des utilisateurs, des exigences de conformité et de la disponibilité du service.
  • Plan de l’espace d’adressage : déterminez une plage d’adresses IP (bloc CIDR) qui ne chevauche pas vos réseaux sur site ni les autres réseaux virtuels que vous envisagez d’appairer. Consultez la planification des adresses IP pour obtenir des conseils.

Considérations relatives à la sécurité

Les réseaux virtuels et les sous-réseaux sont votre première couche de segmentation du réseau. Appliquez les pratiques de sécurité suivantes :

  • Groupes de sécurité réseau (NSG) : associez des groupes de sécurité réseau à chaque sous-réseau pour filtrer le trafic entrant et sortant. Définissez les règles d’autorisation spécifiques au rôle de chaque sous-réseau et refusez tout le reste par défaut. Pour obtenir des instructions détaillées, consultez groupes de sécurité réseau et groupes de sécurité d’application.
  • Tunneling forcé avec des UDR : si vos exigences de conformité imposent que tout le trafic lié à Internet passe par un appareil d’inspection local ou un pare-feu cloud, utilisez des tables de routage avec des itinéraires définis par l’utilisateur pour remplacer le routage Internet par défaut. Consultez la connectivité sortante et de sortie.
  • Isolation du sous-réseau : placez des ressources avec différents niveaux d’approbation dans des sous-réseaux distincts. Par exemple, conservez des bases de données dans un sous-réseau qui autorise uniquement le trafic entrant à partir du sous-réseau de la couche Application. Cette séparation limite le mouvement latéral si un attaquant compromet un composant.
  • Sous-réseaux dédiés pour les services de plateforme : de nombreux services de plateforme Azure (Pare-feu Azure, Application Gateway, Bastion) sont déployés dans des sous-réseaux dédiés. Cette isolation garantit que le routage des services de plateforme et les règles de sécurité n’interfèrent pas avec vos sous-réseaux de charge de travail.

Interaction entre NSG et sous-réseau

Lorsque vous associez un groupe de sécurité réseau à un sous-réseau, les règles de groupe de sécurité réseau s’appliquent à toutes les ressources de ce sous-réseau. Comprendre ces comportements d’interaction :

  • Évaluation cumulative : si la carte réseau d'une machine virtuelle possède également un groupe de sécurité réseau, Azure évalue à la fois le groupe de sécurité réseau au niveau du sous-réseau et le groupe de sécurité réseau au niveau de la carte réseau. Pour le trafic entrant, Azure évalue d'abord le groupe de sécurité réseau du sous-réseau, puis celui de l'interface réseau. Pour le trafic sortant, Azure évalue d’abord le NSG de la carte d’interface réseau, puis le NSG du sous-réseau.
  • Refus par défaut : Azure inclut des règles par défaut qui autorisent le trafic intra-réseau virtuel et l’accès Internet sortant. Après avoir ajouté des règles de refus personnalisées, vérifiez que le trafic légitime (par exemple, les sondes d’intégrité d’Azure Load Balancer provenant de l’adresse IP 168.63.129.16) n’est pas bloqué par inadvertance.
  • Balises de service et ASG : utilisez des balises de service (par exempleAzureLoadBalancer, , InternetVirtualNetwork) et des groupes de sécurité d’application (ASG) dans des règles de groupe de sécurité réseau au lieu d’adresses IP brutes. Cette approche simplifie la gestion des règles et s’adapte automatiquement à mesure que les plages d’adresses IP Azure changent.
  • Journaux de flux pour une meilleure visibilité : activez les journaux de flux NSG sur chaque NSG de niveau sous-réseau afin de consigner le trafic autorisé et refusé. Les journaux de flux vous aident à vérifier que les règles de sécurité fonctionnent comme prévu et fournissent des preuves pour les audits de conformité. Consultez les journaux de flux NSG pour obtenir des instructions d’installation.

Ces articles du guide de conception de mise en réseau Azure couvrent les rubriques connexes :

Learn more

Pour plus d’informations sur Azure mise en réseau virtuel, consultez les ressources suivantes :

É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 :

Planifiez votre espace d’adressage IP : allouez un pool CIDR /16 qui évite de chevaucher vos plages d’adresses locales.

Ensuite, dans votre parcours de modernisation :

Planifiez votre espace d’adressage IP : allouez des pools d’adresses IP pour deux régions avec des plages non chevauchantes pour le peering actif-actif.

Prochaine étape de votre parcours multi-cloud :

Planifiez votre espace d’adressage IP : concevez une adressage sans chevauchement entre Azure, Amazon Web Services (AWS) et Google Cloud.

  • Last updated on