Gruppi di gestione e sottoscrizioni

Azure organizza le risorse in una gerarchia a quattro livelli. Al livello superiore si trovano i Management Groups, contenitori che raggruppano le sottoscrizioni per gestire criteri e accessi su larga scala. Seguono le Subscriptions, che costituiscono unità di fatturazione e confini delle risorse. All'interno delle sottoscrizioni si trovano i Resource Groups, contenitori logici per risorse correlate. Al livello inferiore ci sono le Resources, ovvero singoli servizi come VM, database e account di archiviazione. I criteri e le autorizzazioni applicati ai livelli superiori si propagano verso il basso.

Una sottoscrizione Azure è sia un'unità di fatturazione sia un confine logico per le risorse. Tutto l'utilizzo delle risorse di una sottoscrizione viene addebitato in un'unica fattura. Le sottoscrizioni stabiliscono limiti (quote) al numero di risorse di ogni tipo che è possibile distribuire. Le organizzazioni creano spesso sottoscrizioni separate per ambienti diversi (Produzione, Sviluppo, Test), diverse unità aziendali o diverse aree geografiche, ciascuna con una propria reportistica dei costi e un proprio controllo degli accessi.

Le grandi aziende utilizzano più sottoscrizioni per diversi motivi. Isolamento: le risorse di produzione sono completamente isolate da quelle di sviluppo e test; una configurazione errata nell'ambiente di sviluppo non può influire sulla produzione. Granularità della fatturazione: la sottoscrizione di ogni reparto genera una propria fattura, facilitando un'allocazione chiara dei costi. Limiti delle sottoscrizioni: Azure applica quote per sottoscrizione (ad esempio 250 VM per area); i carichi di lavoro di grandi dimensioni possono richiedere più sottoscrizioni per rimanere entro i limiti.

Un Management Group è un contenitore che si trova al di sopra delle sottoscrizioni nella gerarchia di Azure. È possibile organizzare le sottoscrizioni in gruppi di gestione e applicare Azure Policy definitions e RBAC role assignments a livello di gruppo di gestione. Queste impostazioni vengono ereditate da ogni sottoscrizione e risorsa all'interno del gruppo. In questo modo non è necessario duplicare la stessa policy o assegnazione di ruolo in decine di sottoscrizioni individuali.

I gruppi di gestione possono essere nidificati fino a sei livelli di profondità. Ogni directory di Azure ha un singolo Root Management Group al vertice, da cui dipendono tutti gli altri gruppi di gestione e le sottoscrizioni. Una gerarchia aziendale tipica potrebbe essere: Root → Company → Platform → Production → Landing Zones → Individual Workload Subscriptions. Le policy applicate a livello Root hanno effetto su ogni sottoscrizione dell'intera directory.

Le assegnazioni di controllo degli accessi a qualsiasi livello della gerarchia vengono ereditate verso il basso. Se assegna a un utente il ruolo Reader su un gruppo di gestione, l'utente ottiene automaticamente l'accesso Reader a ogni sottoscrizione e gruppo di risorse all'interno di quel gruppo di gestione. Questa ereditarietà è cumulativa: non è possibile revocare un'autorizzazione ereditata a un ambito inferiore (è possibile solo aggiungere altre autorizzazioni). Le assegnazioni di negazione costituiscono un'eccezione: bloccano le azioni anche quando un'assegnazione di ruolo le consentirebbe.

Analogamente, le Azure Policy assignments a livello di gruppo di gestione si applicano a tutte le sottoscrizioni, i gruppi di risorse e le risorse all'interno di quel gruppo. Un modello comune consiste nell'assegnare una corporate baseline policy a livello Root o del gruppo di gestione aziendale, per imporre standard come aree consentite, tag obbligatori o impostazioni diagnostiche necessarie in tutta l'organizzazione, mentre i proprietari delle singole sottoscrizioni possono aggiungere policy più specifiche ai livelli inferiori senza sostituire la baseline aziendale.

Le sottoscrizioni di Azure possono essere create, rinominate, annullate e spostate tra gruppi di gestione. Spostare una sottoscrizione in un altro gruppo di gestione modifica le policy e le assegnazioni di ruolo che vi si applicano: le modifiche alle policy hanno effetto immediato su tutte le risorse della sottoscrizione. Annullare una sottoscrizione disabilita la creazione di risorse e, al termine di un periodo di tolleranza, elimina tutte le risorse al suo interno; questa operazione deve quindi essere eseguita solo dopo un'attenta pianificazione.

Le grandi organizzazioni accedono ad Azure tramite contratti di fatturazione che influiscono sulla struttura delle sottoscrizioni. Un Enterprise Agreement (EA) fornisce sottoscrizioni nell'ambito di un'iscrizione con un account di fatturazione centralizzato, destinato a grandi volumi di spesa impegnata. Un Microsoft Customer Agreement (MCA) è il successore moderno e offre una gestione self-service delle sottoscrizioni più ampia. In entrambi i casi, i profili di fatturazione e le sezioni delle fatture consentono di raggruppare gli addebiti delle sottoscrizioni per i diversi reparti.

Ogni sottoscrizione di Azure dispone di service quotas, ovvero limiti flessibili sul numero di risorse di ciascun tipo che possono esistere per area. Esempi predefiniti: 20.000 vCPU per area, 980 gruppi di risorse per sottoscrizione e 800 dischi gestiti per sottoscrizione. Quando il carico di lavoro si avvicina a una quota, è possibile inviare una quota increase request nel portale di Azure (Support + troubleshooting > New support request). Per aumentare il numero di risorse su larga scala, Microsoft consiglia di distribuire i carichi di lavoro su più sottoscrizioni.

Microsoft consiglia diverse procedure per la progettazione dei gruppi di gestione. Eviti più di tre o quattro livelli di nidificazione: un numero eccessivo di livelli rende complessa la risoluzione dei problemi relativi alle policy. Crei un gruppo di gestione Platform dedicato ai servizi condivisi (identità, connettività e gestione), separato dai carichi di lavoro delle landing zone. Separi Production e Non-Production in gruppi di gestione diversi, in modo che le policy destinate solo alla produzione (come la disabilitazione dell'accesso a Internet pubblico) non vengano applicate accidentalmente agli ambienti di sviluppo.

Verifichi la Sua comprensione dei concetti di Microsoft Azure Fundamentals (AZ-900) trattati in questa lezione.

In questa lezione ha imparato che: la gerarchia delle risorse di Azure va dai gruppi di gestione alle sottoscrizioni, ai gruppi di risorse e infine alle risorse, le policy e le assegnazioni RBAC a livello di gruppo di gestione vengono ereditate verso il basso da tutte le sottoscrizioni figlie e più sottoscrizioni offrono isolamento della fatturazione, separazione degli ambienti e una soluzione alternativa alle quote per sottoscrizione. Ora approfondiremo Azure Policy.