Azure Managed Services: funzionalità, vantaggi e casi d'uso reali

Gli Azure managed services comprendono sia le offerte gestite dalla piattaforma Microsoft — Azure SQL Managed Instance, Managed Disks, Managed Applications — sia i managed service provider (MSP) esterni che operano, proteggono e ottimizzano gli ambienti Azure end to end. Comprendere il confine tra ciò che gestisce Microsoft e ciò che gestite voi (o il vostro MSP) è la decisione più importante in un progetto Azure, perché è proprio nel fraintendimento di quel confine che si originano disservizi, lacune di conformità e costi fuori controllo.

Punti chiave

• Gli Azure managed services coprono uno spettro che va dalle offerte PaaS come Azure SQL Managed Instance alle partnership con MSP esterni che gestiscono l'intero ambiente Azure.
• La scelta tra servizi gestiti da Microsoft (livello piattaforma) e un MSP esterno (livello operativo) non è un aut aut: la maggior parte delle organizzazioni mature utilizza entrambi.
• Le organizzazioni italiane ed europee devono valutare gli Azure managed services alla luce degli obblighi NIS2 sulla supply chain, dei requisiti GDPR sulla residenza dei dati e delle indicazioni dell'ACN (Agenzia per la Cybersicurezza Nazionale) — non solo in base al costo.
• Un MSP Azure competente deve offrire monitoraggio 24/7, incident response, FinOps e gestione della postura di conformità — non solo un servizio di help-desk.

Cosa significa realmente "Managed" in Azure — tre livelli distinti

Il termine "managed" viene usato in modo generico. In Azure si applica a tre livelli differenti, e confonderli genera problemi concreti.

Livello 1: servizi gestiti dalla piattaforma Microsoft (PaaS)

Sono servizi in cui Microsoft è responsabile del patching, della disponibilità e delle operazioni infrastrutturali. Voi li configurate e li consumate, ma non vi collegate in SSH a una VM per risolvere problemi. Esempi:

• Azure SQL Managed Instance — Un database PaaS compatibile quasi al 100% con SQL Server, che elimina il patching a livello di sistema operativo, i backup automatizzati e la complessità dell'alta disponibilità. Le organizzazioni che migrano da SQL Server on-premises ottengono compatibilità senza l'onere operativo. Il trade-off: si perde una certa flessibilità a basso livello su SQL Server Agent e si paga un sovrapprezzo rispetto a SQL su una VM non gestita.
• Azure Managed Disks — Storage a blocchi che elimina la necessità di gestire gli storage account. Snapshot dei dischi, crittografia at rest (SSE con chiavi gestite dalla piattaforma o dal cliente) e allineamento all'availability set sono gestiti automaticamente.
• Azure Managed Applications — ISV o team interni pubblicano pacchetti applicativi che i consumatori distribuiscono nelle proprie subscription, mentre l'editore mantiene il controllo operativo del managed resource group. Questo modello è potente per piattaforme interne di tipo SaaS, ma richiede un'attenta definizione degli scope RBAC per evitare il privilege creep.
• Azure Functions (piani Consumption/Premium) — Compute serverless in cui Microsoft gestisce l'infrastruttura host. La vostra responsabilità riguarda il codice, i trigger e i binding. Nel piano Premium, gestite anche l'integrazione VNet e le istanze pre-warmed.

Livello 2: supporto e advisory Microsoft (Unified Support, FastTrack)

Microsoft propone contratti Unified Support e onboarding FastTrack per i workload idonei. Sono servizi reattivi e consulenziali: vi aiutano a risolvere problemi break/fix e a pianificare le migrazioni, ma non monitorano il vostro ambiente 24/7, non rispondono a incidenti di sicurezza alle 3 di notte e non ottimizzano la spesa in modo proattivo.

Livello 3: Managed Service Provider (MSP) esterno

È qui che opera un partner come Opsio. Un MSP Azure assume la responsabilità operativa del vostro ambiente in base a un SLA definito: monitoraggio, alerting, incident response, patching, validazione dei backup, gestione della postura di sicurezza, ottimizzazione dei costi e documentazione di conformità. L'MSP colma il divario tra ciò che Microsoft gestisce a livello di piattaforma e ciò che il vostro team interno può realisticamente coprire.

La maggior parte degli ambienti Azure in produzione ha bisogno di tutti e tre i livelli che lavorano insieme. L'errore che osserviamo ripetutamente nel nostro NOC è quello di organizzazioni che presumono che il livello 1 (PaaS) elimini la necessità del livello 3 (MSP). Non è così. Il PaaS elimina le operazioni infrastrutturali, ma il monitoraggio applicativo, la configurazione di sicurezza, la governance dei costi e la postura di conformità richiedono ancora giudizio umano e attenzione continua 24/7.

Funzionalità principali degli Azure Managed Services (piattaforma + MSP)

Servizi Cloud Gestiti

Vantaggi concreti in produzione

Riduzione del toil operativo

Gestire bene Azure non è un compito per una sola persona. Tra alert di Azure Advisor, raccomandazioni di Defender for Cloud, indagini sulle anomalie di costo, upgrade delle versioni AKS e audit delle regole NSG, un ambiente Azure di medie dimensioni (50–200 risorse) genera un flusso costante di lavoro operativo che non si inserisce facilmente nella pianificazione degli sprint. Un MSP assorbe questo toil con un canone mensile prevedibile, liberando i vostri ingegneri per lo sviluppo di funzionalità di prodotto.

Risoluzione più rapida degli incidenti

Dal nostro SOC, il pattern è chiaro: le organizzazioni senza monitoraggio 24/7 scoprono gli incidenti Azure ore dopo il loro inizio — di solito quando un cliente si lamenta. Con un monitoraggio adeguato (Azure Monitor workspace che alimenta PagerDuty o Opsgenie, con Sentinel per gli eventi di sicurezza), il mean time to detect scende da ore a minuti. L'ingegnere reperibile dell'MSP classifica, scala se necessario e documenta la root cause mentre il vostro team riposa.

Conformità come processo continuo

La conformità non è un esercizio da checkbox. La direttiva NIS2 (recepita in Italia con il D.Lgs. 138/2024, sotto la supervisione dell'ACN) richiede agli enti essenziali e importanti di 18 settori una gestione continua del rischio, la notifica degli incidenti ai CSIRT entro 24 ore e una sicurezza documentata della supply chain — compresi il fornitore cloud e il vostro MSP. Il GDPR, con gli articoli 28 e 32, impone obblighi specifici al responsabile del trattamento. A livello nazionale, il Garante per la protezione dei dati personali e le qualificazioni dell'ACN nell'ambito della strategia Cloud Italia aggiungono ulteriori requisiti per i servizi cloud nella PA e nei settori regolamentati.

Un MSP Azure che opera il vostro ambiente è, per definizione, un responsabile del trattamento. Il contratto con l'MSP deve riflettere questo: accordi per il trattamento dei dati, comunicazione dei sub-responsabili, tempistiche di notifica delle violazioni e diritti di audit. Se il vostro potenziale MSP non è in grado di produrre questa documentazione su richiesta, lasciate perdere.

Cloud Security

FinOps — perché le fatture Azure sorprendono

Secondo il rapporto State of the Cloud di Flexera, la gestione della spesa cloud si è costantemente classificata come la sfida principale per le organizzazioni di ogni livello di maturità. La fatturazione Azure è particolarmente opaca per le organizzazioni nuove alla piattaforma — licensing Hybrid Benefit, scoping delle Reserved Instance (shared vs. singola subscription), policy di eviction delle spot VM e il divario tra le raccomandazioni di risparmio di Azure Advisor e la loro effettiva implementazione.

Un MSP competente esegue un FinOps continuo: revisione settimanale delle anomalie di costo, right-sizing trimestrale delle reservation e pulizia proattiva delle risorse orfane. Le Reserved Instance e gli Azure Savings Plan offrono tipicamente un risparmio del 30–60% rispetto al pay-as-you-go, ma solo se qualcuno gestisce attivamente il portafoglio di impegni. Quel qualcuno dovrebbe essere il vostro MSP, non un ingegnere che controlla una volta a trimestre.

Cloud FinOps

Casi d'uso reali

Caso d'uso 1: azienda SaaS italiana — NIS2, GDPR e sovranità del dato

Un'azienda SaaS di medie dimensioni con sede a Milano, operante in un settore classificato come "importante" ai sensi della NIS2, esegue i propri workload di produzione su Azure Italy North (Milano) e Azure West Europe (Paesi Bassi) come regione di DR. I requisiti:

• I dati non devono uscire dallo Spazio Economico Europeo. Le Azure Policy assignment impongono allowedLocations sulle sole regioni EU, con la region primaria su eu-south-1 (Milan) equivalente Azure.
• Incident response entro 24 ore (NIS2 Articolo 23, D.Lgs. 138/2024). Il SOC dell'MSP opera 24/7 con un playbook di incident response documentato e integrato con il processo di notifica al CSIRT Italia dell'ACN.
• Gestione del rischio della supply chain. L'MSP fornisce report annuali SOC 2 Type II ed è contrattualmente vincolato come responsabile del trattamento ai sensi dell'art. 28 del GDPR.
• Azure SQL Managed Instance sostituisce SQL Server on-premises, eliminando il patching del sistema operativo e mantenendo la TDE (Transparent Data Encryption) con chiavi gestite dal cliente conservate in Azure Key Vault (regione Italia).

Caso d'uso 2: istituzione finanziaria italiana — regolamentazione Banca d'Italia e DORA

Un istituto finanziario italiano con sede a Roma tratta dati personali di cittadini italiani e deve conformarsi al GDPR, alle circolari di Banca d'Italia in materia di esternalizzazione ICT e al regolamento DORA (Digital Operational Resilience Act). Il suo ambiente Azure è distribuito su Azure Italy North (Milano) per la produzione e Azure West Europe (Paesi Bassi) per il DR. Il ruolo dell'MSP:

• Managed Kubernetes (AKS) con auto-scaling dei node pool e orchestrazione degli upgrade di versione.
• Microsoft Defender for Cloud con dashboard di regulatory compliance mappato sui requisiti DORA e sulle indicazioni della Banca d'Italia.
• Validazione automatizzata dei backup: test di restore settimanali verso un ambiente di staging, con risultati registrati per audit.
• FinOps: spot instance per i workload di elaborazione batch (calcolo di modelli di rischio), reserved instance per il tier API always-on.

Caso d'uso 3: impresa multi-cloud — Azure + AWS

Molte aziende non utilizzano Azure in modo isolato. Hanno AWS per un set di workload, Azure per un altro (spesso per l'integrazione con Microsoft 365 ed Entra ID) e talvolta GCP per data e ML. L'MSP deve operare su più cloud senza preferenze.

Dal nostro NOC, il pattern multi-cloud più comune è: Azure per l'identità (Entra ID), la collaboration (M365) e i workload .NET; AWS per i workload container e i data lake. L'MSP fornisce un unico pannello di monitoraggio (tipicamente Datadog o Grafana Cloud), gestione unificata degli incidenti (PagerDuty) e reportistica FinOps cross-cloud, in modo che il CTO veda la spesa cloud totale e non fatture separate in silos.

Migrazione al Cloud

ASM vs. ARM: perché è ancora rilevante

Azure Service Management (ASM), il modello di deployment "classico", è stato deprecato anni fa, ma durante gli assessment di onboarding ci imbattiamo ancora in risorse ASM in produzione — Cloud Services classici, VNet classiche, storage account classici. Queste risorse mancano delle funzionalità ARM: niente resource group, niente RBAC, niente tagging, niente enforcement delle Azure Policy, nessuna integrazione con il monitoraggio moderno.

Azure Resource Manager (ARM) è il modello di deployment attuale e l'unico supportato. Tutte le nuove risorse vengono distribuite tramite ARM e Microsoft sta ritirando i servizi classici progressivamente. Se il vostro ambiente contiene ancora risorse ASM, la migrazione agli equivalenti ARM non è facoltativa: è un requisito di sicurezza e supportabilità. Un buon MSP le identificherà durante l'assessment di onboarding e pianificherà la migrazione.

Come scegliere un MSP Azure: cosa valutare

Non tutti gli MSP sono uguali. Ecco cosa distingue operazioni Azure competenti da un semplice servizio di help-desk:

Profondità tecnica

• Possiedono le designazioni Microsoft Solutions Partner (Infrastructure, Security, Digital & App Innovation)? Le designazioni hanno sostituito le vecchie competenze Gold/Silver e richiedono successi dimostrabili con i clienti e personale certificato.
• Sono in grado di progettare con strumenti Azure-native (template Bicep/ARM, Azure Policy, Azure Landing Zones) oppure conoscono solo Terraform? Entrambi sono validi, ma se non sanno leggere un file Bicep, avranno difficoltà con le architetture di riferimento pubblicate da Microsoft.

Modello operativo

• SOC/NOC 24/7 con SLA definiti per incidenti P1/P2/P3/P4 — non "best effort durante l'orario d'ufficio".
• Runbook per scenari comuni: failure dei node pool AKS, lockout delle conditional-access policy di Azure AD (Entra ID), eventi di scaling dell'App Service plan, degradazione del circuito ExpressRoute.
• Processo di change management: come gestiscono le vostre change request? Esiste un CAB (Change Advisory Board) o un flusso di approvazione leggero basato su PR?

Conformità e governance

• Possono presentare il proprio report SOC 2 Type II e il certificato ISO 27001?
• Dispongono di un accordo per il trattamento dei dati documentato e conforme all'art. 28 del GDPR?
• Per le organizzazioni soggette a NIS2: accettano contrattualmente gli obblighi relativi alla supply chain?
• Per i clienti della PA italiana: i loro servizi cloud sono qualificati secondo i criteri dell'ACN nell'ambito della strategia Cloud Italia?

Maturità FinOps

• Gestiscono proattivamente reservation e savings plan, oppure si limitano a inviarvi screenshot di Azure Advisor?
• Possono mostrare una dashboard FinOps con tracking delle unit economics (costo per cliente, costo per transazione)?

Managed DevOps

Stack di strumenti: cosa utilizziamo concretamente

La trasparenza sugli strumenti è importante. Ecco uno stack rappresentativo per un engagement MSP Azure:

Errori comuni che osserviamo nel nostro NOC

VM sovradimensionate ovunque. Le organizzazioni migrano le VM on-premises verso Azure con un approccio "lift and shift", mantenendo il dimensionamento originale. Le VM Azure sono fatturate al minuto. Ridimensionare da una D4s_v5 a una D2s_v5 quando l'utilizzo medio della CPU è al 12% equivale a risparmiare senza sforzo.

Defender for Cloud impostato sul "free tier" e dimenticato. Il tier gratuito fornisce solo una postura di sicurezza di base. I piani Defender (per Servers, SQL, Kubernetes, Storage, Key Vault, ecc.) offrono rilevamento delle minacce, valutazione delle vulnerabilità e punteggio di conformità normativa. Il costo è reale ma giustificato per i workload in produzione.

Nessuna segmentazione di rete. Una singola VNet con un'unica subnet e un NSG predefinito che consente tutto il traffico interno. È l'equivalente Azure di una rete piatta. Utilizzate la topologia hub-spoke (Azure Virtual WAN o hub VNet tradizionale con peering), i flow log NSG e Azure Firewall o un'NVA di terze parti per l'ispezione del traffico est-ovest.

Policy di backup configurate ma mai testate. Azure Backup funziona in modo affidabile, ma ciò che conta è il processo di restore. Se non avete mai eseguito un test di restore del vostro database di produzione, il vostro backup è un'ipotesi, non un controllo.

Quando non serve un MSP

L'onestà è importante. Probabilmente non avete bisogno di un MSP Azure esterno se:

• Avete meno di 20 risorse Azure e un platform engineer competente che le monitora.
• I vostri workload sono interamente serverless (Azure Functions piano Consumption, Logic Apps, Cosmos DB serverless) senza obblighi di conformità.
• Avete un team interno di platform engineering maturo con rotazione on-call 24/7 già operativa.

Ne avete probabilmente bisogno se:

• Il vostro ambiente Azure è cresciuto oltre le capacità di monitoraggio del team durante l'orario lavorativo.
• Avete obblighi di conformità (NIS2, GDPR, SOC 2, DORA, requisiti ACN) che richiedono controlli documentati e continui.
• Operate in ambienti ibridi (Azure + on-premises) o multi-cloud (Azure + AWS/GCP) e necessitate di operazioni unificate.
• La vostra fattura Azure cresce più velocemente del fatturato e nessuno sa perché.

Servizi Cloud Gestiti

Domande frequenti

Cosa sono gli Azure Managed Services?

Gli Azure managed services indicano due cose distinte: le offerte gestite dalla piattaforma Microsoft (Azure SQL Managed Instance, Managed Disks, Managed Applications) dove Microsoft gestisce l'infrastruttura sottostante, e i managed service provider di terze parti che operano, monitorano, proteggono e ottimizzano il vostro ambiente Azure in base a un SLA contrattuale. La maggior parte degli ambienti in produzione utilizza entrambi i livelli insieme.

Quali sono le cinque tipologie di servizi gestiti?

Le cinque tipologie comunemente riconosciute sono: infrastruttura gestita (compute, networking, storage), sicurezza gestita (SOC, SIEM, rilevamento e risposta alle minacce), database gestiti (amministrazione SQL e NoSQL, patching, backup), applicazioni gestite (pipeline di deployment, scaling, patching) e gestione finanziaria del cloud — FinOps — che comprende ottimizzazione dei costi, gestione delle reservation e governance del budget.

Qual è la differenza tra ASM e ARM?

ASM (Azure Service Management) era il modello di deployment "classico" originale di Azure, con API basate su XML e senza supporto per resource group, RBAC o policy. ARM (Azure Resource Manager) lo ha sostituito ed è oggi l'unico modello supportato, con template JSON/Bicep, RBAC granulare, tagging e integrazione con Azure Policy. Microsoft sta ritirando progressivamente i servizi classici ASM; le eventuali risorse ASM residue vanno migrate ad ARM immediatamente.

Cos'è un managed device in Azure?

Un managed device è qualsiasi endpoint — laptop, smartphone, tablet — registrato in Microsoft Intune (parte della suite Microsoft Entra). La registrazione impone policy di accesso condizionale, controlli di conformità (crittografia, versione del sistema operativo, codice di accesso) e consente il remote wipe. I managed device sono un componente fondamentale delle architetture Zero Trust per l'accesso alle applicazioni e ai dati ospitati su Azure.

In che modo gli Azure managed services supportano la conformità NIS2?

La direttiva NIS2 impone agli enti essenziali e importanti di 18 settori nell'UE di implementare una gestione continua del rischio, segnalare gli incidenti significativi ai CSIRT entro 24 ore e gestire la sicurezza della supply chain. In Italia, il D.Lgs. 138/2024 ha recepito la direttiva e l'ACN funge da autorità competente. Un MSP Azure con capacità SOC 24/7, runbook di incident response documentati e reportistica di compliance audit-ready supporta direttamente questi requisiti — a condizione che l'MSP sia contrattualmente vincolato come parte della supply chain e possa dimostrare le proprie certificazioni di sicurezza (SOC 2 Type II, ISO 27001).