Administrasjonsgrupper og abonnementer

Azure organiserer ressurser i et hierarki på fire nivåer. Øverst finner du Management Groups – beholdere som grupperer abonnementer for policy- og tilgangsstyring i stor skala. Under disse finner du Subscriptions – enheter for fakturering og ressursavgrensning. I abonnementene finner du Resource Groups – logiske beholdere for relaterte ressurser. Nederst finner du Resources – individuelle tjenester som VM-er, databaser og lagringskontoer. Policyer og tillatelser som brukes på høyere nivåer, arves nedover i hierarkiet.

Et Azure-abonnement er både en faktureringsenhet og en logisk ressursavgrensning. All ressursbruk i et abonnement faktureres på én samlet faktura. Abonnementer setter grenser (kvoter) for hvor mange ressurser av hver type som kan distribueres. Organisasjoner oppretter ofte separate abonnementer for ulike miljøer (Produksjon, Utvikling, Testing), ulike forretningsenheter eller ulike geografiske regioner – hvert med egen kostnadsrapportering og tilgangsstyring.

Store virksomheter bruker flere abonnementer av flere grunner. Isolasjon – produksjonsressurser er fullstendig adskilt fra utviklings- og testmiljøer, slik at en feilkonfigurasjon i utviklingsmiljøet ikke kan påvirke produksjonen. Detaljert fakturering – hvert avdelingsabonnement genererer sin egen faktura, noe som gir tydelig kostnadsfordeling. Abonnementsgrenser – Azure har kvoter per abonnement (for eksempel 250 VM-er per region), og store arbeidsbelastninger kan kreve flere abonnementer for å holde seg innenfor grensene.

En administrasjonsgruppe er en beholder over abonnementer i Azure-hierarkiet. Du kan organisere abonnementer i administrasjonsgrupper og bruke Azure Policy-definisjoner og RBAC-rolletilordninger på administrasjonsgruppenivå. Disse arves av alle abonnementer og ressurser i gruppen. Dermed slipper du å duplisere den samme policyen eller roll تildelingen på tvers av dusinvis av individuelle abonnementer.

Administrasjonsgrupper kan nestes opptil seks nivåer dypt. Hver Azure-katalog har én enkelt rotadministrasjonsgruppe øverst, som alle andre administrasjonsgrupper og abonnementer ligger under. Et typisk virksomhetshierarki kan være: Rot → Selskap → Plattform → Produksjon → Landingssone → Individuelle arbeidsbelastningsabonnementer. Policyer som brukes på rotnivå, påvirker alle abonnementer i hele katalogen.

Tilordninger for tilgangskontroll på alle nivåer i hierarkiet arves nedover. Hvis du tildeler en bruker rollen Reader på en administrasjonsgruppe, får brukeren automatisk Reader-tilgang til alle abonnementer og ressursgrupper i administrasjonsgruppen. Dette arvet er additivt – du kan ikke tilbakekalle en arvet tillatelse på et lavere omfang (du kan bare legge til flere tillatelser). Deny-tilordninger er unntaket: De blokkerer handlinger selv når en roll etildeling ellers ville tillatt dem.

Tilsvarende gjelder at Azure Policy-tilordninger på administrasjonsgruppenivå brukes på alle abonnementer, ressursgrupper og ressurser i gruppen. Et vanlig mønster er å tilordne en policy for virksomhetens grunnlinje på rot- eller selskapsnivå for å håndheve standarder som tillatte områder, obligatoriske koder eller nødvendige diagnostikkinnstillinger i hele organisasjonen, mens eiere av individuelle abonnementer kan legge til mer spesifikke policyer på lavere nivå uten å overstyre virksomhetens grunnlinje.

Azure-abonnementer kan opprettes, gis nytt navn, avsluttes og flyttes mellom administrasjonsgrupper. Flytting av et abonnement til en annen administrasjonsgruppe endrer hvilke policyer og roll etildelinger som gjelder for det – policyendringer trer umiddelbart i kraft for alle ressurser i abonnementet. Avslutning av et abonnement deaktiverer oppretting av ressurser og sletter til slutt alle ressurser i det etter en karensperiode. Denne handlingen bør derfor bare utføres etter grundig planlegging.

Store organisasjoner bruker Azure gjennom faktureringsavtaler som påvirker hvordan abonnementene struktureres. En Enterprise Agreement (EA) tilbyr abonnementer under en registrering med en sentral faktureringskonto for store, forpliktede utgifter. En Microsoft Customer Agreement (MCA) er den moderne etterfølgeren og tilbyr mer selvbetjent administrasjon av abonnementer. Med begge avtalene kan faktureringsprofiler og fakturaseksjoner brukes til å gruppere abonnements kostnader for ulike avdelinger.

Hvert Azure-abonnement har tjenestekvoter – myke grenser for hvor mange ressurser av hver type som kan finnes per område. Eksempler på standardverdier er 20 000 vCPU-er per område, 980 ressursgrupper per abonnement og 800 administrerte disker per abonnement. Når arbeidsbelastningen nærmer seg en kvote, kan du sende inn en forespørsel om kvoteøkning i Azure-portalen (Support + feilsøking > Ny støtteforespørsel). For svært stor utskalering anbefaler Microsoft å fordele arbeidsbelastninger på flere abonnementer.

Microsoft anbefaler flere beste praksiser for utforming av administrasjonsgrupper. Unngå mer enn tre til fire nivåer med nesting – for mange nivåer gjør feilsøking av policyer komplisert. Opprett en dedikert Platform-administrasjonsgruppe for delte tjenester (identitet, tilkobling og administrasjon), atskilt fra arbeidsbelastninger i landingssoner. Skill Produksjon og Ikke-produksjon i ulike administrasjonsgrupper, slik at policyer som bare gjelder produksjon (for eksempel deaktivering av offentlig internettilgang) ikke ved en feil brukes på utviklingsmiljøer.

I denne leksjonen lærte du at Azure-ressurshierarkiet går fra administrasjonsgrupper til abonnementer, ressursgrupper og ressurser, at policyer og RBAC-tilordninger på administrasjonsgruppenivå arves nedover til alle underordnede abonnementer, og at flere abonnementer gir isolasjon av fakturering, separasjon av miljøer og en løsning på kvoter per abonnement. Neste tema er Azure Policy i detalj.