Planification des adresses IP pour les réseaux virtuels Azure

Cet article traite de la planification des adresses IP privées et publiques pour les déploiements Azure. Vous découvrez comment allouer de l’espace d’adressage, éviter les plages qui se chevauchent, choisir le type d’adresse IP publique approprié et évaluer la prise en charge de la double pile IPv6.

Présentation de cet article

Cet article traite des stratégies d’allocation d’adresses privées, des types d’adresses IP publiques et des références SKU, de la planification CIDR pour éviter les plages qui se chevauchent, les considérations relatives à la double pile IPv6 et le Gestionnaire d’adresses IP (IPAM) pour les environnements à grande échelle.

Qui a besoin de cet article

Lisez cet article si vous :

  • Déployez un réseau virtuel dans Azure et devez décider quelles plages d’adresses IP utiliser.
  • Vous connectez des réseaux Azure à des environnements locaux et devez éviter les conflits d'adresses.
  • Vous devez choisir entre les adresses IP publiques standard, les préfixes d’adresse IP publique ou l’ajout de vos propres plages d’adresses IP (BYOIP).
  • Vous souhaitez comprendre dans quels cas la double pile IPv6 est adaptée à vos charges de travail.
  • Gérez un environnement volumineux ou croissant et avez besoin d’une stratégie pour suivre les allocations d’adresses IP à grande échelle.

Objectif de la migration lift-and-shift : choisissez des plages privées qui ne chevauchent pas votre réseau local afin que le routage via VPN ou ExpressRoute fonctionne sans traduction. Réservez un grand bloc de zone d'atterrissage offrant suffisamment d'espace pour les charges de travail que vous prévoyez de migrer au cours des prochaines années.

Objectif de la modernisation : planifiez des espaces d'adressage qui ne se chevauchent pas entre vos régions principale et de secours afin que les charges de travail actives-actives puissent être appairées ultérieurement, et réservez des sous-réseaux correctement dimensionnés pour App Service Environment et AKS.

Priorité au multicloud : Créez un plan d’adressage global qui n’entre pas en conflit avec les plages CIDR existantes d’AWS VPC ou de Google Cloud, ce qui est indispensable avant de relier des environnements cloud via un VPN ou une interconnexion.

Azure services et fonctionnalités

Les services et fonctionnalités suivants prennent en charge la planification des adresses IP dans Azure :

Service ou fonctionnalité Ce qu’il fournit Quand l′utiliser ?
Espaces d’adressage privés RFC 1918 Trois plages réservées pour une utilisation privée : 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16. Les réseaux virtuels Azure utilisent ces plages pour la communication interne. Toujours : chaque réseau virtuel nécessite au moins une plage d’adresses privée à partir de ces espaces.
Espace d’adressage partagé RFC 6598 100.64.0.0/10 : traité comme espace d’adressage privé dans Azure. Conçu à l’origine pour les environnements de NAT de niveau opérateur (CGNAT). Lorsque votre organisation utilise déjà des plages RFC 6598 en local, ou lorsque l'espace RFC 1918 est épuisé.
Adresse IP publique standard Une adresse IP publique statique redondante interzone affectée à une seule ressource. Sécurisé par défaut avec le trafic entrant bloqué. Lorsqu’une ressource a besoin d’un point de terminaison public unique, tel qu’un équilibreur de charge, une passerelle VPN ou une machine virtuelle publique.
Préfixe d’adresse IP publique Bloc contigu réservé d’adresses IP publiques d’une région Azure spécifique. Lorsque vous avez besoin de plages d'adresses IP prévisibles pour NAT Gateway, Virtual Machine Scale Sets ou des systèmes externes à ajouter à une liste d'autorisations.
BYOIP / Préfixe IP personnalisé Intégrez vos propres plages d’adresses IP publiques à Azure. Utilise un processus en trois phases : valider la propriété, provisionner le préfixe, puis le commissionner pour une utilisation. Lorsque vous devez conserver la réputation IP existante, conserver les entrées de liste approuvées externes ou migrer des charges de travail sans modifier les adresses IP publiques.
Azure Virtual Network Manager IPAM Fonctionnalité intégrée de gestion des adresses IP dans Azure Virtual Network Manager. Généralement disponible dans la plupart des régions. Offre une visibilité centralisée et le suivi des allocations sur l’ensemble des abonnements. Lorsque vous gérez un grand nombre de réseaux virtuels sur plusieurs abonnements et que vous avez besoin d'un suivi automatisé de l'utilisation des espaces d'adressage. Consultez la gestion centralisée du réseau.

Comment choisir

Utilisez les tableaux de décision suivants pour guider vos décisions de planification IP.

Meilleures pratiques en matière de planification IP

Pratique Pourquoi Example
Allouer un CIDR parent de grande taille (/16) et le subdiviser Évite l’épuisement des adresses à mesure que les charges de travail augmentent. Plus facile à résumer les itinéraires. Affectez 10.1.0.0/16 à l’environnement de production, puis carvez /24 sous-réseaux pour chaque niveau de charge de travail.
Laissez au moins 30 % de marge de capacité dans chaque sous-réseau Les services évolutifs tels que Virtual Machine Scale Sets, AKS et App Service Environment consomment rapidement des adresses IP lors des montées en charge. Un sous-réseau /24 fournit 251 adresses IP utilisables. Si votre déploiement de référence en utilise 100, vous disposez d'une marge suffisante pour tripler cette capacité.
Utiliser des blocs CIDR contigus pour chaque environnement Simplifie le résumé des itinéraires et les règles de pare-feu. Une seule route de synthèse représente l’ensemble de l’environnement. Production : 10.1.0.0/16. Préproduction : 10.2.0.0/16. Développement : 10.3.0.0/16.
Évitez les plages réservées et interdites par la plateforme Azure. L’utilisation de plages réservées provoque des échecs de routage et des erreurs de déploiement. N’affectez pas 169.254.0.0/16, 168.63.129.16/32, 224.0.0.0/4, 127.0.0.0.0/8 ou 255.255.255.255/32.
Allocations de documents dans Azure IPAM ou une feuille de calcul Évite les chevauchements à mesure que l’environnement s’agrandit. Centralise la visibilité des équipes réseau. Utilisez Azure Virtual Network Manager IPAM pour le suivi automatisé ou gérez une feuille de calcul partagée pour les environnements plus petits.

Diagramme montrant comment un espace d’adressage de réseau virtuel est divisé en sous-réseaux dimensionnés pour les niveaux de charge de travail et les services de plateforme dédiés tels que la passerelle, le pare-feu et Bastion.

Types d’adresses IP publiques

Catégorie Qu’est-ce que c’est ? Quand l′utiliser ?
Adresse IP publique standard Adresse IP publique statique affectée individuellement. Redondance de zone par défaut dans les régions prenant en charge les zones de disponibilité. Sécurisé par défaut : tout le trafic entrant est bloqué jusqu’à ce qu’un groupe de sécurité réseau ou une règle d’équilibreur de charge l’autorise. Équilibreurs de charge publics, passerelles VPN, Azure Bastion, passerelles d’application ou toute ressource nécessitant un point de terminaison public unique.
Préfixe d’adresse IP publique Bloc contigu réservé d’adresses IP publiques d’une région spécifique. Garantit des adresses séquentielles. La passerelle NAT (nécessite un préfixe pour plusieurs adresses IP sortantes), Virtual Machine Scale Sets ou lorsque des systèmes externes doivent ajouter à une liste approuvée une plage prévisible d’adresses IP.
BYOIP / Préfixe IP personnalisé Les plages d’adresses IP publiques détenues par le client sont intégrées à Azure par le biais d’un processus en trois phases : validation, approvisionnement et commissionnement. Commission des préfixes régionaux en environ 30 minutes ; les préfixes globaux prennent 3 à 4 heures. Préservation de la réputation IP lors de la migration cloud, gestion des entrées de liste approuvées externes ou conformité aux exigences réglementaires en matière de propriété IP. Les adresses IP dérivées d’un préfixe IP personnalisé peuvent également utiliser Azure protection DDoS.

Note

Les adresses IP publiques SKU Basic ont été mises hors service le 30 septembre 2025. Les adresses IP de base existantes continuent de fonctionner, mais ne sont pas prises en charge et n’ont pas de contrat SLA. Effectuez une mise à niveau vers la référence SKU Standard pour tous les nouveaux déploiements.

Décision IPv6

Scénario Recommendation Justification
La charge de travail sert uniquement les clients IPv4, aucune exigence IPv6 réglementaire IPv4 uniquement Configuration la plus simple. Évite la surcharge liée à la gestion en double pile. La plupart des services Azure prennent en charge IPv4 en mode natif.
La charge de travail doit traiter les clients IPv6 ou les réglementations nécessitent une prise en charge IPv6 Double pile (IPv4 + IPv6) Les réseaux virtuels Azure prennent en charge les sous-réseaux à double pile. Déployez IPv6 en même temps que IPv4 sur les mêmes ressources.
La charge de travail a besoin d’IPv6, mais s’appuie sur Pare-feu Azure, Virtual WAN ou le serveur de routage IPv4 uniquement (avec arrêt IPv6 externe) Pare-feu Azure, Virtual WAN et le serveur de routage ne prennent pas actuellement en charge IPv6. Terminez la connexion IPv6 au niveau d’un équilibreur de charge externe ou d’un périphérique de périphérie avant que le trafic n’entre dans ces services. passerelle VPN IPv6 est disponible en préversion.

IPv6 dual-stack sur Azure

Azure prend en charge les déploiements IPv6 en double pile dans les réseaux virtuels. Lorsque vous activez le mode double pile, chaque sous-réseau se voit attribuer à la fois une plage IPv4 et une plage IPv6 /64. Les ressources reçoivent des adresses des deux familles et peuvent communiquer simultanément sur l’un ou l’autre des protocoles.

IPv6 dans Azure a des exigences de dimensionnement spécifiques. Les sous-réseaux IPv6 doivent être exactement /64. Aucune autre longueur de préfixe n’est prise en charge. L’espace d’adressage IPv6 que vous affectez à un réseau virtuel doit être suffisamment grand pour prendre en charge les sous-réseaux /64 pour chaque sous-réseau qui a besoin d’une connectivité IPv6. Planifiez votre allocation d’adresses IPv6 en même temps que vos plages IPv4 lors de la conception réseau initiale.

Les services de Azure suivants prennent en charge les configurations de double pile IPv6 :

Service Prise en charge d’IPv6
Réseau virtuel Azure Sous-réseaux à double pile avec des plages IPv6 en /64
Équilibreur de charge standard Serveurs frontaux IPv6 publics et internes
passerelle VPN Points de terminaison de tunnel IPv6 (préversion ; inscription requise)
NAT Gateway Traduction sortante IPv6 (référence SKU StandardV2 uniquement ; La référence SKU standard est IPv4 uniquement)
Adresse IP publique (SKU Standard) Adresses publiques IPv6
Ensembles de mise à l’échelle de machines virtuelles Interfaces réseau IPv6
VNET Peering Trafic IPv6 entre réseaux virtuels appairés
Groupes de sécurité réseau Règles IPv6 pour le filtrage
DNS (Azure DNS) Prise en charge des enregistrements AAAA

Services clés qui ne prennent pas en charge IPv6 : Pare-feu Azure (nécessite un sous-réseau IPv4 uniquement), Virtual WAN (IPv4 uniquement) et le serveur de routage (IPv4 uniquement). passerelle VPN prend en charge IPv6 en mode double pile, mais uniquement en tant que fonctionnalité en préversion (inscription requise). Si votre architecture dépend de Pare-feu Azure, de Virtual WAN ou du serveur de routage pour l’inspection ou le routage du trafic, concevez votre réseau afin que le trafic IPv6 soit géré avant d’atteindre ces composants.

Pour obtenir des fonctionnalités, limitations et étapes de configuration IPv6 détaillées, consultez IPv6 pour Réseau virtuel Azure.

Adresses réservées Azure

Azure réserve cinq adresses IP dans chaque sous-réseau :

Adresse réservée Objectif
Première adresse (.0) Identificateur réseau
Deuxième adresse (.1) Passerelle par défaut
Troisième adresse (.2) mappage de Azure DNS
Quatrième adresse (.3) mappage de Azure DNS
Dernière adresse (diffusion) Adresse de diffusion

Factorisez ces cinq adresses réservées dans tous les calculs de dimensionnement de sous-réseau. Un sous-réseau /24 fournit 256 adresses totales moins 5 réservées, ce qui laisse 251 adresses IP hôtes utilisables. Le plus petit sous-réseau IPv4 pris en charge est /29 (8 adresses moins 5 réservées = 3 utilisables). Le plus grand sous-réseau IPv4 pris en charge est /2.

Tip

Les adresses IP publiques SKU Standard entraînent des frais, qu’elles soient ou non associées à une ressource. Dans le cadre de l’hygiène IP, supprimez régulièrement les adresses IP publiques que vous n’utilisez plus et relâchez les préfixes d’adresses IP publiques que vous avez dépassés. Les adresses IP publiques non attachées sont une source fréquente de coûts évitables et d’une surface d’attaque inutile.

Considérations relatives à la conception

Objectif de conception de la planification IP pour la migration lift-and-shift

  • Réservez un seul bloc CIDR de grande taille (un /16 est courant) pour la zone de déploiement et subdivisez-le pour chaque application migrée, en conservant une marge d’environ 20 % pour la croissance future.
  • Choisissez des plages qui ne chevauchent pas les réseaux locaux que vous connectez via passerelle VPN ou ExpressRoute. Le routage fonctionne donc sans traduction d'adresses.
  • Comptez les cinq adresses réservées de Azure par sous-réseau et les sous-réseaux dédiés requis par les services de plateforme, tels que GatewaySubnet (/27) et AzureFirewallSubnet (/26).
  • Là où les réseaux n’établissent jamais de peering, vous pouvez réutiliser délibérément des plages IPv4 privées pour préserver l’espace d’adressage.

Moderniser l’approche de conception de la planification IP

  • Attribuez des plages qui ne se chevauchent pas dans vos régions principale et de secours afin que les charges de travail actives-actives puissent ultérieurement utiliser le peering global sans renumérotation des adresses.
  • Réservez un sous-réseau dédié de taille adaptée à App Service Environment (/24, ou /23 si vous approchez de la capacité maximale). Pour AKS avec CNI Overlay, dimensionnez le sous-réseau uniquement pour les nœuds, car les pods utilisent une plage CIDR de superposition distincte, ce qui rend le sous-réseau des nœuds bien plus petit que ne l’exige une architecture CNI plate.
  • Réservez un sous-réseau dédié pour les points de terminaison privés afin que l’adoption de PaaS ne fragmente pas votre plan d’adresse.
  • Utilisez Azure Virtual Network Manager gestion des adresses IP pour suivre et automatiser les allocations à mesure que votre environnement est mis à l’échelle.

Objectif de conception de la planification IP multicloud

  • Établissez d’abord un plan d’adressage global : réservez des blocs CIDR Azure qui ne se chevauchent pas avec les VPC AWS existants ni avec les réseaux VPC Google Cloud, ce qui est requis pour un VPN routé ou une interconnexion.
  • Documentez les plages d’adresses de chaque cloud connecté et branche pour que vous puissiez planifier des itinéraires résumés via Azure Virtual WAN.
  • Réservez de l’espace d’adressage IP pour les composants de transit, tels que le hub Virtual WAN et les sous-réseaux de passerelle VPN, en prévoyant une marge d’évolution à mesure que vous ajoutez des points de présence cloud et des succursales.
  • Lorsque les chevauchements sont inévitables, prévoyez de faire du NAT sur les connexions VPN concernées ou de réadresser les charges de travail pendant la migration plutôt qu’après.

Prerequisites

Avant de planifier votre allocation d’adresses IP :

  • Conception de réseau virtuel : Vous disposez d’une structure de réseau virtuel existante ou planifiée. Si vous n'avez pas encore conçu vos réseaux virtuels, consultez d'abord Azure réseaux virtuels et sous-réseaux.
  • Inventaire IP local : Documentez les plages d’adresses locales existantes, y compris toutes les plages utilisées par les succursales, les centres de données ou d’autres fournisseurs de cloud. Les adresses qui ne se chevauchent pas sont requises pour la connectivité hybride.
  • Projections de croissance : Estimez le nombre de sous-réseaux et d’hôtes supplémentaires dont vous aurez besoin au cours des 2 à 3 prochaines années. Allouer l’espace d’adressage dès le départ est plus facile que d’étendre un réseau virtuel plus tard.

Considérations relatives à la sécurité

La planification IP a des implications directes en matière de sécurité. Suivez ces pratiques pour réduire les risques :

  • Empêcher le chevauchement d’adresses : Les plages d’adresses IP qui se chevauchent entre les réseaux locaux, les réseaux virtuels Azure et les réseaux virtuels appairés provoquent des défaillances de routage. Le trafic peut atteindre la mauvaise destination ou être rejeté sans notification. Vérifiez que chaque plage d’adresses est unique sur l’ensemble de votre réseau.
  • Évitez les plages interdites : Azure réserve les plages suivantes pour les opérations de plateforme. Ne les utilisez jamais comme espace d’adressage de réseau virtuel :
    • 169.254.0.0/16 (lien local)
    • 168.63.129.16/32 (Azure DNS interne)
    • 224.0.0.0/4 (multidiffusion)
    • 127.0.0.0/8 (bouclage)
    • 255.255.255.255/32 (diffusion)
  • Document et audit : Conservez un enregistrement actuel de toutes les allocations IP. Les plages non documentées entraînent un chevauchement accidentel lorsque de nouvelles charges de travail sont déployées. Utilisez Azure Virtual Network Manager IPAM pour le suivi de conformité automatisé ou gérez une feuille de calcul partagée qui est examinée pendant chaque déploiement.
  • Protéger les adresses IP publiques : Associez Azure protection DDoS aux ressources IP publiques dans les environnements de production. Les plages BYOIP peuvent également être protégées par la protection DDoS.

Ces articles couvrent les rubriques qui interagissent avec la planification des adresses IP :

Learn more

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

Sécurisez vos sous-réseaux avec des groupes de sécurité réseau : reflètez vos règles de pare-feu existantes en tant que règles de groupe de sécurité réseau pour maintenir votre posture de sécurité dans Azure.

Ensuite, dans votre parcours de modernisation :

Sécurisez vos sous-réseaux avec des groupes de sécurité réseau : appliquez une segmentation stricte afin que seul le trafic de l’équilibreur de charge atteigne vos sous-réseaux d’application.

Prochaine étape de votre parcours multi-cloud :

Sécurisez vos sous-réseaux avec des groupes de sécurité réseau : reflètez vos groupes de sécurité AWS et les règles de pare-feu Google Cloud en tant que groupes de sécurité réseau Azure.

  • Last updated on