La governance in Azure non è un layer che si aggiunge alla fine: è la struttura portante su cui si appoggiano policy, RBAC, budget e sicurezza. In AZ-305 il compito ricorrente è tradurre un requisito organizzativo (“vogliamo separare produzione da sviluppo”, “ogni business unit fattura separatamente”) in una gerarchia di management group e in un modello di subscription coerente con le Azure landing zone del Cloud Adoption Framework (CAF).

Management group: il piano dell’ereditarietà

I management group formano un albero (fino a 6 livelli di profondità, escludendo il root tenant e le subscription) la cui unica funzione è propagare Azure Policy e RBAC verso il basso per ereditarietà. Il root management group deve restare quasi vuoto: qui vanno solo le assegnazioni davvero universali (es. policy di allowed locations, deny di risorse mai consentite), perché tutto ciò che assegni al root non è più derogabile senza eccezioni esplicite.

Il pattern autoritativo dell’Azure landing zone propone una gerarchia standard sotto il root:

  • Platform → subscription condivise: Identity (domain controller/Entra Connect), Management (Log Analytics, automation), Connectivity (hub VNet, Azure Firewall, ExpressRoute).
  • Landing zones → subscription applicative, tipicamente distinte in Corp (workload che richiedono connettività ibrida) e Online (workload esposti su internet, senza rotta on-premises).
  • Sandbox → ambiente libero per sperimentazione, isolato con policy restrittive sul networking.
  • Decommissioned → per il ciclo di vita delle subscription ritirate.

Perché questa forma? Separare Platform da Landing zones implementa il pilastro Security e Operational Excellence del Well-Architected Framework: il team piattaforma centralizza rete e identità con guardrail forti, mentre i team applicativi ricevono una subscription già conforme in cui hanno autonomia operativa (Owner/Contributor sul proprio scope) senza poter toccare il perimetro condiviso.

Il modello di subscription: per ambiente, BU o billing?

La subscription è il confine primario di isolamento, quota e (spesso) fatturazione. Le tre logiche di partizionamento non sono alternative rigide, ma vanno pesate:

  • Per ambiente (dev/test/prod): massimizza l’isolamento del blast radius e permette policy differenziate (es. deny di SKU costose in dev, backup obbligatori in prod). È la scelta raccomandata quando il requisito è separazione dei rischi e RBAC distinto per ambiente.
  • Per business unit: allinea la fatturazione e la delega ai confini organizzativi. Ottima quando ogni BU deve avere cost accountability e amministrazione indipendente.
  • Per billing/cost center: utile in enti con contabilità analitica stringente, ma da preferire tramite tag + Cost Management quando la sola esigenza è la reportistica, evitando di moltiplicare subscription solo per etichettare la spesa.

Il pattern più solido combina i primi due: management group per BU o per tipologia (Corp/Online), e sotto subscription separate per ambiente. Così l’ereditarietà di policy scende naturalmente e i limiti di scala (risorse per subscription, RU di rete) restano gestibili.

Il trade-off centrale: centralizzazione vs autonomia

Il cuore del design è bilanciare controllo della piattaforma e velocità dei team. Troppa centralizzazione (ogni deploy passa dal team platform) crea colli di bottiglia e viola Operational Excellence; troppa autonomia (ogni team gestisce la propria rete e le proprie identità) genera drift di sicurezza e costi. La risposta del CAF è il modello a guardrail: la piattaforma impone i confini via Policy (deny/deployIfNotExists per diagnostica, endpoint privati, tag obbligatori) e i team si muovono liberamente dentro quei confini. Il controllo è dichiarativo e scalabile, non manuale.

Trappole tipiche d’esame

  • Requisito: “policy applicata a tutte le subscription attuali e future di una divisione senza riassegnarla ogni volta” → assegna la policy al management group della divisione, non alle singole subscription; l’ereditarietà copre anche le subscription aggiunte in futuro.
  • Requisito: “isolare completamente produzione, con RBAC e quota separati” → usa subscription distinte per ambiente. Resource group e tag non forniscono un vero confine di quota/isolamento.
  • Scenario: gerarchia proposta con 8-9 livelli di management group → eccessiva profondità: massimo 6 livelli, e comunque una gerarchia piatta (2-3 livelli utili) è più manutenibile. La profondità complica il troubleshooting delle policy ereditate.
  • Requisito: “il team applicativo deve gestire i propri workload ma NON la rete condivisa” → separa platform landing zone (Connectivity, con RBAC ristretto) dalle application landing zone; concedi ai team ruoli solo sulla loro subscription.
  • Sintomo: proliferazione incontrollata di subscription per singoli progetti (“subscription sprawl”) → consolida con un modello ad archetipi (Corp/Online) e usa tag + Cost Management per la reportistica di costo, non nuove subscription per ogni cost center.