• Cloud, Guide
• 30 Dicembre 2025

Gli Azure Service Groups sono un concetto logico e organizzativo utilizzato nell’ambito di Microsoft Azure per rappresentare un servizio applicativo nel suo complesso, andando oltre il semplice contenitore tecnico delle risorse. Quando parlate di Service Group, non vi riferite a un oggetto che create o distribuite direttamente nel portale Azure, ma a un modello che vi aiuta a strutturare responsabilità, governance e operatività attorno a un servizio.

Partendo da qui, potete considerare un Service Group come la vista “di servizio” di un’applicazione o di un workload. Al suo interno rientrano tutti i componenti necessari a erogare valore: applicazioni, database, integrazioni, sicurezza, monitoraggio e processi operativi. Questi componenti possono essere distribuiti su più Resource Group, sottoscrizioni o persino regioni diverse, ma dal vostro punto di vista fanno parte di un unico servizio coerente.

Utilizzando i Service Groups riuscite a separare chiaramente il piano tecnico dal piano organizzativo. I Resource Group vi servono per gestire il ciclo di vita delle risorse, mentre i Service Groups vi permettono di definire chi è responsabile del servizio, quali sono gli SLA, quali policy si applicano e come vengono gestiti incidenti e cambiamenti. Questo approccio è particolarmente utile quando operate in contesti enterprise, con molti team e numerosi workload, perché vi consente di mantenere una visione chiara e condivisa di ciò che ogni servizio rappresenta per il business.

Dal punto di vista operativo, i Service Groups diventano un punto di riferimento per DevOps e ITSM. Vi aiutano a coordinare i rilasci, a correlare alert e metriche, e a gestire gli incidenti non a livello di singola risorsa, ma a livello di servizio. In questo modo ragionate in termini di impatto sul cliente o sull’utente finale, invece che su singoli componenti infrastrutturali.

In sintesi, quando adottate gli Azure Service Groups state introducendo un livello di astrazione superiore, che vi consente di governare ambienti Azure complessi in modo strutturato, allineando tecnologia, organizzazione e processi operativi.

Figura 1: Diagramma ufficiale Azure Service Groups

Che differenze ci sono tra service group, management group e resource group?

Nel modello di governance di Microsoft Azure convivono tre concetti distinti che spesso vengono confusi perché operano a livelli diversi: Service Group, Management Group e Resource Group. La differenza fondamentale sta nello scopo, nel livello di astrazione e nel tipo di responsabilità che ciascuno di essi rappresenta.

Il Resource Group è il livello più concreto e tecnico. Quando lavorate con Azure nel quotidiano, è il contenitore che usate per distribuire e gestire le risorse: macchine virtuali, App Service, database, storage. Tutte le risorse contenute condividono lo stesso ciclo di vita, quindi se eliminate il Resource Group eliminate anche tutto ciò che contiene. Qui operate soprattutto in termini di deployment, configurazione e costi.

Il Management Group si colloca invece a un livello superiore e ha uno scopo di governance globale. Lo utilizzate per organizzare più sottoscrizioni Azure secondo una struttura gerarchica che riflette l’organizzazione aziendale, le unità di business o gli ambienti. A questo livello definite policy, controlli di sicurezza e assegnazioni di ruolo che si propagano automaticamente alle sottoscrizioni sottostanti. Non contiene risorse, ma sottoscrizioni. Gestire le sottoscrizioni Azure con gli Azure Management Groups – ICT Power

Il Service Group, infine, non è un contenitore tecnico nativo di Azure, ma un concetto logico e organizzativo. Quando parlate di Service Group, state ragionando in termini di servizio applicativo end-to-end. Un Service Group rappresenta tutto ciò che concorre a erogare un servizio: componenti applicativi, dati, integrazioni, sicurezza e processi operativi. Questi elementi possono essere distribuiti su più Resource Group, più sottoscrizioni e quindi anche sotto Management Group diversi, ma dal vostro punto di vista costituiscono un unico servizio con una chiara ownership, SLA e modello operativo.

In pratica, quando progettate un ambiente enterprise maturo, usate i Management Group per imporre regole comuni e garantire conformità, i Resource Group per gestire le risorse in modo operativo, e i Service Group per mantenere una visione chiara del servizio così come viene percepito dal business e dagli utenti finali. Ogni livello risponde a una domanda diversa: il Management Group definisce “quali regole valgono”, il Resource Group risponde a “dove e come vivono le risorse”, il Service Group chiarisce “che servizio stiamo erogando e chi ne è responsabile”.

Creazione degli Azure Service Groups

Dal portale di Azure cercate Service Groups. Dalla vista Service groups potete visualizzare l’elenco dei Service Group presenti nel tenant, incluso il Tenant root service group. Per creare un nuovo Service Group fate clic su + Create service group

Figura 2: Schermata iniziale dei Service Groups nel portale Azure, con il pulsante “Create service group” per avviare la creazione di un nuovo Service Group

Nella sezione Basics definite le informazioni principali del Service Group, inclusi il nome tecnico, il nome visualizzato e il Service Group padre a cui verrà associato, tipicamente il Tenant root service group. È inoltre possibile inserire una descrizione per documentare lo scopo del servizio.

Figura 3: Configurazione delle informazioni di base per la creazione di un nuovo Service Group nel portale Azure (sezione Basics)

Nella sezione Members potete definire i membri del Service Group, aggiungendo risorse, Resource Group o sottoscrizioni tramite l’azione Add members. In questo modo stabilite le relazioni che collegano i componenti tecnici al servizio applicativo rappresentato dal Service Group.

Figura 4: Sezione Members della creazione di un Service Group, utilizzata per associare risorse, Resource Group o sottoscrizioni al servizio

Aggiungete tutte le sottoscrizioni, i Resource Group e singole risorse Azure. In questo modo il Service Group rappresenta in maniera esplicita tutti gli elementi che contribuiscono all’erogazione del servizio.

Figura 5: Elenco dei membri associati a un Service Group, con risorse, Resource Group e sottoscrizioni collegati al servizio

Verificate il riepilogo delle informazioni configurate, inclusi i dettagli di base e il numero di membri associati, prima di confermare definitivamente la creazione del Service Group tramite il pulsante Create.

Figura 6: Schermata di riepilogo e conferma per la creazione del Service Group, con validazione finale delle configurazioni prima della creazione

La figura sotto mostra la vista Overview di un Service Group appena creato nel portale Azure. Dopo alcuni secondi dalla conferma, la creazione viene completata con successo e il Service Group risulta in stato Succeeded. Da questa pagina potete verificare le informazioni principali, visualizzare il numero di membri associati e accedere alle funzionalità di gestione, come la modifica delle relazioni, il controllo degli accessi e il monitoraggio.

Figura 7: Vista di overview del Service Group dopo la creazione, con stato di provisioning completato e riepilogo dei membri associati

Nella vista Members potete visualizzare in dettaglio tutti i membri associati al Service Group, inclusi sottoscrizioni, Resource Group e singole risorse, insieme al tipo di relazione e all’identificativo della relazione. Questa vista consente anche di filtrare, esportare e gestire le relazioni esistenti, facilitando il controllo e la manutenzione del servizio nel tempo.

Figura 8: Vista Members del Service Group, con l’elenco completo delle risorse e delle sottoscrizioni collegate al servizio

Nella sezione Child service groups potete visualizzare ed eventualmente creare Service Group figli, costruendo una struttura gerarchica che rappresenta servizi complessi articolati su più livelli. Questo approccio consente di modellare il servizio in modo modulare, mantenendo una chiara relazione tra servizio principale e sottoservizi.

Figura 9: Vista Child service groups, utilizzata per creare e gestire Service Group annidati all’interno di un Service Group principale

Nella sezione Monitoring potete avere una vista aggregata dello stato di salute del servizio, con il riepilogo degli alert e degli eventuali problemi rilevati sulle risorse appartenenti al Service Group. Il monitoraggio è presentato a livello di servizio, consentendo di valutare rapidamente l’impatto complessivo senza analizzare singolarmente ogni risorsa.

Figura 10: Vista di monitoraggio del Service Group, con stato di salute e alert aggregati a livello di servizio

Dalla scheda Coverage + Recommendations della sezione Monitoring potete analizzare il livello di copertura del monitoraggio sulle risorse associate al servizio, identificando eventuali gap di osservabilità. La vista include anche raccomandazioni operative, come l’abilitazione di funzionalità avanzate di monitoraggio, per migliorare l’affidabilità e la visibilità complessiva del servizio.

Figura 11: Vista Coverage + Recommendations del monitoraggio del Service Group, con analisi della copertura e suggerimenti per migliorare l’osservabilità del servizio

Dalla sezione Access control (IAM) potete gestire i permessi di accesso al Service Group utilizzando il modello RBAC di Azure. È importante chiarire che l’IAM sul Service Group non governa direttamente le operazioni sulle singole risorse, ma controlla chi può visualizzare, amministrare e modificare il Service Group stesso, incluse le relazioni con le risorse e la struttura gerarchica dei Service Group.

Nel contesto dei Service Group, Access control (IAM) dovrebbe essere usato principalmente per definire ownership, responsabilità operative e governance, evitando di assegnare permessi in modo indiscriminato. In genere, l’accesso va limitato ai ruoli che hanno la responsabilità di gestire il servizio nel suo insieme, non l’infrastruttura di dettaglio.

Dal punto di vista delle assegnazioni consigliate, dovreste concedere accesso completo al Service Group ai Service Owner o ai Responsabili applicativi, che devono poter creare o modificare Service Group, aggiungere o rimuovere membri e organizzare i Service Group figli. A questi profili è appropriato assegnare ruoli con privilegi elevati sul Service Group, come il Contributor o ruoli equivalenti dedicati alla gestione del servizio.

Ai team DevOps e Operations dovreste garantire la possibilità di consultare lo stato del servizio, accedere al monitoraggio aggregato e analizzare i membri del Service Group, senza necessariamente consentire modifiche strutturali. In questi casi è preferibile assegnare ruoli di sola lettura, in modo da preservare la stabilità della struttura del servizio.

Gli stakeholder di business, i responsabili di processo o i team di governance possono avere accesso in sola lettura per ottenere visibilità sul servizio, sul perimetro delle risorse coinvolte e sullo stato complessivo, senza alcuna capacità di intervento tecnico.

Ovviamente dovreste evitare di assegnare permessi sul Service Group a singoli utenti quando possibile, privilegiando gruppi di Microsoft Entra ID, così da mantenere un controllo centralizzato e coerente degli accessi. Inoltre, è buona pratica limitare l’uso di ruoli con privilegi elevati nel tempo, utilizzando meccanismi di accesso temporaneo o approvato quando disponibili. Vi torna, no?

Figura 12: Gestione degli accessi (IAM) su un Service Group, utilizzata per controllare chi può amministrare, modificare o consultare la struttura e le relazioni del servizio

Conclusioni

I Service Group rappresentano un livello fondamentale per governare i servizi in Azure in modo strutturato e orientato al business. Utilizzandoli correttamente, potete ottenere una visione end-to-end del servizio, indipendente dalla distribuzione tecnica delle risorse, migliorando chiarezza, responsabilità e collaborazione tra team.

La creazione di Service Group ben definiti, con membri coerenti, una struttura gerarchica chiara e un modello di accesso controllato tramite IAM, vi consente di semplificare le attività operative, rendere più efficace il monitoraggio e facilitare la gestione degli incidenti e del ciclo di vita del servizio. In contesti enterprise, questo approccio aiuta a ridurre la complessità e ad allineare governance, operazioni e obiettivi di business.

Adottare i Service Group non significa sostituire Resource Group o Management Group, ma affiancarli con un livello di astrazione che vi permette di ragionare in termini di servizio. Se utilizzati in modo coerente e disciplinato, diventano un elemento chiave per una gestione moderna, scalabile e sostenibile degli ambienti Azure.