IPAM pour vos Landing zones, votre résolution de 2025

Introduction

De nombreuses architectures de Landing Zones ont débuté sans intégrer de fonctionnalité IPAM (IP Adress management) et ce pour plusieurs raisons : 

• Absence de solution native dans Azure (ce n’est plus le cas aujourd’hui) 

• Coût perçu comme trop élevé  

• Collaboration complexe avec l’équipe réseau, freinant l’industrialisation 

• Intégration jugée non prioritaire, repoussée à plus tard 

Avec le temps, dans votre architecture LZ, la manière dont vous gérer vos adresses IP peut devenir un frein pour votre business. Sans réseau, pas de workload hébergé dans Azure. En 2025, avec les nouveaux usages comme l’IA, les besoins réseau explosent. Par exemple, dans une architecture Azure OpenAI Chat basée sur une Landing Zone, nous faisons face à ce schéma et la lecture de la documentation associée : 

De ce schéma et la lecture de la documentation associée, nous faisons face aux éléments suivants :  

• Multiples instances déployées dans diverses régions Azure (West Europe, France Central, Sweden Central) pour accéder à tous les modèles d’OpenAI. 

• Besoin de multiples Virtual Networks avec segmentation en multiples sous-réseaux 

• Présence de services Azure spécifiques nécessitant des sous-réseaux dédiés (APPGW, APIM, …) 

Chaque instance, consomme un range /22, soit 1022 adresses IP, pour une seule Landing Zone. Face à ces enjeux, il est temps d’abandonner vos fichiers Excel et d’intégrer une solution d’IPAM dans vos Landing Zones. Avant de rentrer dans la technique, il faut un peu de planification et définir ses stratégies d’allocations. 

Un IPAM nécessaire pour de nouveaux scénarios 

Les équipes en charge des workloads hébergés dans les Landing zones gagnent en maturité et en expertise au fil du temps. De nombreux changements sont alors opérés pour optimiser les workloads existants. Parallèlement, de nouvelles approches comme VNET Integration apparaissent, impliquant la création de sous-réseaux dédiés. 

Tous ces mouvements vont avoir un impact sur les besoins en adressage IP au sein de nos Landing zones. Voici les scénarios à anticiper : 

• Le recyclage des plans d’adressage des Virtual Networks des landing zones décommissionnées 

• L’extension du plan d’adressage du Virtual Network de la Landing zone 

• L’extension d’un sous-réseau au sein du Virtual Network de la Landing zone 

Le recyclage du plan d’adressage des Virtual Networks présents dans les Landing zones décommissionnées est le premier de ces scénarios.  Il est essentiel de récupérer les plans d’adressage inutilisés.  Une solution IPAM disposant d’une fonctionnalité de découverte et de réconciliation permet de gagner un temps précieux. Il est donc essentiel de câbler / industrialiser ce processus dans vos Landing zone dès que possible. 

Le second scénario concerne l’extension du plan d’adressage du Virtual Network présent dans notre Landing zone. Il n’y a plus de place, il faut réagir et étendre le plan d’adressage actuel : Resize the address space of Azure virtual networks that are peered. Le challenge, sera de réaliser la resynchronization des Virtual Network Peerings :  Update the address space for a peered virtual network using the Azure portal.  Avec ce scénario nous allons pouvoir créer nouveaux sous-réseaux, mais pas encore étendre des sous-réseaux existants. 

Le troisième scénario est assez nouveau (Juin 2024), encore actuellement en preview : Create multiple prefixes for a subnet in an Azure Virtual Network. C’est pleinement documenté ici.  

Dans le cadre du déploiement d’une solution IPAM, les deux premiers scénarios devront être pris en compte en priorité, tandis que le troisième pourra être intégré une fois sa disponibilité officielle confirmée. Revoir le plan d’adressage des Virtual networks peut entraîner des conséquences dans le Hub qu’il ne faudra pas négliger. Il sera également nécessaire d’anticiper ce scénario : Do not let ExpressRoute, VPN and SDWAN traffic bypass your firewall. 

Importance de préparer son plan adressage 

Le plan d’adressage IP (IPv4) routable est devenu une ressource rare, en particulier dans les grandes organisations. Une gestion rigoureuse est donc indispensable pour répondre aux besoins d’hébergement dans Azure.   

L’organisation du découpage du plan d’adressage doit s’appuyer sur plusieurs questions clés : 

• Mono-cloud / Multi-Cloud?  De nombreuses grandes organisations utilisent plusieurs fournisseurs, avec un cloud provider principal et un secondaire.Quelle segmentation entre les environnements (DEV, QA, PRD) ?  Les environnements de production doivent être privilégiés afin d’éviter un gaspillage des ressources. 

• Faut-il -être présent dans plusieurs zones business (EMA, AMER, APAC, …) pour déployer des Hub régionaux auxquels on va connecter nos Landing zones ? 

• Quel nombre de Virtual Networks dans nos Landing zones ?  Ce point devient crucial lorsqu’il s’agit d’assurer la résilience des applications critiques. 

• Quels sont les workloads hébergés dans les Landing zones ? Pour certains, cela implique des sous-réseaux dédiés (VNET integration). Certaines configuration réseau d’AKS sont particulièrement gourmandes et doivent à tout prix être évitées. 

 Une planification à long terme s’impose, tout en recherchant des optimisations pour réduire les coûts lorsque cela est possible.  

Quelle stratégie d’allocation ? 

Il est courant de penser qu’un seul plan d’adressage IP Azure routable suffit à couvrir tous les besoins. Cette approche suppose que l’ensemble des consommateurs des Landing Zones ont les mêmes besoins, ce qui n’est absolument pas le cas. Lors de mes discussions avec les futurs consommateurs des Landing zones, je m’intéresse à un certain nombre de points dont la dépendance avec des ressources On-Premises.

Si la connectivité directe avec On-Premises n’est pas obligatoire ou si une autre solution d’hybridation réseau peut être envisagée, alors d’autres stratégies d’allocation peuvent être explorées, telles que : 

• Proposer plusieurs plans d’adressage IP entre vos Landing zones 

• Proposer plusieurs plans d’adressages au sein du Virtual Network de la Landing zone 

Proposer plusieurs plans d’adressage IP pour vos Landing zones 

Dans les projets Landing zones, il y a un scénario que je propose souvent, ce sont les Landing zones d’expérimentation. De par leur destination, il n’est pas opportun qu’elles disposent d’une connectivité routée vers le réseau On-Premises, c’est même bien vu par les équipes sécurité. Dans ce contexte, mon IPAM propose deux plans d’adressage IP, en fonction des Landing zones : 

• Landing zones classiques 

• Landing zones d’expérimentation 

Le schéma ci-dessous illustre la présence de plusieurs Landing Zones sur des plans d’adressage distincts, toutes connectées à un Hub commun, lui-même présent sur les deux plans d’adressage. L’Azure Firewall situé dans le Hub est alors responsable du routage vers On-Premises. 

En introduisant plusieurs plans d’adressage IP (routable et non routable), il devient plus simple de multiplier les sous-réseaux alloués et d’assurer une micro-segmentation entre les applications. Cependant, certaines expérimentations peuvent nécessiter un accès depuis On-Premises. Deux solutions peuvent être envisagées :  

• Exposer uniquement la partie frontale du workload en s’appuyant sur des services comme Azure Application Gateway et Azure API Management, généralement déployés dans le Hub. 

• Utiliser Private Link, une approche détaillée en complément de cet article 

Plus généralement, notre IPAM devrait être en mesure de proposer trois classes de plan d’adressage :  

• Un plan d’adressage compatible RFC1918 et RFC6598 à allouer avec parcimonie 

• Un plan d’adressage pris en charge par le Hub mais non routable vers On-Premises 

• Un plan d’adressage non pris en charge par le routage du Hub et non routable vers On-Premises pour isoler certains usages 

Proposer plusieurs plans d’adressages au sein du Virtual Network de la Landing zone 

Comme évoqué précédemment, l’adresse IP privée routable est devenue une ressource rare et précieuse. Parallèlement, les besoins des workloads hébergés ne cessent de croître tant que l’hybridation réseau doit être maintenue, en attendant une migration complète vers Azure ou une transition vers IPv6. 

Pour optimiser cette allocation, il est possible d’exploiter la capacité du Virtual Network à gérer plusieurs plans d’adressage IP. Le schéma ci-dessous illustre cette approche : 

Deux plans d’adressage IP (routable et non routable) sont alloués au niveau du Virtual Network pour ensuite être affectés aux sous-réseaux. 

• À ce jour, un sous-réseau est composé d’un seul plan d’adressage, mais il est déjà prévu qu’un sous-réseau existant puisse être étendu avec de nouveaux plans d’adressage. 

• Bien que cette approche puisse sembler complexe au premier abord, elle présente un avantage majeur : gérer de manière rationnelle une ressource devenue rare, l’adresse IP routable. 

Dans un environnement AKS, cette stratégie s’avère particulièrement pertinente. Depuis les réseaux On-Premises, seuls certains éléments doivent être accessibles : l’API du cluster et les workloads exposés via l’Ingress / Gateway. L’intégralité des pods hébergés sur le cluster ne nécessite pas d’être accessible. 

Cela implique quelques ajustements : 

• Positionner le Private Endpoint de notre Private-Cluster AKS sur le sous-réseau routable 

• Positionner le System node pool de notre Private-Cluster AKS sur ce même sous-réseau 

• Positionner notre Ingress sur un ce même sous-réseau : Specify a different subnet  

• Mais positionner les User nodes pools sur un sous-réseau non routable : Add a node pool with a unique subnet. 

Enfin, il est toujours possible d’aller plus loin en renforçant l’isolation grâce à Private Link, une approche détaillée en complément de cet article. 

Quels IPAM en 2025 ? 

Il y a quelques années, les options étaient limitées. Aujourd’hui, le choix s’est élargi, et nous pouvons distinguer deux grandes catégories de solutions : 

• Les solutions « Network-Native » 

• Les solutions « Azure-Native » 

Les solutions « Network-Native »  

Issues du monde réseau, ces solutions sont souvent privilégiées par les équipes réseau et peuvent déjà être déployées On-Premises. Parmi les plus connues : 

• Infoblox : bien intégré aux environnements réseau, il propose divers services (DHCP, DNS, IPAM, etc.) et s’interface avec Azure via un provider Terraform. 

Infoblox peut être déployé sous forme de NVA (Network Virtual Appliance) via le Marketplace Azure. 

• Netbox : solution de la communauté Open-Source proposant de nombreuses fonctionnalités, y compris l’IPAM. Son intégration avec Azure repose également sur Terraform. 

NetBox peut être installé sur machine virtuelle ou sous forme de conteneurs sur un cluster AKS. 

Les solutions « Azure-Native »  

Comme son nom l’indique la catégorie des solutions « Azure-Native » sont développées spécifiquement pour Azure.  Ces deux solutions comprennent :  

• Azure Virtual Network Manager 

• Azure IPAM 

Azure Virtual Network Manager  

Azure Virtual Network Manager est un service Azure pour gérer efficacement des réseaux à grande échelle. Dans cette boîte à outils, Microsoft a récemment intégré une composante IPAM. Attention, l’offre est actuellement en preview. Cela explique que la solution ne dispose pas encore d’intégration via un provider Terraform : Support IP address management for Azure Network Manager. Si vous entamez une réflexion pour délivrer une nouvelle infrastructure de type Hub and Spoke, c’est une offre à ne pas négliger car côté intégration on ne peut pas faire plus simple qu’une case à cocher dans le portail Azure : 

Azure IPAM  

Pour finir, Azure IPAM est une solution Open-Source développée par des collaborateurs de Microsoft. Elle présente plusieurs avantages dont un déploiement totalement packagé et même une API pour interagir avec la solution. Les GitHub Discussions page du repo GitHub montrent qu’il y a une roadmap intéressante (prise en charge Multi-tenant, Azure Container Apps, …). 

Seul point négatif pour Azure IPAM, c’est son intégration native avec Azure reste en retrait par rapport aux autres solutions (pas encore de provider Terraform). 

Les acteurs du réseau préfèreront des solutions qu’ils connaissent déjà comme Infoblox ou Netbox. C’est un choix judicieux surtout si elles sont déjà déployées On-Premises.  

Toutefois, quelle que soit la solution retenue, le principal défi réside dans son intégration dans le subscription vending afin de l’exploiter efficacement dans toutes les landing zones. 

Bonus : Comment réduire ses besoins en IP ? 

 Il est essentiel d’analyser les besoins des workloads hébergés pour optimiser le plan d’adressage. Prenons l’exemple d’AKS, le choix du CNI sera déterminant. 

 En 2025, l’option à privilégier est clairement Azure CNI Overlay : 

Source : AKS CNI networking options 

Si vous avez encore des clusters AKS utilisant autre chose que le CNI Overlay, il est temps de revoir votre approche. Jusqu’ici, nous avons toujours supposé que l’accès à un cluster AKS nécessitait un réseau routable. Or, Azure Private Link permet d’éliminer cette contrainte.  

Dans le schéma ci-dessous, nous avons :  

• Le producteur d’un service à droite qui expose son service. 

• Le consommateur de ce service à gauche qui accède au service mis à disposition. 

Source : Azure Private Link Service 

Plusieurs remarques sont à constater :  

• Nous avons bien deux Virtual Network distincts sur des plans d’adressage distincts mais pas de Perring entre eux, ce qui signifie pas de routage. 

• Le seul lien entre les deux Virtual Networks, c’est un Private Endpoint d’un côté et un Private Link de l’autre.  

• Les deux parties prenantes peuvent être dans des souscriptions Azure distinctes, des régions Azure distinctes et même dépendre de tenant Azure AD distincts. 

Lorsque je présente le scénario pendant les formations Azure que j’ai le plaisir d’animer, je fais la comparaison avec la série TV Stargate SG-1 avec les portes des étoiles (et même Stargate Universe pour les Tenant Azure AD distincts 😉). Voyons maintenant les étapes de la mise en œuvre avec le worklfow suivant que nous allons interpréter pour notre contexte Landing zone : 

Source: Azure Private Link service workflow 

1. Tout commence par le workload dans la Landing Zone, qui doit être exposé via un Load Balancer de SKU Standard. Bonne nouvelle : AKS utilise ce service pour exposer l’Ingress ou la Gateway. 
2. Dans cette Landing Zone, nous créons un Private Link Service lié à notre Load Balancer. 
3. Du côté du Hub, la mise en place d’un Private Endpoint permettra de référencer le Private Link   
4. Une fois la demande de connexion approuvée au niveau du Private Link Service, la connectivité réseau devient fonctionnelle. 
5. Il ne reste plus qu’à associer un enregistrement DNS au Private Endpoint. 

L’intégration avec AKS repose sur quelques annotations au niveau du service : 

Source : Azure Private Link Service Integration 

 Cette approche, bien que radicalement différente, présente de nombreux avantages. 

Conclusion 

Toutes les cartes sont désormais en main pour intégrer l’IPAM de votre choix dans les architectures de Landing Zones et repenser le plan d’adressage IP afin d’ouvrir de nouvelles possibilités aux consommateurs. 

Même si l’année 2025 est déjà bien entamée, il n’est pas trop tard pour inscrire un projet IPAM dans le backlog des bonnes résolutions. Un sujet sur lequel les consultants de Cellenza ont déjà accompagné plusieurs clients.