Azure Virtual Network Manager : La solution pour dompter votre réseau à l'échelle

Dans le cloud, la complexité du réseau augmente de façon exponentielle avec la croissance de l'infrastructure. Gérer 5 réseaux virtuels (VNets) via des peerings manuels est trivial. En gérer 500 répartis sur 50 souscriptions et plusieurs régions devient un cauchemar opérationnel.

C'est ici qu'intervient Azure Virtual Network Manager (AVNM). Ce service, aujourd'hui incontournable pour les grandes entreprises, permet de centraliser la gestion de la connectivité et de la sécurité réseau à l'échelle globale.

1. Qu'est-ce que Azure Virtual Network Manager ?

Azure Virtual Network Manager est un service de gestion de réseau hautement évolutif. Il permet aux équipes IT (Cloud Architects, NetOps) de gérer des réseaux virtuels de manière centralisée sur plusieurs abonnements, groupes de ressources et régions.

Le problème qu'il résout : Avant AVNM, pour connecter une architecture Hub & Spoke, il fallait créer manuellement chaque peering entre le Hub et les Spokes, gérer les tables de routage, et s'assurer que les NSG (Network Security Groups) étaient cohérents partout. AVNM automatise et gouverne tout cela.

2. Les concepts clés de l'architecture AVNM

Pour maîtriser AVNM, il faut comprendre ses trois piliers fondamentaux :

A. La Portée (Scope)

C'est la frontière de gestion de votre instance AVNM. Elle est généralement définie au niveau d'un Management Group (Groupe d'administration) ou d'une Souscription. Une fois la portée définie, AVNM a la visibilité sur tous les VNets qui s'y trouvent.

B. Les Groupes de Réseaux (Network Groups)

C'est une logique de regroupement des VNets. Au lieu de penser "VNet A" et "VNet B", vous pensez "Réseaux de Production" ou "Réseaux DMZ".

• Adhésion Statique : Vous ajoutez manuellement des VNets.

• Adhésion Dynamique (La puissance réelle) : Vous utilisez Azure Policy. Par exemple : "Tous les VNets ayant le tag Env: Prod rejoignent automatiquement le groupe Production". Dès qu'un développeur crée un VNet avec ce tag, il est automatiquement configuré et sécurisé.

C. Les Configurations

Une fois vos groupes créés, vous leur appliquez des configurations de deux types :

1. Configuration de Connectivité

2. Configuration de Sécurité

3. Gestion de la Connectivité : L'automatisation du Peering

AVNM simplifie drastiquement la topologie réseau. Il propose deux modèles principaux :

Le modèle Mesh (Maillé)

Tous les VNets du groupe sont connectés les uns aux autres.

• Cas d'usage : Une flotte de bases de données qui doivent se répliquer entre elles, ou des microservices très interdépendants.

• Avantage : Plus besoin de créer un maillage $N \times (N-1)$ de peerings manuels.

Le modèle Hub and Spoke (Étoile)

C'est le modèle le plus courant. Vous définissez un VNet comme "Hub" et les autres comme "Spokes".

• Peerings automatiques : AVNM crée les peerings bidirectionnels entre le Hub et chaque Spoke.

• Direct Connectivity (Optionnel) : Vous pouvez permettre aux Spokes de se parler directement (sans passer par le firewall du Hub) pour réduire la latence, tout en restant dans une topologie Hub & Spoke gérée.

4. Gestion de la Sécurité : Les Règles d'Administration (Security Admin Rules)

C'est souvent la fonctionnalité la plus mal comprise, mais la plus puissante pour la gouvernance.

Les Security Admin Rules ne remplacent pas les NSG (Network Security Groups), elles se placent au-dessus.

La hiérarchie de décision :

1. AVNM Security Admin Rules (Évalué en premier)

2. NSG classiques (Évalué ensuite)

Pourquoi est-ce crucial ?

Cela permet aux équipes de sécurité centrale d'imposer des règles que les propriétaires d'applications (qui gèrent leurs propres NSG) ne peuvent pas contourner.

Exemple : L'équipe Sécurité crée une règle AVNM "Deny All SSH from Internet". Même si un développeur met une règle "Allow SSH Any/Any" sur son NSG local, le trafic sera bloqué car la règle AVNM prime.

On utilise souvent AVNM pour :

• Always Allow : Forcer l'autorisation du trafic vers les contrôleurs de domaine ou les outils de monitoring.

• Always Deny : Bloquer des protocoles à risque (Telnet, FTP, SSH ouvert) au niveau global.

5. Déploiement : L'importance des Régions

AVNM fonctionne avec un concept de déploiement explicite. Créer une configuration ne suffit pas ; il faut la déployer vers les régions cibles.

Si vous avez des VNets en France Central et West Europe, et que vous créez une configuration Mesh, celle-ci ne sera active que lorsque vous aurez poussé la configuration vers ces deux régions spécifiques via l'interface AVNM. Cela agit comme une sécurité pour éviter d'impacter le réseau mondial par erreur.

6. Synthèse des avantages

7. Exemple en Terraform

Voici un exemple complet et fonctionnel pour déployer Azure Virtual Network Manager (AVNM) avec Terraform.

Le Scénario

Nous allons créer une infrastructure Hub & Spoke automatisée :

• 3 VNets : 1 Hub et 2 Spokes.

• 1 Instance AVNM.

• 1 Groupe Réseau contenant les deux Spokes.

• 1 Configuration de Connectivité qui connecte automatiquement les Spokes au Hub.

• 1 Déploiement pour appliquer la configuration dans la région.

provider "azurerm" {
  features {}
}

data "azurerm_subscription" "current" {}

# 1. Création des ressources de base (Resource Group + VNets)
resource "azurerm_resource_group" "rg" {
  name     = "rg-avnm-demo"
  location = "West Europe"
}

resource "azurerm_virtual_network" "hub_vnet" {
  name                = "vnet-hub"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  address_space       = ["10.0.0.0/16"]
}

resource "azurerm_virtual_network" "spoke1_vnet" {
  name                = "vnet-spoke-01"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  address_space       = ["10.1.0.0/16"]
}

resource "azurerm_virtual_network" "spoke2_vnet" {
  name                = "vnet-spoke-02"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  address_space       = ["10.2.0.0/16"]
}

# 2. Instance Azure Virtual Network Manager
resource "azurerm_network_manager" "avnm" {
  name                = "avnm-prod"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  scope_accesses      = ["Connectivity", "SecurityAdmin"]
  description         = "Gestionnaire central pour le Hub & Spoke"

  scope {
    # On définit la portée sur la souscription courante
    subscription_ids = [data.azurerm_subscription.current.id]
  }
}

# 3. Création du Groupe Réseau (Network Group) pour les Spokes
resource "azurerm_network_manager_network_group" "spokes_group" {
  name               = "ng-spokes"
  network_manager_id = azurerm_network_manager.avnm.id
  description        = "Groupe contenant tous les réseaux spoke"
}

# 4. Ajout des membres (VNets) dans le groupe
# Note : En prod, on utiliserait souvent Azure Policy pour l'ajout dynamique.
# Ici, nous utilisons l'ajout statique pour la clarté de l'exemple.
resource "azurerm_network_manager_static_member" "spoke1_member" {
  network_group_id          = azurerm_network_manager_network_group.spokes_group.id
  target_virtual_network_id = azurerm_virtual_network.spoke1_vnet.id
}

resource "azurerm_network_manager_static_member" "spoke2_member" {
  network_group_id          = azurerm_network_manager_network_group.spokes_group.id
  target_virtual_network_id = azurerm_virtual_network.spoke2_vnet.id
}

# 5. Configuration de la Connectivité (Topology Hub & Spoke)
resource "azurerm_network_manager_connectivity_configuration" "hub_spoke_config" {
  name                  = "conf-hub-spoke"
  network_manager_id    = azurerm_network_manager.avnm.id
  connectivity_topology = "HubAndSpoke"

  # Définition du Hub
  hub {
    resource_id   = azurerm_virtual_network.hub_vnet.id
    resource_type = "Microsoft.Network/virtualNetworks"
  }

  # Définition des groupes concernés (les Spokes)
  applies_to_group {
    group_connectivity = "None" # Mettre "DirectlyConnected" pour que les spokes se parlent entre eux
    network_group_id   = azurerm_network_manager_network_group.spokes_group.id
  }
}

# 6. DÉPLOIEMENT (Commit) de la configuration
# C'est l'étape cruciale qui applique réellement les changements sur l'infrastructure Azure.
resource "azurerm_network_manager_deployment" "deploy_westeurope" {
  network_manager_id = azurerm_network_manager.avnm.id
  location           = "westeurope" # Région cible du déploiement
  scope_access       = "Connectivity"

  configuration_ids = [
    azurerm_network_manager_connectivity_configuration.hub_spoke_config.id
  ]

  # Astuce Terraform : On force le redéploiement si la config change
  triggers = {
    config_change = jsonencode(azurerm_network_manager_connectivity_configuration.hub_spoke_config)
  }

  depends_on = [
    azurerm_network_manager_static_member.spoke1_member,
    azurerm_network_manager_static_member.spoke2_member
  ]
}

Explication des blocs clés

1. azurerm_network_manager : C'est le cerveau. Notez le bloc scope. Ici, il gère une seule souscription, mais vous pouvez lister plusieurs IDs ou utiliser un Management Group pour une portée plus large.

2. azurerm_network_manager_static_member : Dans cet exemple, je lie explicitement les VNets au groupe. Dans un scénario avancé, vous utiliseriez une ressource Azure Policy pour dire "Tous les VNets avec le tag Role=Spoke vont dans ce groupe".

3. applies_to_group (dans la config) :

   • group_connectivity = "None" : Les spokes parlent au Hub, mais ne se parlent pas entre eux (isolation).

   • group_connectivity = "DirectlyConnected" : AVNM crée un maillage complet entre les spokes (utile si spoke A doit appeler spoke B sans passer par la NVA du hub).

4. azurerm_network_manager_deployment : Contrairement à d'autres ressources Azure, créer la configuration ne suffit pas. Il faut explicitement demander à AVNM de "pousser" (commit) cette config vers la région cible (ici westeurope). Sans ce bloc, vos peerings n'apparaîtront jamais.

Résultat après le terraform apply

Si vous allez sur le portail Azure après l'exécution :

1. Regardez le VNet Hub : vous verrez dans "Peerings" deux nouvelles connexions créées par AVNM.

2. Regardez les VNets Spokes : chacun aura un peering vers le Hub.

3. Si vous ajoutez un 3ème Spoke et créez un static_member pour lui, Terraform et AVNM créeront automatiquement le peering sans que vous ayez à toucher à la configuration du Hub.

Passer à l'adhésion dynamique

Le concept

Nous allons remplacer les ressources azurerm_network_manager_static_member par un duo Azure Policy Definition + Assignment.

L'architecture logique est la suivante :

1. Azure Policy détecte un VNet avec le bon Tag.

2. L'effet de la Policy est addToNetworkGroup.

3. Le VNet rejoint le groupe et hérite automatiquement de la connectivité (Peering Hub & Spoke).

Code Terraform (policy.tf)

Ce code s'ajoute à votre configuration précédente (en supprimant les blocs static_member).

# 1. Récupération des infos du Groupe Réseau (créé précédemment)
# On suppose que la ressource azurerm_network_manager_network_group.spokes_group existe déjà.

# 2. Définition de la Politique (La Règle)
resource "azurerm_policy_definition" "avnm_dynamic_membership" {
  name         = "policy-avnm-dynamic-spokes"
  policy_type  = "Custom"
  mode         = "All" # Important pour gérer les ressources réseau
  display_name = "Ajouter les VNets 'Prod' au groupe AVNM Spoke"
  description  = "Ajoute automatiquement les VNets avec le tag Env=Prod au groupe réseau."

  # La portée de la définition (ici la souscription courante)
  management_group_id = null 

  metadata = jsonencode({
    category = "Network"
  })

  # La logique "Si... Alors..."
  policy_rule = jsonencode({
    "if" : {
      "allOf" : [
        {
          "field" : "type",
          "equals" : "Microsoft.Network/virtualNetworks"
        },
        {
          # La condition clé : Le Tag 'Env' doit valoir 'Prod'
          "field" : "tags['Env']",
          "equals" : "Prod"
        }
      ]
    },
    "then" : {
      "effect" : "addToNetworkGroup",
      "details" : {
        "networkGroupId" : azurerm_network_manager_network_group.spokes_group.id
      }
    }
  })
}

# 3. Assignation de la Politique (L'Activation)
# C'est ce qui rend la règle active sur votre souscription
resource "azurerm_subscription_policy_assignment" "assign_avnm_policy" {
  name                 = "assign-avnm-spokes"
  policy_definition_id = azurerm_policy_definition.avnm_dynamic_membership.id
  subscription_id      = data.azurerm_subscription.current.id

  display_name = "Enrôlement auto des VNets Spokes"

  # Pour AVNM, on a souvent besoin d'une identité managée pour que la Policy
  # ait le droit de modifier le groupe réseau.
  identity {
    type = "SystemAssigned"
  }

  location = "westeurope"
}

# 4. Role Assignment (La Permission)
# L'identité de la Policy doit avoir le droit de contribuer au Network Manager
resource "azurerm_role_assignment" "policy_avnm_contrib" {
  scope                = azurerm_network_manager.avnm.id
  role_definition_name = "Network Contributor" # Ou un rôle custom plus restrictif
  principal_id         = azurerm_subscription_policy_assignment.assign_avnm_policy.identity[0].principal_id
}

Explications détaillées

1. policy_rule (JSON) :

   • C'est le cœur du système. La partie if vérifie que la ressource est un VNet ET qu'elle possède le tag Env: Prod.

   • La partie then utilise l'effet spécial addToNetworkGroup. C'est un effet spécifique à AVNM qui ne fait pas de "Deny" ou "Audit", mais qui injecte la ressource dans le groupe cible.

2. azurerm_subscription_policy_assignment :

   • Nous assignons cette règle à toute la souscription. Dès qu'un VNet est créé (ou modifié) n'importe où dans cette souscription avec le bon tag, la policy se déclenche.

3. azurerm_role_assignment (Crucial) :

   • C'est l'erreur la plus fréquente. L'assignation de policy crée une Managed Identity (SystemAssigned).

   • Cette identité a besoin de droits sur l'instance AVNM pour pouvoir dire "Hey, j'ai trouvé un nouveau VNet, ajoute-le au groupe !". Le rôle "Network Contributor" sur l'AVNM suffit.

Comment tester que ça marche ?

Une fois le terraform apply terminé :

1. Créez un nouveau VNet (via le portail ou Terraform) sans toucher à la config AVNM.

   Terraform

    resource "azurerm_virtual_network" "test_dynamic" {
      name                = "vnet-test-dynamic"
      # ... params standards ...
      tags = {
        Env = "Prod"  # <--- C'est ce tag qui déclenche la magie
      }
    }
   

2. Attendez quelques minutes (Azure Policy n'est pas instantané, cela prend entre 5 et 15 minutes pour l'évaluation).

3. Allez dans votre instance AVNM > Network Groups.

4. Vous verrez votre nouveau VNet apparaître dans les membres du groupe.

5. Grâce à la configuration de connectivité (Hub & Spoke) déjà en place, le peering se créera automatiquement peu après.

C'est la méthode idéale pour gérer des environnements éphémères tel que des environnements de développement qui naissent et meurent fréquemment.

Résumé de la tarification Azure Virtual Network Manager

La facturation de ce service repose sur trois composantes principales : la gestion des ressources, l'analyse de connectivité et la gestion des adresses IP.

1. Gestion du réseau (Frais de base)

Il existe deux modèles de facturation selon la date de création de votre instance ou votre configuration :

• Facturation basée sur le Réseau Virtuel (VNet) : C'est le modèle par défaut pour les nouvelles instances.

  • Coût : 0,02 $ / heure par réseau virtuel géré.

  • Estimation mensuelle : Environ 14,40 $ par mois pour un VNet actif 24h/24 (sur une base de 30 jours).

• Facturation basée sur l'Abonnement : Modèle par défaut pour les instances créées avant l'introduction de la facturation par VNet.

  • Coût : 0,10 $ / heure par abonnement géré (un abonnement est considéré "géré" s'il contient au moins un VNet avec une configuration AVNM active).

  • Estimation mensuelle : Environ 72 $ par abonnement par mois.

2. Network Verifier (Analyse de connectivité)

Pour vérifier si vos politiques réseau autorisent ou bloquent le trafic entre vos ressources :

• Coût : 0,10 $ par analyse de chemin d'accessibilité exécutée dans l'espace de travail du vérificateur.

3. IPAM (Gestion des adresses IP)

Si vous utilisez les fonctionnalités de gestion centralisée des adresses IP (IP Address Management) :

• Coût : 0,00027 $ / heure par adresse IP active gérée par le service.

4. Frais de transfert de données (Peering)

Il est important de noter qu'AVNM automatise la connectivité, mais il ne remplace pas les coûts de transfert de données :

• Les frais de VNet Peering habituels s'appliquent à tout le trafic transitant par les connexions créées par AVNM (environ 0,01 $/Go pour le peering intra-région, variable pour le peering global).

Conclusion

Azure Virtual Network Manager n'est pas nécessaire pour une petite start-up avec 3 VNets. Cependant, dès que vous adoptez une Landing Zone à l'échelle entreprise ou que vous dépassez la dizaine de réseaux virtuels, il devient un outil indispensable pour garantir que votre réseau reste gérable, performant et, surtout, sécurisé par défaut.