Hanteringsgrupper och prenumerationer

Azure organiserar resurser i en hierarki på fyra nivåer. Högst upp finns Management Groups – containrar som grupperar prenumerationer för policy och åtkomstkontroll i stor skala. Under dem finns Subscriptions – enheter för fakturering och resursavgränsning. I prenumerationerna finns Resource Groups – logiska containrar för relaterade resurser. Längst ned finns Resources – enskilda tjänster som virtuella datorer, databaser och lagringskonton. Policyer och behörigheter som tillämpas på högre nivåer ärvs nedåt.

En Azure-prenumeration är både en faktureringsenhet och en logisk resursavgränsning. All resursanvändning i en prenumeration debiteras på en enda faktura. Prenumerationer anger gränser (kvoter) för hur många resurser av varje typ som kan distribueras. Organisationer skapar ofta separata prenumerationer för olika miljöer (Production, Development, Testing), olika affärsenheter eller olika geografiska regioner – var och en med egen kostnadsrapportering och åtkomstkontroll.

Stora företag använder flera prenumerationer av flera skäl. Isolering – produktionsresurser är helt isolerade från utveckling och test, så att en felkonfiguration i utvecklingsmiljön inte kan påverka produktionen. Detaljerad fakturering – varje avdelnings prenumeration genererar en egen faktura för tydlig kostnadsfördelning. Prenumerationsgränser – Azure har kvoter per prenumeration (t.ex. 250 virtuella datorer per region); stora arbetsbelastningar kan behöva flera prenumerationer för att hålla sig inom gränserna.

En Management Group är en behållare ovanför prenumerationerna i Azure-hierarkin. Ni kan organisera prenumerationer i hanteringsgrupper och tillämpa Azure Policy definitions och RBAC role assignments på hanteringsgruppsnivå. Dessa ärvs av alla prenumerationer och resurser i gruppen. Då behöver ni inte duplicera samma policy eller rolltilldelning i dussintals enskilda prenumerationer.

Hanteringsgrupper kan kapslas i upp till sex nivåer. Varje Azure-katalog har en enda Root Management Group högst upp, som alla andra hanteringsgrupper och prenumerationer ligger under. En typisk företagshierarki kan se ut så här: Root → Company → Platform → Production → Landing Zones → Individual Workload Subscriptions. Principer som tillämpas på Root-nivån påverkar alla prenumerationer i hela katalogen.

Åtkomstkontrolltilldelningar på alla nivåer i hierarkin ärvs nedåt. Om ni tilldelar en användare rollen Reader för en hanteringsgrupp får användaren automatiskt Reader-åtkomst till alla prenumerationer och resursgrupper inom den hanteringsgruppen. Detta arv är kumulativt — ni kan inte återkalla en ärvd behörighet på en lägre nivå (ni kan bara lägga till fler behörigheter). Deny-tilldelningar är undantaget: de blockerar åtgärder även när en rolltilldelning skulle tillåta dem.

På samma sätt gäller Azure Policy assignments på hanteringsgruppsnivå för alla prenumerationer, resursgrupper och resurser inom gruppen. Ett vanligt mönster är att tilldela en företagsgemensam baspolicy på rot- eller företagshanteringsgruppen för att upprätthålla standarder som tillåtna regioner, obligatoriska taggar eller nödvändiga diagnostikinställningar i hela organisationen, medan ägare av enskilda prenumerationer kan lägga till mer specifika principer längre ned utan att åsidosätta företagets baspolicy.

Azure-prenumerationer kan skapas, byta namn, avslutas och flyttas mellan hanteringsgrupper. När ni flyttar en prenumeration till en annan hanteringsgrupp ändras vilka principer och rolltilldelningar som gäller för den — policyändringar börjar omedelbart gälla för alla resurser i prenumerationen. När ni avslutar en prenumeration inaktiveras möjligheten att skapa resurser och alla resurser i den tas så småningom bort efter en respitstid. Därför bör denna åtgärd endast utföras efter noggrann planering.

Stora organisationer använder Azure genom faktureringsavtal som påverkar hur prenumerationerna struktureras. Ett Enterprise Agreement (EA) tillhandahåller prenumerationer under en registrering med ett centralt faktureringskonto för stora, avtalade inköp. Ett Microsoft Customer Agreement (MCA) är den moderna efterföljaren och erbjuder mer självbetjäning för hantering av prenumerationer. Med båda avtalen kan faktureringsprofiler och fakturasektioner användas för att gruppera prenumerationskostnader för olika avdelningar.

Varje Azure-prenumeration har service quotas — mjuka gränser för hur många resurser av varje typ som får finnas per region. Exempel på standardvärden är 20 000 vCPU:er per region, 980 resursgrupper per prenumeration och 800 hanterade diskar per prenumeration. När er arbetsbelastning närmar sig en kvot kan ni skicka in en begäran om kvotökning i Azure-portalen (Support + troubleshooting > New support request). För mycket stora utrullningar rekommenderar Microsoft att arbetsbelastningar fördelas över flera prenumerationer.

Microsoft rekommenderar flera metodtips för utformning av hanteringsgrupper. Undvik fler än tre till fyra kapslingsnivåer — för många nivåer gör felsökning av principer komplex. Skapa en dedikerad Platform-hanteringsgrupp för delade tjänster (identitet, anslutning och hantering), separat från arbetsbelastningar i landningszoner. Separera Production och Non-Production i olika hanteringsgrupper så att principer som endast gäller produktion (till exempel att inaktivera internetåtkomst) inte av misstag tillämpas på utvecklingsmiljöer.

I den här lektionen har ni lärt er att Azure-resurshierarkin går från hanteringsgrupper till prenumerationer, resursgrupper och resurser, att principer och RBAC-tilldelningar på hanteringsgruppsnivå ärvs nedåt till alla underordnade prenumerationer och att flera prenumerationer ger isolerad fakturering, separering av miljöer och en lösning på kvoter per prenumeration. Härnäst går vi igenom Azure Policy på djupet.