Introduction

La gestion des plages IP dans un environnement cloud multi-équipes est souvent une source de friction : qui possède quel bloc CIDR ? Quelle plage est encore disponible ? Comment éviter les chevauchements entre spoke VNets, environnements on-premises et espaces cloud ? Ces questions reviennent à chaque nouveau déploiement et mobilisent inutilement les équipes réseau.

Azure Virtual Network Manager (AVNM) intègre depuis sa GA une fonctionnalité native d'IP Address Management (IPAM) qui centralise et automatise entièrement cette gestion. Combinée à Terraform, elle permet à n'importe quelle équipe de demander un bloc d'adresses sans avoir besoin de connaître la moindre notation CIDR.

1. Architecture et concepts fondamentaux

Le modèle de pools hiérarchiques

L'IPAM d'Azure Virtual Network Manager repose sur un modèle de pools d'adresses hiérarchiques pouvant atteindre 7 niveaux de profondeur :

Network Manager (scope : subscription ou management group)
└── Root Pool  (ex : 10.0.0.0/16 — espace global de l'organisation)
    ├── Child Pool : prod-west    (10.0.0.0/18   — 16 384 IPs)
    ├── Child Pool : prod-east    (10.0.64.0/18  — 16 384 IPs)
    ├── Child Pool : staging      (10.0.128.0/18 — 16 384 IPs)
    └── Child Pool : dev          (10.0.192.0/18 — 16 384 IPs)
            └── VNet allocation  → bloc /24 attribué automatiquement

• Root pool : représente l'espace d'adressage global de l'organisation.

• Child pool : subdivision logique du parent. Peut être délégué à une équipe ou une région.

• Static CIDR : réservation manuelle d'un bloc pour des ressources hors-Azure (on-premises, autres clouds, équipements réseau).

Comportement d'allocation

L'allocation est basée sur la puissance de deux la plus proche. Si une VNet demande 5 000 adresses, IPAM attribue automatiquement un /19 (8 192 IPs) — jamais un bloc fragmenté. Cette approche garantit des préfixes valides et évite les trous dans l'espace d'adressage.

Types de ressources ARM

2. Prérequis et permissions

Rôles RBAC requis

La délégation granulaire est un point fort du service : les équipes applicatives peuvent se voir accorder le rôle IPAM Pool User sur un child pool spécifique, sans aucun accès aux autres pools.

Disponibilité régionale

IPAM est généralement disponible dans toutes les régions Azure Virtual Network Manager, à l'exception de : Chile Central, Jio India West, Malaysia West, Qatar Central, South Africa West, West India.

3. Déploiement complet avec Terraform

Configuration du provider

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.35"
    }
  }
}

provider "azurerm" {
  features {}
}

data "azurerm_subscription" "current" {}

3.1 Azure Virtual Network Manager

Le Network Manager est l'instance racine qui définit le scope (subscription ou management group). Tout l'IPAM vit sous cette ressource.

resource "azurerm_resource_group" "networking" {
  name     = "rg-network-manager"
  location = "westeurope"
}

resource "azurerm_network_manager" "main" {
  name                = "anm-platform"
  location            = azurerm_resource_group.networking.location
  resource_group_name = azurerm_resource_group.networking.name

  scope {
    subscription_ids = [data.azurerm_subscription.current.id]
  }

  scope_accesses = ["Connectivity", "SecurityAdmin"]
}

3.2 Root Pool

Le root pool définit l'espace d'adressage global géré par la plateforme.

locals {
  global_cidr = "10.0.0.0/16"
}

resource "azurerm_network_manager_ipam_pool" "root" {
  name               = "ipam-pool-global"
  location           = azurerm_resource_group.networking.location
  network_manager_id = azurerm_network_manager.main.id

  address_prefixes = [local.global_cidr]

  display_name = "Global IP Space"
  description  = "Espace d'adressage global de l'organisation"
}

3.3 Child Pools par région ou environnement

Les child pools subdivisent l'espace global. La fonction cidrsubnet() de Terraform est idéale pour calculer les sous-blocs de manière déclarative.

locals {
  environments = {
    prod-westeurope  = { offset = 0 }
    prod-northeurope = { offset = 1 }
    staging          = { offset = 2 }
    dev              = { offset = 3 }
  }
}

resource "azurerm_network_manager_ipam_pool" "env" {
  for_each = local.environments

  name               = "ipam-pool-${each.key}"
  location           = azurerm_resource_group.networking.location
  network_manager_id = azurerm_network_manager.main.id
  parent_pool_name   = azurerm_network_manager_ipam_pool.root.name

  # Chaque child pool hérite d'un /18 du root /16
  address_prefixes = [cidrsubnet(local.global_cidr, 2, each.value.offset)]

  display_name = "Pool ${each.key}"
}

Résultat :

3.4 Réservation de CIDRs statiques

Les CIDRs statiques permettent de réserver des plages pour des ressources hors-Azure (on-premises, DMZ, VPN concentrators) afin qu'IPAM ne les réattribue jamais.

resource "azurerm_network_manager_ipam_pool_static_cidr" "onprem" {
  name         = "static-onprem-datacenter"
  ipam_pool_id = azurerm_network_manager_ipam_pool.root.id

  address_prefixes = ["10.0.0.0/20"]

  description = "Réservé pour le datacenter on-premises Paris"
}

4. La vraie valeur ajoutée : demander un range sans connaître le CIDR

C'est ici que l'IPAM révèle tout son intérêt opérationnel. Une équipe applicative qui déploie une nouvelle VNet n'a plus besoin de coordonner avec l'équipe réseau pour connaître la plage disponible. Elle indique uniquement le nombre d'adresses nécessaires.

Exemple : déploiement d'une VNet applicative

# L'équipe applicative n'a besoin que de connaître :
# 1. L'ID du pool IPAM ciblé (fourni par l'équipe plateforme)
# 2. Le nombre d'adresses dont elle a besoin

variable "ipam_pool_id" {
  description = "ID du pool IPAM cible (fourni par l'équipe plateforme)"
  type        = string
}

resource "azurerm_resource_group" "app" {
  name     = "rg-app-myservice"
  location = "westeurope"
}

resource "azurerm_virtual_network" "app" {
  name                = "vnet-myservice"
  location            = azurerm_resource_group.app.location
  resource_group_name = azurerm_resource_group.app.name

  # Plus d'address_space à spécifier manuellement !
  ip_address_pool {
    id                     = var.ipam_pool_id
    number_of_ip_addresses = "256"  # IPAM attribue le /24 suivant disponible
  }
}

Le workflow en pratique

L'équipe applicative n'a jamais vu une notation CIDR. L'équipe plateforme n'a pas eu à intervenir manuellement. Azure garantit qu'aucune autre VNet n'a reçu ce même bloc.

Passage de l'ID du pool via Remote State (pattern recommandé)

# Dans le module plateforme — outputs.tf
output "ipam_pool_dev_id" {
  value = azurerm_network_manager_ipam_pool.env["dev"].id
}

# Dans le module applicatif
data "terraform_remote_state" "platform" {
  backend = "azurerm"
  config = {
    resource_group_name  = "rg-tfstate"
    storage_account_name = "satfstate"
    container_name       = "tfstate"
    key                  = "platform/network.tfstate"
  }
}

resource "azurerm_virtual_network" "app" {
  name                = "vnet-myservice"
  location            = "westeurope"
  resource_group_name = azurerm_resource_group.app.name

  ip_address_pool {
    id                     = data.terraform_remote_state.platform.outputs.ipam_pool_dev_id
    number_of_ip_addresses = "256"
  }
}

5. Gestion des allocations et monitoring

Vue d'utilisation dans le portail Azure

Azure Virtual Network Manager expose une vue centralisée de l'utilisation de chaque pool : nombre total d'IPs, pourcentage alloué, liste des VNets associées. Cela donne à l'équipe plateforme une visibilité en temps réel sur la saturation de l'espace d'adressage.

Délégation granulaire via Azure CLI

# Donner accès à l'équipe "squad-payments" uniquement sur le pool dev
az role assignment create \
  --role "IPAM Pool User" \
  --assignee "<object-id-squad-payments>" \
  --scope "/subscriptions/<sub-id>/resourceGroups/rg-network-manager/providers/Microsoft.Network/networkManagers/anm-platform/ipamPools/ipam-pool-dev"

Comportement en cas d'épuisement du pool

Si le pool est saturé, Azure retourne une erreur HTTP 400 avec le code IpamApiCallFailed. En Terraform, cela se traduit par un échec du terraform apply avec un message explicite. L'équipe plateforme est alors responsable d'étendre le pool ou d'en créer un nouveau.

6. Limites et points d'attention

7. Coûts

L'IPAM d'Azure Virtual Network Manager génère deux lignes de facturation distinctes à comprendre.

7.1 Frais Azure Virtual Network Manager (base)

AVNM facture selon le modèle Virtual network-based billing (par défaut pour toute nouvelle instance créée après février 2025) :

€/heure par VNet managée — c'est-à-dire toute VNet ayant une configuration AVNM active déployée dessus.

• Si 100 VNets sont dans le scope mais que 5 seulement ont une configuration active, seules les 5 sont facturées.

• Une VNet avec plusieurs configurations (connectivity + security admin) du même Network Manager n'est facturée qu'une seule fois.

Pour les instances créées avant février 2025, le modèle par subscription s'applique par défaut. La migration vers le modèle par VNet est disponible via Azure Feature Exposure Control (AFEC). Le modèle par subscription sera retiré le 6 février 2028.

7.2 Frais IPAM (spécifiques)

La facturation IPAM est indépendante des frais AVNM de base :

€/heure par IP active gérée par l'IPAM d'Azure Virtual Network Manager.

Définition d'une IP active : toute adresse IP associée à une interface réseau (NIC) dans une VNet elle-même associée à un pool IPAM.

7.3 Estimation et bonnes pratiques

Exemple : 50 VMs actives avec 1 NIC chacune dans des VNets IPAM
→ 50 IPs actives × prix unitaire horaire × 730h/mois

Optimisations recommandées :

1. Éviter le sur-dimensionnement des allocations : demander 256 adresses pour un workload qui n'en utilisera que 10 ne coûte rien à la réservation — les NICs actives sont la vraie variable de coût.

2. Éteindre (deallocate) les VMs hors prod : les VMs deallocated libèrent leurs NICs et n'entrent plus dans la base de facturation IPAM.

3. Consolider les Network Managers : une seule instance AVNM par région / management group évite la multiplication des frais de base.

4. Monitorer via Azure Cost Management : filtrer par ressource Microsoft.Network/networkManagers pour isoler les coûts AVNM et IPAM.

Les prix exacts varient selon la région et le type de contrat Microsoft (Pay-as-you-go, EA, MCA). Consultez la calculatrice Azure pour une estimation précise adaptée à votre contexte.

8. Récapitulatif des ressources Terraform

Conclusion

L'IPAM d'Azure Virtual Network Manager transforme la gestion des plages IP d'un processus manuel et error-prone en un service déclaratif piloté par la demande. En Terraform, l'équipe plateforme configure une fois la hiérarchie de pools et délègue ; les équipes applicatives réclament des blocs en précisant uniquement un nombre d'adresses. Azure garantit l'absence de chevauchement, le portail offre la visibilité centralisée, et la facturation reste maîtrisable en surveillant les IPs actives plutôt que les réservations.

Le seul manque notable à date reste l'absence de data source Terraform pour azurerm_network_manager_ipam_pool, qui force le passage de l'ID du pool via remote state ou variable — un gap qui devrait être comblé dans les prochaines versions du provider AzureRM.

Sources :

• Microsoft Learn — What is IPAM in Azure Virtual Network Manager

• Microsoft Learn — Manage IP addresses with Azure Virtual Network Manager

• Azure Virtual Network Manager Pricing