Schéma Azure Landing Zone : groupes de gestion, abonnements et réseau hub

La plupart des parcs Azure démarrent de la même façon. Quelqu'un crée un abonnement pour un pilote, puis un pour la production, puis chaque équipe obtient le sien. Deux ans plus tard, 40 abonnements sont rattachés au groupe racine du tenant, trois exploitent leurs propres passerelles VPN, une VM de base de données a une IP publique, et personne ne sait quelles politiques s'appliquent où.

Une Azure landing zone est le plan de référence de Microsoft pour éviter cela. Cet article passe en revue chaque élément avec un schéma : groupes de gestion, landing zones de plateforme et de workload, garde-fous de politique, hub-and-spoke ou Virtual WAN, identité et déploiement.

Ce qu'est une Azure landing zone

Le Cloud Adoption Framework (CAF) définit une Azure landing zone comme « une architecture éprouvée et flexible pour gouverner, sécuriser et faire évoluer un environnement Azure multi-abonnements » (Microsoft Learn). Elle comporte deux parties :

• La landing zone de plateforme : la hiérarchie des groupes de gestion plus les ressources partagées comme le réseau hub, la journalisation et les outils de sécurité. Microsoft en recommande une par tenant Microsoft Entra, exploitée par une équipe plateforme.
• Les landing zones de workload : une par workload, détenue par son équipe, regroupant chaque environnement (développement, test, production) sous la forme d'un ou plusieurs abonnements. Les documents plus anciens les appellent landing zones d'application.

L'abonnement est la brique de base : CAF l'appelle une unité de gestion, de facturation et de mise à l'échelle. En termes AWS, un abonnement correspond à peu près à un compte et un groupe de gestion à une unité d'organisation ; le schéma AWS landing zone montre ce côté.

La hiérarchie des groupes de gestion

Une attribution de politique ou de rôle sur un groupe de gestion s'applique à tout ce qui se trouve en dessous, et les propriétaires d'abonnement ne peuvent pas la modifier. Selon la documentation des groupes de gestion, Azure autorise 10 000 groupes de gestion par tenant, six niveaux sous la racine et un seul parent chacun.

La hiérarchie de référence, avec des notes tirées des attributions de politiques ALZ par défaut :

Trois règles du guide CAF sur les groupes de gestion évitent la plupart des refontes :

1. Gardez-la plate. Trois ou quatre niveaux suffisent ; n'ajoutez pas de groupes de gestion pour les régions ni pour le développement, le test et la production.
2. Assignez à la racine intermédiaire, pas à la racine du tenant. Les nouveaux abonnements arrivent par défaut sous la racine du tenant, et tout utilisateur peut créer des groupes de gestion tant que vous n'exigez pas d'autorisation. Changez les deux et faites de Sandbox la valeur par défaut.
3. Donnez aux équipes de workload des rôles à l'échelle de l'abonnement. Les équipes plateforme peuvent détenir des rôles sur des groupes de gestion, contrôlés par un accès juste-à-temps.

Les noms évoluent : Security a rejoint Platform en 2025, et la dernière vue d'ensemble de CAF utilise « Workload landing zones » pour Landing zones et « Internal » pour Corp.

Landing zones de plateforme et de workload

Avec le subscription vending, une demande, souvent une pull request, crée l'abonnement sous Corp ou Online, assigne des rôles et un budget et, pour Corp, ajoute un spoke en peering avec le hub. Microsoft publie des modules de vending pour Bicep et Terraform.

Garde-fous pilotés par la politique

Azure Policy transforme la hiérarchie en application des règles : assignez une règle une fois à un groupe de gestion, et chaque abonnement actuel et futur en dessous l'hérite.

Les règles de région demandent de l'attention : la politique intégrée Allowed locations ignore les groupes de ressources et l'emplacement global, donc associez-la à Allowed locations for resource groups, et commencez en mode DoNotEnforce pour voir ce qu'elle bloquerait :

az policy assignment create \
  --name allowed-locations \
  --scope /providers/Microsoft.Management/managementGroups/contoso \
  --policy e56962a6-4747-49cd-b67b-bf8b01975c4c \
  --params '{"listOfAllowedLocations": {"value": ["westeurope", "northeurope"]}}' \
  --enforcement-mode DoNotEnforce

Le calendrier compte : une nouvelle attribution s'applique en cinq minutes environ, un abonnement déplacé dans un groupe de gestion est évalué en 30 minutes environ, et une analyse complète s'exécute toutes les 24 heures. Les politiques DeployIfNotExists et Modify agissent sur les ressources nouvelles et mises à jour ; les ressources existantes demandent une tâche de correction.

Réseau : hub-and-spoke ou Virtual WAN

L'abonnement de connectivité possède le réseau partagé : Azure Firewall, passerelles VPN et ExpressRoute, Bastion, zones DNS privées et DNS Private Resolver. Le guide de topologie réseau de CAF propose deux conceptions :

Le peering n'est pas transitif : dans un réseau virtuel hub, chaque spoke reçoit donc une table de routage qui envoie 0.0.0.0/0 vers l'IP privée du pare-feu, le peering du hub autorise le gateway transit, et le peering du spoke utilise la passerelle distante ; l'article sur la topologie réseau hub-and-spoke détaille le routage. Azure Firewall Basic gère jusqu'à 250 Mbit/s, Standard 30 Gbit/s et Premium 100 Gbit/s. Pour Virtual WAN, choisissez le type Standard ; Basic ne prend en charge que le VPN site à site.

Le DNS est l'endroit où les équipes se trompent le plus souvent. Les zones DNS privées comme privatelink.blob.core.windows.net résident dans l'abonnement de connectivité, liées au hub, où DNS Private Resolver transfère vers Azure DNS à 168.63.129.16 ; les serveurs DNS sur site lui transfèrent des zones comme blob.core.windows.net. Une politique DeployIfNotExists dans Corp écrit l'enregistrement de chaque point de terminaison privé dans la zone centrale, si bien que les équipes de workload n'ont besoin d'aucun droit dessus.

Identité

Le tenant Microsoft Entra est la frontière d'identité. Les règles pratiques de CAF :

• Accordez aux équipes de workload des rôles sur leurs propres abonnements pendant le vending, jamais sur des groupes de gestion.
• Laissez les ingénieurs plateforme activer des rôles comme Owner via Privileged Identity Management (PIM), avec approbation et limite de durée.
• Appliquez l'accès conditionnel à tous ceux qui gèrent Azure, et conservez des comptes d'accès d'urgence surveillés.
• Utilisez l'abonnement d'identité pour les contrôleurs de domaine ou Microsoft Entra Domain Services si des workloads en ont encore besoin.

Le déployer

Au moment de la rédaction (novembre 2026), Microsoft recommande l'Azure Landing Zones IaC Accelerator : Bicep ou Terraform reposant sur les Azure Verified Modules (AVM). Son module PowerShell initialise un dépôt GitHub ou Azure DevOps, des pipelines avec approbations et des identités managées avec identifiants fédérés. Terraform utilise des modules distincts pour la hiérarchie et la politique (avm-ptn-alz), les ressources de gestion et chaque conception réseau ; Bicep utilise des deployment stacks, qui peuvent supprimer les ressources que vous retirez des modèles.

Les anciennes options disparaissent : le module Terraform caf-enterprise-scale est obsolète, et l'ALZ-Bicep classique a quitté l'accélérateur le 16 février 2026, son dépôt devant être archivé le 16 février 2027. Un accélérateur de portail subsiste, mais sans code il est difficile à mettre à jour.

Prévoyez le budget. La page de scénarios de l'accélérateur estime l'infrastructure fixe à environ 5 640 USD par mois pour un hub-and-spoke monorégion avec Azure Firewall, et 690 USD pour la variante petite entreprise, qui désactive entre autres le plan DDoS Network Protection (prix publics de westus d'avril 2026, hors trafic et journaux). Il vous faut aussi quatre abonnements de plateforme, ou deux dans la configuration petite entreprise.

Le schéma Azure landing zone

Comment le lire :

• L'arbre à gauche est la hiérarchie ; les flèches vont du parent à l'enfant, le sens de l'héritage.
• Le nœud de politique est accroché à la racine intermédiaire Contoso, pas au groupe racine du tenant, donc il atteint toute la landing zone et rien d'autre.
• Les couleurs montrent la propriété : bleu pour la plateforme, vert pour les workloads, ambre pour Sandbox, gris pour la racine et les abonnements retirés.
• Les liens en pointillés montrent l'emplacement : le hub vit dans l'abonnement de connectivité, et les deux spokes sont fournis dans Corp.
• Les liens pleins transportent le trafic : peering vers le hub et lien de passerelle vers le site ; chaque spoke route 0.0.0.0/0 vers le pare-feu à 10.0.0.4.
• Le bloc Markdown liste les limites clés.

Dessiner clairement des schémas Azure landing zone

• Dessinez la gouvernance et le réseau comme deux vues, reliées seulement là où vit un abonnement.
• Rattachez chaque politique là où elle est assignée, pour que les lecteurs voient quels workloads elle contraint.
• Montrez un ou deux abonnements d'exemple par groupe, pas un inventaire.
• Écrivez les plages d'adresses sur le hub et chaque spoke ; les chevauchements sont la première chose que les relecteurs vérifient.
• Évitez les erreurs classiques : peering dessiné comme transitif, workloads sous la racine du tenant, et régions ou environnements comme groupes de gestion.

Voir les schémas d'architecture cloud pour des nœuds cloud typés, et l'article sur le schéma d'architecture Terraform pour les parcs gérés avec Terraform.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez huit nœuds Ressource cloud du pack Cloud : Tenant root group, Contoso, Platform, Landing zones, Corp, Online, Sandbox et Decommissioned. Mettez chaque rôle dans la ligne du type de ressource et disposez-les en arbre indenté.
3. Reliez les parents aux enfants avec des liens orthogonaux et colorez les branches : bleu pour Platform, vert pour Landing zones, ambre pour Sandbox.
4. Ajoutez un nœud Politique du pack Sécurité nommé Azure Policy guardrails et reliez-le à Contoso.
5. Ajoutez un nœud VPC du pack Réseau pour le hub, avec un Routeur pour la passerelle et un Pare-feu à l'intérieur, et deux nœuds VPC pour les spokes, chacun avec une ligne Texte du pack Base pour sa route.
6. Tracez des liens en pointillés de Platform vers le hub et de Corp vers les spokes, des liens de peering vers le hub, et un lien de la passerelle vers une étiquette Texte pour le site.
7. Ajoutez un bloc Markdown du pack Base avec les limites.

Si votre landing zone est en Terraform, l'outil Terraform to diagram transforme les fichiers en première ébauche.

L'exemple utilise 15 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

Qu'est-ce qu'une Azure landing zone ? Un environnement Azure multi-abonnements construit selon les recommandations du Cloud Adoption Framework avant l'arrivée des workloads : groupes de gestion, garde-fous de politique, identité, journalisation et réseau partagé.

Quels groupes de gestion utilise une Azure landing zone ? Une racine intermédiaire sous le groupe racine du tenant, avec en dessous Platform (Management, Connectivity, Identity, Security), Landing zones (Corp, Online, Local), Sandbox et Decommissioned.

Quelle est la différence entre les landing zones Corp et Online ? Corp regroupe les workloads qui atteignent le réseau d'entreprise via le hub ; les valeurs par défaut y refusent donc les points de terminaison PaaS publics et les IP publiques sur les interfaces réseau. Online regroupe les workloads qui ont besoin d'un accès direct à Internet ou d'aucun réseau virtuel.

Faut-il utiliser hub-and-spoke ou Virtual WAN ? Un réseau virtuel hub convient à quelques régions, moins de 30 tunnels site à site et un contrôle total du routage ; Virtual WAN convient à de nombreuses régions et sites, au SD-WAN ou au transit VPN vers ExpressRoute.

Le module Terraform caf-enterprise-scale est-il toujours pris en charge ? Non. Il est obsolète et ne reçoit aucune mise à jour. Utilisez les Azure Verified Modules pour la landing zone de plateforme, généralement via l'accélérateur IaC ; Microsoft documente un chemin de migration.

Commencez gratuitement — un siège, sans carte bancaire.