Modelli di deployment cloud: Public, Private, Hybrid e Multi-Cloud

I modelli di deployment cloud definiscono dove risiede l'infrastruttura, chi la gestisce e come i carichi di lavoro si spostano tra gli ambienti. I quattro modelli principali — public, private, hybrid e multi-cloud — impongono compromessi differenti in termini di costo, compliance, complessità operativa e prestazioni. Scegliere correttamente richiede un'analisi a livello di singolo carico di lavoro, non una policy generica. Questa guida analizza ciascun modello con i dettagli operativi e il contesto normativo italiano ed europeo che le panoramiche generiche trascurano.

Punti chiave

• I quattro modelli di deployment cloud — public, private, hybrid e multi-cloud — presentano compromessi distinti in termini di costo, controllo, compliance e complessità operativa.
• L'hybrid cloud è il modello più adottato dalle imprese, secondo il report State of the Cloud di Flexera, perché consente alle organizzazioni di collocare i carichi di lavoro nell'ambiente più appropriato.
• Le organizzazioni italiane ed europee devono valutare le scelte di deployment cloud alla luce dei requisiti di residenza dei dati previsti da NIS2, GDPR e dalle indicazioni dell'ACN (Agenzia per la Cybersicurezza Nazionale); le imprese indiane affrontano un livello di scrutinio analogo con il DPDPA 2023.
• Multi-cloud e hybrid cloud non sono la stessa cosa — confonderli genera dispersione architetturale, duplicazione degli strumenti e costi fuori controllo.
• La scelta del modello di deployment non è una decisione presa una volta per tutte; la classificazione dei carichi di lavoro e una rivalutazione periodica prevengono la deriva verso il modello sbagliato.

Che cos'è un modello di deployment cloud?

Un modello di deployment cloud descrive la proprietà, l'ambito di accesso e la localizzazione fisica dell'infrastruttura cloud. Risponde a tre domande: chi possiede l'hardware? Chi può accedere all'ambiente? Dove risiedono fisicamente i dati?

Si tratta di un concetto distinto dai modelli di servizio cloud (IaaS, PaaS, SaaS), che descrivono il livello di astrazione — ciò che il provider gestisce rispetto a ciò che gestisci tu. Un modello di deployment riguarda il dove e come; un modello di servizio riguarda il cosa. È possibile eseguire IaaS su un private cloud o consumare SaaS erogato tramite un'architettura ibrida. Le due tassonomie sono ortogonali.

La definizione NIST SP 800-145 identifica quattro modelli di deployment: public, private, hybrid e community. Il settore ha successivamente aggiunto il multi-cloud come quinto modello de facto, perché le sue caratteristiche operative differiscono in modo significativo dall'hybrid. Li analizziamo tutti e cinque di seguito.

Public Cloud

Come funziona

L'infrastruttura public cloud è di proprietà e gestita da un provider terzo — AWS, Microsoft Azure, Google Cloud Platform (GCP) o altri — e condivisa tra più tenant. Le risorse vengono consumate on demand, si paga in base all'utilizzo e il provider si occupa dell'approvvigionamento hardware, della sicurezza fisica e della gestione a livello di piattaforma.

I principali provider operano region a livello globale. AWS dispone di region a Milano (eu-south-1), Francoforte (eu-central-1) e Mumbai (ap-south-1). Azure opera in Italy North, Germany West Central e Central India. GCP offre europe-west8 (Milano) e asia-south1 (Mumbai). La scelta della region è cruciale per latenza, residenza dei dati e pricing — non è un dettaglio secondario.

Quando il public cloud è la scelta giusta

• Carichi di lavoro variabili o imprevedibili: l'auto-scaling elimina l'incertezza del capacity planning. Paghi per ciò che usi, non per ciò che potresti aver bisogno.
• Startup e team orientati all'iterazione rapida: zero CapEx iniziali, provisioning istantaneo. Prima si rilascia, poi si ottimizza.
• Applicazioni stateless o cloud-native: microservizi containerizzati, funzioni serverless (AWS Lambda, Azure Functions, Cloud Run) e database gestiti (RDS, Cloud SQL) sono progettati per le primitive del public cloud.
• Ambienti di sviluppo/test: si avvia, si eseguono i test, si smantella. La capacità riservata non ha senso in questo scenario.

Dove il public cloud mostra i suoi limiti

• Vincoli di sovranità dei dati: l'articolo 44 del GDPR limita i trasferimenti di dati personali al di fuori dello SEE in assenza di adeguate garanzie. Utilizzare la region europea di un provider con sede negli Stati Uniti è generalmente accettabile, ma le implicazioni della sentenza Schrems II e gli sviluppi del EU–US Data Privacy Framework richiedono una valutazione legale approfondita, non solo la selezione di una region. La strategia Cloud Italia dell'ACN e la qualificazione dei servizi cloud per la PA impongono ulteriori vincoli per le organizzazioni pubbliche italiane. Sotto il DPDPA 2023 indiano, il governo centrale può limitare i trasferimenti verso determinati Paesi — le organizzazioni devono monitorare queste notifiche.
• Carichi di lavoro stabili ad alto utilizzo: una VM che gira al 80%+ di utilizzo 24/7 per anni è quasi sempre più conveniente on-premises o in private cloud. Le Reserved Instances e i Savings Plans (che offrono tipicamente risparmi del 30–60% rispetto al pricing on-demand, secondo la documentazione stessa di AWS) riducono il divario ma non lo eliminano per carichi realmente statici.
• Ambienti altamente regolamentati: alcuni regolatori dei servizi finanziari e agenzie di difesa richiedono isolamento fisico che la separazione logica della multi-tenancy nel public cloud non soddisfa. La Banca d'Italia e la CONSOB, ad esempio, richiedono garanzie specifiche sull'esternalizzazione dei servizi IT presso cloud provider.

Servizi Cloud Gestiti

Private Cloud

Come funziona

Il private cloud dedica l'infrastruttura a una singola organizzazione. Può essere operato on-premises nel proprio data center o ospitato da terzi (hosted private cloud). La caratteristica distintiva è la single-tenancy e il controllo diretto sull'intero stack infrastrutturale.

I private cloud moderni utilizzano le stesse tecnologie di orchestrazione dei provider pubblici. VMware Cloud Foundation, OpenStack, Nutanix e Azure Stack HCI offrono modelli di consumo simili a IaaS internamente. Distribuzioni Kubernetes come Red Hat OpenShift o Rancher aggiungono l'orchestrazione dei container.

Quando il private cloud ha senso

• Regimi di compliance rigorosi: gli istituti finanziari soggetti alle normative nazionali (ad esempio Banca d'Italia, CONSOB, oltre a BaFin in Germania) talvolta sono soggetti a requisiti che impongono un isolamento fisico verificabile. Le organizzazioni sanitarie che trattano dati dei pazienti sotto il GDPR spesso preferiscono un'infrastruttura privata per semplificare la catena di accountability. Il Garante per la protezione dei dati personali ha più volte sottolineato l'importanza di un controllo effettivo sui dati trattati tramite servizi cloud.
• Compute prevedibile ad alta densità: carichi di lavoro HPC, elaborazioni batch su larga scala o training di modelli ML su cluster GPU dedicati possono essere più convenienti su hardware di proprietà quando l'utilizzo resta elevato.
• Dipendenze da applicazioni legacy: carichi di lavoro adiacenti ai mainframe o applicazioni con dipendenze da IP hardcoded, protocolli non TCP/IP o licensing legato ai core fisici spesso non possono migrare al public cloud senza una riscrittura.

I costi reali che le persone sottovalutano

Il private cloud non è "gratuito perché possediamo già i server". Le attività di Cloud FinOps di Opsio rivelano costantemente costi nascosti: alimentazione e raffreddamento del data center, cicli di refresh dell'hardware (tipicamente 3–5 anni), personale per gestire firmware, patch e sicurezza fisica, oltre al costo-opportunità di ingegneri impegnati in attività indifferenziate anziché nello sviluppo del prodotto.

Il calcolo onesto: se l'utilizzo medio è inferiore al 60%, è probabile che si stia pagando troppo per il private cloud. Se è costantemente superiore al 75%, è probabile che si stia risparmiando rispetto al pricing on-demand del public cloud — ma occorre considerare anche il costo di agilità legato ai tempi di approvvigionamento.

Hybrid Cloud

Come funziona

L'hybrid cloud connette l'infrastruttura privata (on-premises o hosted) con uno o più ambienti di public cloud tramite orchestrazione, networking e, spesso, layer di identità condivisi. L'elemento differenziante rispetto al semplice utilizzo di entrambi è l'integrazione: carichi di lavoro, dati e piani di gestione operano in modo coordinato tra gli ambienti.

Le tecnologie abilitanti principali includono:

Perché l'hybrid domina l'adozione enterprise

Secondo il report State of the Cloud di Flexera, l'hybrid è stato costantemente la strategia enterprise dominante per diversi anni consecutivi. Le ragioni sono pratiche, non teoriche:

1. La migrazione è graduale: nessuna impresa migra tutto sul public cloud in un unico passaggio. L'hybrid è l'architettura di transizione naturale durante qualsiasi programma di Migrazione Cloud.

2. Flessibilità nel posizionamento dei carichi di lavoro: i dati sensibili restano sull'infrastruttura privata mentre le applicazioni rivolte al cliente scalano sul public cloud. Un'azienda italiana di e-commerce potrebbe mantenere i PII in un ambiente privato nel data center di Milano, eseguendo il layer di CDN e compute su AWS eu-south-1 (Milano).

3. Capacità di burst: si esegue il compute di base on-premises e si scala sul public cloud durante i picchi — traffico del Black Friday, elaborazioni di fine trimestre, domanda stagionale.

4. DR e resilienza: utilizzare il public cloud come target di disaster recovery per i carichi di lavoro on-premises. AWS Elastic Disaster Recovery, Azure Site Recovery e servizi analoghi rendono questa opzione operativamente praticabile.

Sfide operative dell'hybrid cloud

L'hybrid non è "il meglio di entrambi i mondi" senza sforzo. Dall'esperienza del NOC 24/7 di Opsio nella gestione di ambienti ibridi, i punti critici ricorrenti sono:

• Complessità di rete: i carichi di lavoro sensibili alla latenza distribuiti tra ambienti creano situazioni di debugging estremamente complesse. Se il database è on-prem e l'applicazione è nel public cloud, ogni query attraversa l'interconnessione. Va misurato prima di progettare l'architettura.
• Postura di sicurezza inconsistente: regole firewall on-prem, security group in AWS, NSG in Azure — tre linguaggi di policy diversi che descrivono lo stesso intento. La deriva è inevitabile senza Infrastructure as Code (Terraform, Pulumi) e validazione continua delle policy (OPA, Checkov).
• Frammentazione del monitoring: un alert si attiva in CloudWatch, un altro nella tua istanza Zabbix on-prem, un terzo in Datadog. Senza un layer di osservabilità unificato, il team SOC spreca tempo a correlare tra console anziché risolvere gli incidenti.

Sicurezza Cloud

Multi-Cloud

Multi-Cloud vs. Hybrid: una distinzione necessaria

Questi termini vengono spesso usati in modo intercambiabile. Non dovrebbero esserlo. Hybrid significa combinare infrastruttura privata e pubblica. Multi-cloud significa utilizzare due o più provider di public cloud. Un'organizzazione che usa AWS e Azure è multi-cloud. Un'organizzazione che usa AWS e un cluster VMware on-premises è hybrid. Un'organizzazione che fa entrambe le cose è hybrid multi-cloud — e gestirla rappresenta lo scenario operativamente più complesso nell'infrastruttura cloud.

Multi-cloud deliberato vs. accidentale

Questa distinzione conta più di qualsiasi diagramma architetturale. La maggior parte degli ambienti multi-cloud è accidentale: il team di sviluppo ha scelto AWS, il team dati ha scelto GCP per BigQuery, e l'azienda ha acquisito una società che gestiva tutto su Azure. Nessuno l'ha pianificato; è semplicemente successo.

Il multi-cloud deliberato ha giustificazioni specifiche:

• Requisiti normativi: alcuni regolatori finanziari europei richiedono la mitigazione del rischio di concentrazione — non dipendere da un singolo cloud provider per i servizi critici. L'articolo 21 della NIS2 richiede, in alcune interpretazioni, "strategie ICT multi-vendor" per le entità essenziali. La Banca d'Italia e le linee guida EBA sull'esternalizzazione enfatizzano la necessità di piani di exit strategy e la riduzione del rischio di lock-in.
• Servizi best-of-breed: GCP BigQuery per l'analytics, AWS per il compute generale, Azure per l'integrazione con Microsoft 365 e Active Directory. Questa scelta è difendibile quando il costo del networking cross-cloud e dell'overhead operativo giustifica il vantaggio a livello di servizio.
• Copertura geografica: nessun singolo provider dispone di region ovunque. Un'organizzazione che necessita di compute locale in un Paese dove solo un provider ha una region sarà multi-cloud per necessità.

Il costo operativo del multi-cloud

Gestendo i servizi di DevOps Gestito di Opsio su infrastrutture multi-cloud, il costo operativo è evidente:

• Divergenza IAM: AWS IAM, Azure Entra ID e GCP IAM utilizzano modelli di permessi diversi, meccanismi di trust chain differenti e formati di audit log distinti. Costruire un layer unificato di governance degli accessi richiede un investimento significativo in strumenti.
• Frammentazione della visibilità sui costi: AWS Cost Explorer, Azure Cost Management e GCP Billing Export emettono dati in schemi diversi. Senza una piattaforma di Cloud FinOps (Apptio Cloudability, Vantage o simili), non è possibile rispondere alla domanda "quanto costa questa applicazione al mese?" trasversalmente ai provider.
• Diluizione delle competenze: ogni cloud provider ha migliaia di servizi. Un'expertise approfondita su tutti e tre è rara. I team distribuiti su più provider non ne padroneggiano nessuno.

La raccomandazione onesta: non perseguire il multi-cloud come strategia fine a sé stessa. Adottalo solo quando hai una ragione specifica e difendibile per ogni provider aggiuntivo, e metti a budget l'overhead operativo che comporta.

Community Cloud

Il community cloud — infrastruttura condivisa tra organizzazioni con requisiti comuni — è il modello meno discusso ma resta rilevante in settori specifici. Esempi includono i community cloud governativi (AWS GovCloud, Azure Government), le comunità di ricerca (GÉANT in Europa, GARR in Italia) e i consorzi di settore che condividono infrastruttura conforme.

In pratica, il community cloud è architetturalmente simile a un private cloud con tenancy condivisa tra organizzazioni selezionate. La sua rilevanza è circoscritta ma reale: se sei un ente della pubblica amministrazione italiana che condivide infrastruttura attraverso il Polo Strategico Nazionale (PSN) o i servizi cloud qualificati dall'ACN, stai operando su un community cloud.

Confronto tra modelli di deployment cloud

Come scegliere il modello di deployment cloud giusto

La scelta del modello di deployment è una decisione a livello di carico di lavoro, non a livello di organizzazione. Applicazioni diverse all'interno della stessa impresa rientreranno legittimamente in modelli differenti. Ecco il framework decisionale che Opsio applica:

Step 1: Classificare i carichi di lavoro

Per ogni carico di lavoro, valutare:

• Sensibilità dei dati: il carico tratta dati personali ai sensi del GDPR, dati finanziari sotto la normativa bancaria, o dati sanitari secondo le leggi nazionali? Il Garante per la protezione dei dati personali richiede misure di sicurezza adeguate al rischio. Ai sensi della NIS2, le entità essenziali e importanti in 18 settori devono implementare misure di gestione del rischio che possono vincolare le opzioni di deployment.
• Profilo prestazionale: sensibile alla latenza (deve essere prossimo agli utenti o ad altri sistemi), ad alto throughput (richiede larga banda), o ad alta intensità di calcolo (richiede hardware specifico come GPU)?
• Variabilità della domanda: stato stazionario, picchi stagionali o spike imprevedibili?
• Dipendenze di integrazione: il carico dipende da sistemi on-premises (database, mainframe, API legacy)?

Step 2: Mappare i vincoli

• Normativi: requisiti di residenza dei dati GDPR, restrizioni sui trasferimenti transfrontalieri del DPDPA 2023, regole settoriali (PSD2 per i pagamenti, MiFID II per il trading), la Circolare 285 di Banca d'Italia per i servizi IT bancari, le linee guida ACN per la qualificazione dei servizi cloud per la PA.
• Finanziari: disponibilità di budget CapEx, hardware esistente con vita utile residua, accordi di committed spend con i provider.
• Organizzativi: competenze del team, strumenti esistenti, relazioni con i vendor.

Step 3: Selezionare per carico di lavoro, poi aggregare

Una volta che ogni carico di lavoro ha un modello target, l'aggregazione determina il modello organizzativo. Se tutti i carichi puntano al public cloud, si è public-cloud-only. Se i carichi sono distribuiti tra private e public, si è hybrid. Se si estendono su più provider pubblici, si è multi-cloud.

Step 4: Rivalutare periodicamente

Il deployment cloud non è una decisione da prendere e dimenticare. Le caratteristiche dei carichi di lavoro cambiano. I prezzi cambiano. Le normative cambiano. Opsio raccomanda una rivalutazione formale almeno annuale, allineata ai cicli di rinnovo contrattuale e ai calendari di audit di compliance.

Considerazioni di compliance per UE e India

Unione Europea e Italia

GDPR: l'articolo 44 limita i trasferimenti di dati personali al di fuori dello SEE. Le scelte del modello di deployment devono garantire che i controlli sulla residenza dei dati siano imposti a livello architetturale, non solo su base documentale. AWS, Azure e GCP offrono tutti impegni sulla residenza dei dati nelle region EU, ma configurazioni come la replica cross-region, il caching CDN e gli strumenti di accesso del supporto possono trasferire inavvertitamente dati al di fuori dei confini previsti.

Garante per la protezione dei dati personali: il Garante ha adottato una posizione particolarmente attenta sull'uso dei servizi cloud, come evidenziato dalle decisioni relative a Google Analytics e ai trasferimenti di dati verso gli USA. Le organizzazioni italiane devono verificare che il modello di deployment scelto consenta un controllo effettivo sui dati e la possibilità di dimostrare la compliance in caso di ispezione.

NIS2: applicabile da ottobre 2024 e recepita in Italia con il D.Lgs. 138/2024, la NIS2 richiede alle entità essenziali e importanti di implementare misure tecniche e organizzative appropriate per la gestione del rischio di cybersicurezza. Questo include la sicurezza della supply chain — il cloud provider è parte della tua supply chain. Le decisioni sul modello di deployment devono documentare come ciascun modello soddisfa i requisiti dell'articolo 21 della NIS2.

ACN e Cloud Italia: l'Agenzia per la Cybersicurezza Nazionale (ACN) definisce i requisiti di qualificazione dei servizi cloud per la pubblica amministrazione italiana. La strategia Cloud Italia e il Polo Strategico Nazionale (PSN) impongono la classificazione dei dati in strategici, critici e ordinari, con vincoli progressivi sul tipo di infrastruttura utilizzabile. Le PA che trattano dati strategici o critici possono essere obbligate a utilizzare infrastrutture qualificate a livello elevato.

Sovranità cloud in Europa: il C5 del BSI tedesco e il SecNumCloud francese impongono requisiti aggiuntivi ai cloud provider. In Italia, il sistema di qualificazione ACN opera in modo analogo. Le organizzazioni che operano in questi mercati possono aver bisogno di provider con certificazioni nazionali specifiche, il che può vincolare le opzioni di deployment.

India

DPDPA 2023: il Digital Personal Data Protection Act indiano autorizza il governo centrale a limitare i trasferimenti transfrontalieri di dati personali verso Paesi notificati. Le organizzazioni che operano in India devono assicurarsi che il trattamento primario avvenga nelle region indiane (AWS ap-south-1 Mumbai, Azure Central India, GCP asia-south1 Mumbai) con controlli architetturali che impediscano l'egress dei dati verso giurisdizioni non approvate.

Linee guida RBI: le imprese di servizi finanziari in India devono conformarsi al framework della RBI sull'esternalizzazione dei servizi IT, che include requisiti specifici sulla localizzazione dei dati e sull'accesso per audit all'infrastruttura del cloud provider.

Sicurezza Cloud

Cosa osserva Opsio: pattern operativi nei diversi modelli di deployment

Gestendo operazioni SOC e NOC 24/7 su ambienti dei clienti che coprono tutti i modelli di deployment, emergono costantemente diversi pattern:

Gli ambienti hybrid generano il maggior numero di incidenti da guasti ai confini di rete. L'interconnessione tra on-premises e public cloud (Direct Connect, ExpressRoute) è un single point of failure che i team monitorano in modo insufficiente. Quando si degrada, i sintomi appaiono come lentezza applicativa anziché come guasto di rete, causando un troubleshooting mal indirizzato.

L'attribuzione dei costi in ambienti multi-cloud è la sfida FinOps principale. Le organizzazioni che eseguono carichi di lavoro su due o più provider faticano costantemente a rispondere a domande basilari come "quanto costa questa applicazione al mese?" senza strumenti dedicati e disciplina nel tagging.

Gli ambienti private cloud sono quelli che divergono più rapidamente dalle baseline di sicurezza. I provider di public cloud aggiornano continuamente le configurazioni predefinite (encryption-at-rest di default, versioni minime TLS, blocco dell'accesso pubblico). L'infrastruttura private cloud mantiene qualsiasi configurazione impostata al deployment, a meno che non venga attivamente manutenuta.

Le organizzazioni esclusivamente su public cloud adottano le nuove funzionalità più rapidamente ma accumulano anche il maggior numero di risorse inutilizzate. La facilità di provisioning genera sprawl. Il report State of the Cloud di Flexera ha costantemente identificato lo spreco cloud come una preoccupazione primaria, e gli ambienti puramente public cloud sono quelli in cui la practice FinOps di Opsio trova le maggiori opportunità di ottimizzazione.

Domande frequenti

Quali sono i 4 modelli di deployment cloud?

I quattro modelli definiti dal NIST SP 800-145 sono: public cloud (infrastruttura condivisa gestita da un provider come AWS, Azure o GCP), private cloud (infrastruttura dedicata a una singola organizzazione), hybrid cloud (carichi di lavoro distribuiti tra ambienti pubblici e privati con orchestrazione tra essi) e community cloud (infrastruttura condivisa tra organizzazioni con requisiti comuni, come le pubbliche amministrazioni). Il multi-cloud — l'utilizzo di più provider pubblici — è spesso considerato un quinto modello nella pratica.

Qual è il modello di deployment cloud più utilizzato?

L'hybrid cloud è il modello più adottato dalle imprese. Il report State of the Cloud di Flexera ha costantemente rilevato che la maggioranza delle aziende persegue una strategia ibrida, combinando risorse on-premises o private cloud con uno o più cloud pubblici. I deployment esclusivamente su public cloud sono più comuni tra startup e organizzazioni di dimensioni ridotte che non dispongono di infrastruttura legacy richiedente integrazione on-premises.

Cosa sono IaaS, PaaS e SaaS e come si relazionano ai modelli di deployment?

IaaS (Infrastructure as a Service), PaaS (Platform as a Service) e SaaS (Software as a Service) sono modelli di servizio cloud — descrivono il livello di astrazione e ciò che il provider gestisce rispetto a ciò che gestisci tu. I modelli di deployment descrivono dove e come l'infrastruttura è ospitata. Le due dimensioni sono indipendenti: puoi eseguire IaaS su un private cloud, consumare PaaS su un public cloud o utilizzare un SaaS erogato tramite un'architettura ibrida. Scegliere un modello di deployment non vincola a un modello di servizio specifico.

AWS è un cloud pubblico, privato o ibrido?

AWS è principalmente un provider di public cloud, ma supporta tutti i modelli di deployment. AWS Outposts porta l'infrastruttura gestita da AWS nel tuo data center on-premises per deployment privati o ibridi. AWS GovCloud fornisce region isolate per carichi di lavoro governativi statunitensi. AWS Local Zones estendono il compute più vicino agli utenti finali. La maggior parte delle organizzazioni utilizza AWS come componente public cloud di una strategia hybrid o multi-cloud più ampia.

L'hybrid cloud è più economico del private cloud?

Il costo dipende interamente dal profilo del carico di lavoro. L'hybrid cloud in genere riduce i costi per carichi di lavoro variabili, perché consente di scalare verso il public cloud anziché sovradimensionare l'infrastruttura privata per la domanda di picco. Tuttavia, l'ibrido introduce costi di rete (tariffe di interconnessione, costi di data transfer), complessità di integrazione e overhead di strumenti aggiuntivi. Per carichi di lavoro a stato stazionario con utilizzo costantemente elevato, il private cloud può risultare più conveniente per unità di calcolo. L'approccio rigoroso: modellare il TCO per i propri carichi di lavoro specifici su entrambi i modelli prima di decidere.