Groupes de gestion et abonnements

Azure organise les ressources selon une hiérarchie à quatre niveaux. Au sommet se trouvent les groupes de gestion, des conteneurs qui regroupent les abonnements afin d’appliquer des stratégies et de contrôler les accès à grande échelle. Viennent ensuite les abonnements, qui constituent des unités de facturation et des limites de ressources. Au sein des abonnements se trouvent les groupes de ressources, des conteneurs logiques pour les ressources associées. Enfin, au niveau inférieur se trouvent les ressources, c’est-à-dire les services individuels tels que les VM, les bases de données et les comptes de stockage. Les stratégies et les autorisations appliquées aux niveaux supérieurs se propagent vers les niveaux inférieurs.

Un abonnement Azure est à la fois une unité de facturation et une limite logique de ressources. Toute l’utilisation des ressources d’un abonnement est facturée sur une seule facture. Les abonnements définissent des limites (quotas) concernant le nombre de ressources de chaque type pouvant être déployées. Les organisations créent généralement des abonnements distincts pour différents environnements (Production, développement et test), différentes unités opérationnelles ou différentes régions géographiques, chacun disposant de ses propres rapports de coûts et contrôles d’accès.

Les grandes entreprises utilisent plusieurs abonnements pour diverses raisons. Isolation : les ressources de production sont complètement isolées de celles de développement et de test ; une mauvaise configuration dans l’environnement de développement ne peut pas affecter la production. Granularité de la facturation : l’abonnement de chaque service génère sa propre facture, ce qui facilite la répartition précise des coûts. Limites des abonnements : Azure applique des quotas par abonnement (par exemple, 250 VM par région) ; les charges de travail importantes peuvent nécessiter plusieurs abonnements pour rester dans les limites.

Un groupe de gestion est un conteneur situé au-dessus des abonnements dans la hiérarchie Azure. Vous pouvez organiser les abonnements en groupes de gestion et appliquer des définitions de Policy Azure ainsi que des attributions de rôles RBAC au niveau du groupe de gestion. Ces éléments se propagent à chaque abonnement et ressource du groupe. Cela évite de devoir dupliquer la même stratégie ou attribution de rôle dans des dizaines d’abonnements individuels.

Les groupes de gestion peuvent être imbriqués sur six niveaux maximum. Chaque annuaire Azure possède un unique Root au sommet, sous lequel se trouvent tous les autres groupes de gestion et abonnements. Une hiérarchie d’entreprise classique peut être la suivante : Root → Company → Platform → Production → Landing Zones → abonnements de charges de travail individuels. Les stratégies appliquées au niveau de Root affectent chaque abonnement de l’ensemble de l’annuaire.

Les attributions de contrôle d’accès à n’importe quel niveau de la hiérarchie sont héritées vers les niveaux inférieurs. Si vous attribuez le rôle Reader à un utilisateur sur un groupe de gestion, celui-ci obtient automatiquement un accès Reader à chaque abonnement et groupe de ressources de ce groupe de gestion. Cet héritage est cumulatif : vous ne pouvez pas révoquer une autorisation héritée à une portée inférieure (vous pouvez uniquement ajouter des autorisations). Les attributions de refus constituent l’exception : elles bloquent les actions même lorsqu’une attribution de rôle les autoriserait.

De même, les attributions de Azure Policy au niveau d’un groupe de gestion s’appliquent à tous les abonnements, groupes de ressources et ressources de ce groupe. Une pratique courante consiste à attribuer une stratégie de référence d’entreprise au niveau de Root ou du groupe de gestion Company afin d’imposer des normes telles que les régions autorisées, les balises obligatoires ou les paramètres de diagnostic requis dans toute l’organisation, tandis que les propriétaires d’abonnements individuels peuvent ajouter des stratégies plus spécifiques aux niveaux inférieurs sans remplacer la référence d’entreprise.

Les abonnements Azure peuvent être créés, renommés, annulés et déplacés entre des groupes de gestion. Le déplacement d’un abonnement vers un autre groupe de gestion modifie les stratégies et attributions de rôles qui lui sont appliquées ; les changements de stratégie prennent immédiatement effet sur toutes les ressources de l’abonnement. L’annulation d’un abonnement désactive la création de ressources et finit par supprimer toutes les ressources qu’il contient après une période de grâce. Cette action ne doit donc être entreprise qu’après une planification rigoureuse.

Les grandes organisations accèdent à Azure par l’intermédiaire d’accords de facturation qui influencent la structure des abonnements. Un accord Entreprise (EA) fournit des abonnements dans le cadre d’une inscription associée à un compte de facturation central pour des dépenses importantes engagées. Un contrat client Microsoft (MCA) lui succède dans sa version moderne et offre davantage de gestion des abonnements en libre-service. Dans les deux cas, les profils de facturation et les sections de facture permettent de regrouper les frais d’abonnement pour différents services.

Chaque abonnement Azure possède des quotas de service, c’est-à-dire des limites souples du nombre de ressources de chaque type pouvant exister par région. Exemples par défaut : 20 000 vCPUs par région, 980 groupes de ressources par abonnement et 800 disques managés par abonnement. Lorsque votre charge de travail approche d’un quota, vous pouvez envoyer une demande d’augmentation de quota dans le portail Azure (Support + résolution des problèmes > Nouvelle demande de support). Pour un déploiement à très grande échelle, Microsoft recommande de répartir les charges de travail entre plusieurs abonnements.

Microsoft recommande plusieurs bonnes pratiques pour la conception des groupes de gestion. Évitez plus de trois ou quatre niveaux d’imbrication : un nombre de niveaux trop élevé complexifie le diagnostic des stratégies. Créez un groupe de gestion Platform dédié aux services partagés (identité, connectivité et gestion), séparé des charges de travail des Landing Zones. Séparez Production et NonCompliant dans des groupes de gestion différents afin que les stratégies réservées à la production (comme la désactivation de l’accès Internet public) ne s’appliquent pas accidentellement aux environnements de développement.

Testez votre compréhension des concepts fondamentaux de Microsoft Azure (AZ-900) abordés dans cette leçon.

Dans cette leçon, vous avez appris que la hiérarchie des ressources Azure va des groupes de gestion aux abonnements, puis aux groupes de ressources et enfin aux ressources, que les stratégies et attributions RBAC au niveau des groupes de gestion sont héritées par tous les abonnements enfants, et que plusieurs abonnements permettent d’isoler la facturation, de séparer les environnements et de contourner les quotas propres à chaque abonnement. Nous allons maintenant étudier Azure Policy en détail.