Managementgroepen en subscriptions

Azure organiseert resources in een hiërarchie met vier niveaus. Bovenaan staan Management Groups — containers waarin abonnementen worden gegroepeerd voor beleid en toegangsbeheer op grote schaal. Daaronder staan Subscriptions — eenheden voor facturering en resourcegrenzen. Binnen abonnementen staan Resource Groups — logische containers voor gerelateerde resources. Onderaan staan Resources — afzonderlijke services zoals VM's, databases en opslagaccounts. Beleid en machtigingen die op hogere niveaus worden toegepast, worden naar beneden doorgegeven.

Een Azure-abonnement is zowel een factureringseenheid als een logische resourcegrens. Al het resourcegebruik binnen een abonnement wordt op één factuur in rekening gebracht. Met abonnementen worden limieten (quota) ingesteld voor het aantal resources van elk type dat kan worden geïmplementeerd. Organisaties maken vaak afzonderlijke abonnementen voor verschillende omgevingen (Productie, Ontwikkeling, Testen), verschillende bedrijfseenheden of verschillende geografische regio's — elk met eigen kostenrapportage en toegangsbeheer.

Grote ondernemingen gebruiken om verschillende redenen meerdere abonnementen. Isolatie — productieresources zijn volledig gescheiden van ontwikkel- en testresources; een verkeerde configuratie in de ontwikkelomgeving kan de productie niet beïnvloeden. Gedetailleerde facturering — het abonnement van elke afdeling genereert een eigen factuur voor duidelijke kostentoewijzing. Abonnementslimieten — Azure heeft quota per abonnement (bijvoorbeeld 250 VM's per regio); voor grote workloads kunnen meerdere abonnementen nodig zijn om binnen de limieten te blijven.

Een beheergroep is een container boven abonnementen in de Azure-hiërarchie. Je kunt abonnementen ordenen in beheergroepen en Azure Policy-definities en RBAC-roltoewijzingen toepassen op het niveau van de beheergroep. Deze worden doorgegeven aan elk abonnement en elke resource binnen de groep. Hierdoor hoef je hetzelfde beleid of dezelfde roltoewijzing niet te dupliceren voor tientallen afzonderlijke abonnementen.

Beheergroepen kunnen maximaal zes niveaus diep worden genest. Elke Azure-directory heeft bovenaan één hoofdbeheergroep, waaronder alle andere beheergroepen en abonnementen vallen. Een typische hiërarchie voor een grote organisatie kan er als volgt uitzien: Root → Company → Platform → Production → Landing Zones → afzonderlijke workloadabonnementen. Beleid dat op het niveau van Root wordt toegepast, heeft gevolgen voor elk abonnement in de hele directory.

Toegangsbeheer-toewijzingen op elk niveau in de hiërarchie worden naar onderliggende niveaus overgeërfd. Als je een gebruiker de rol Reader toewijst aan een beheergroep, krijgt die gebruiker automatisch Reader-toegang tot elk abonnement en elke resourcegroep binnen die beheergroep. Deze overerving is cumulatief: je kunt een overgeërfde machtiging niet intrekken op een lager bereik; je kunt alleen meer machtigingen toevoegen. Weigeringstoewijzingen vormen de uitzondering: deze blokkeren acties, zelfs wanneer een roltoewijzing ze zou toestaan.

Op dezelfde manier zijn Azure Policy-toewijzingen op het niveau van een beheergroep van toepassing op alle abonnementen, resourcegroepen en resources binnen die groep. Een gebruikelijk patroon is om op het niveau van Root of de bedrijfsbeheergroep een beleidsbasislijn voor de organisatie toe te wijzen, zodat standaarden zoals toegestane regio's, verplichte tags of vereiste diagnostische instellingen in de hele organisatie worden afgedwongen. Eigenaren van afzonderlijke abonnementen kunnen daaronder specifiekere beleidsregels toevoegen zonder de beleidsbasislijn van de organisatie te overschrijven.

Azure-abonnementen kunnen worden gemaakt, hernoemd, geannuleerd en tussen beheergroepen worden verplaatst. Een abonnement verplaatsen naar een andere beheergroep verandert welk beleid en welke roltoewijzingen erop van toepassing zijn. Beleidswijzigingen worden onmiddellijk van kracht voor alle resources in het abonnement. Een abonnement annuleren voorkomt het maken van resources en verwijdert uiteindelijk alle resources erin na afloop van een respijtperiode. Voer deze actie daarom alleen uit na zorgvuldige planning.

Grote organisaties gebruiken Azure via factureringsovereenkomsten die bepalen hoe abonnementen zijn ingericht. Een Enterprise Agreement (EA) biedt abonnementen binnen een inschrijving met een centraal factureringsaccount voor grote toegezegde uitgaven. Een Microsoft Customer Agreement (MCA) is de moderne opvolger hiervan en biedt meer mogelijkheden voor zelfbeheer van abonnementen. Bij beide overeenkomsten kun je met factureringsprofielen en factuursecties abonnementskosten voor verschillende afdelingen groeperen.

Elk Azure-abonnement heeft servicequota: zachte limieten voor het aantal resources van elk type dat per regio mag bestaan. Voorbeelden van standaardwaarden zijn: 20.000 vCPU's per regio, 980 resourcegroepen per abonnement en 800 beheerde schijven per abonnement. Wanneer je workload een quotum nadert, kun je in de Azure-portal een aanvraag voor quota-uitbreiding indienen (Support + probleemoplossing > Nieuwe ondersteuningsaanvraag). Voor grootschalige uitbreiding raadt Microsoft aan workloads over meerdere abonnementen te verdelen.

Microsoft raadt verschillende aanbevolen procedures aan voor het ontwerpen van beheergroepen. Gebruik niet meer dan drie tot vier geneste niveaus: te veel niveaus maken het oplossen van beleidsproblemen complex. Maak een speciale Platform-beheergroep voor gedeelde services (identiteit, connectiviteit en beheer), los van workloads in landingszones. Scheid productie en niet-productie in verschillende beheergroepen, zodat beleid dat alleen voor productie bedoeld is (zoals het uitschakelen van openbare internettoegang) niet per ongeluk op ontwikkelomgevingen wordt toegepast.

In deze les heb je geleerd dat de hiërarchie van Azure-resources loopt van beheergroepen naar abonnementen, resourcegroepen en resources, dat beleid en RBAC-toewijzingen op het niveau van een beheergroep naar beneden worden overgeërfd door alle onderliggende abonnementen en dat meerdere abonnementen zorgen voor scheiding van facturering en omgevingen en een oplossing bieden voor quota per abonnement. Hierna gaan we dieper in op Azure Policy.