“Cloud” è una parola che si usa per indicare tante cose, e spesso diverse tra loro. Sotto la stessa etichetta convivono modelli differenti in termini di architettura, caratteristiche, profilo di costo e ripartizione delle responsabilità tra fornitore e cliente.
Oggi ci mettiamo nei panni delle realtà che vogliono spostare servizi e applicazioni in cloud senza avere alle spalle un reparto IT strutturato. In questo articolo proponiamo un glossario cloud introduttivo ai principali termini che si incontrano approcciando questo ambito, con l’obiettivo di fare un po’ più di chiarezza su un argomento tanto attuale quanto complesso.
Cos’è il Cloud?
Partiamo dalla definizione cornice: cos’è il cloud? In linea di massima possiamo definirlo come il modello che consente di utilizzare risorse informatiche (potenza di calcolo, spazio di archiviazione, applicazioni), erogate da un fornitore, attraverso la rete e pagate in base all’uso, senza acquistare e gestire direttamente l’hardware.
1. IaaS, PaaS e SaaS: i tre modelli di servizio
Prima delle sigle conviene fissare il concetto che le tiene insieme. Nel cloud ogni risorsa informatica viene erogata come servizio, ed è questo il senso del suffisso aaS (as a service): l’azienda non acquista hardware e, dove previsto, nemmeno la gestione sistemistica, ma utilizza un servizio fornito e mantenuto dal provider.
Le lettere che precedono la sigla indicano quale servizio si sta comprando: infrastruttura (IaaS), piattaforma (PaaS), software (SaaS). Sono i tre modelli di base, ai quali si affiancano altre voci che vedremo al punto 6, dal data center al backup fino al disaster recovery.
IaaS
L’Infrastructure as a Service mette a disposizione le risorse infrastrutturali di base in forma virtuale: vCPU, vRAM, vStorage, vNetwork. In pratica fornisce l’equivalente di un server fisico, costruito però con componenti virtuali erogati nella quantità necessaria e scalabili nel tempo.
Il provider si occupa dell’hardware e del livello di virtualizzazione, mentre il cliente installa e gestisce sistemi operativi e applicazioni. È il modello che più si avvicina all’esperienza del server in azienda, senza l’onere dell’acquisto e della manutenzione del “ferro”. Chi sposta un gestionale o un file server in cloud, nella maggior parte dei casi, sta comprando IaaS. Ne abbiamo parlato anche nell’articolo dedicato alla IaaS ibrida.
PaaS
Il Platform as a Service è la fornitura di servizi informatici già configurati e gestiti direttamente dal provider, che il cliente si limita a utilizzare.
Due esempi rendono l’idea meglio di qualsiasi definizione. Un database pronto all’uso, che il provider mantiene operativo e aggiornato nel tempo e a cui il cliente deve solo collegarsi. Oppure un web server già attivo ed esposto su internet, gestito dal provider, sul quale il cliente installa le proprie applicazioni web. L’unico punto di contatto tra le due parti riguarda la compatibilità delle applicazioni del cliente con gli aggiornamenti che il provider deve eseguire sul servizio.
Riguarda soprattutto chi produce software o ha applicazioni proprietarie da far girare, e incide in modo diretto sui tempi di rilascio.
SaaS
Il Software as a Service è il software pronto all’uso, accessibile da browser e pagato in abbonamento. Esempi sono la posta elettronica aziendale, il CRM, il gestionale documentale. In pratica il cliente usa l’applicazione senza vedere nulla di ciò che c’è sotto.
È il modello che quasi tutte le aziende già utilizzano, spesso senza chiamarlo cloud.
Chi gestisce cosa nei tre modelli
| Livello | IaaS | PaaS | SaaS |
|---|---|---|---|
| Data center, hardware, rete | Provider | Provider | Provider |
| Virtualizzazione | Provider | Provider | Provider |
| Sistema operativo | Cliente | Provider | Provider |
| Database e runtime | Cliente | Provider | Provider |
| Applicazione | Cliente | Cliente | Provider |
| Dati, utenti e permessi | Cliente | Cliente | Cliente |
L’ultima riga è quella che genera più equivoci: i dati e la gestione degli accessi restano in capo al cliente in tutti e tre i modelli.
2. Cloud pubblico, privato, ibrido e multicloud
Se le sigle aaS dicono quali servizi informatici stai comprando, questi quattro termini dicono come e dove vengono erogati, e di conseguenza quale livello di qualità e di efficienza puoi aspettarti.
Cloud pubblico
Si parla di cloud pubblico quando le risorse risiedono sull’infrastruttura del provider e sono condivise tra più clienti, con isolamento logico. È il modello più elastico e con la soglia d’ingresso più bassa. Il provider possiede, amministra e mantiene l’hardware e i data center, mentre l’utente finale accede ai servizi via browser o tramite rete. Solitamente il pagamento è a consumo, così da pagare solo le risorse effettivamente utilizzate. I vantaggi riguardano, soprattutto, la scalabilità tecnologica ed economica, nonché zero preoccupazioni in termini di manutenzione.
Cloud privato
Nel caso del cloud privato, l’infrastruttura è dedicata a una sola organizzazione. Può stare nella sede del cliente, presso il data center del provider (il cosiddetto hosted private cloud) oppure consistere in una porzione dell’infrastruttura fisica del provider riservata a un unico cliente, per esempio un singolo server dedicato.
Sicuramente ha costi più elevati, compensati, però, da un controllo e una prevedibilità maggiori. L’azienda, infatti, decide le regole di sicurezza, le configurazioni e le politiche di accesso. In questo caso i benefici maggiori sono relativi a sicurezza, personalizzazione, privacy e prestazioni, che non risentono della condivisione delle risorse con altri clienti.
Cloud ibrido
Il cloud ibrido è sostanzialmente la combinazione dei due modelli precedenti, con i carichi distribuiti in base a criticità, requisiti normativi, costi e vincoli architetturali. Quest’ultimo aspetto pesa più di quanto si immagini: alcune applicazioni CAD, o i software che pilotano torni e macchine di produzione collegati alla rete di stabilimento, non funzionano se fatti girare attraverso una WAN e devono restare on-premise.
È l’assetto verso cui converge la maggior parte delle organizzazioni, perché consente di tenere su risorse dedicate i dati più sensibili, di lasciare in sede ciò che tecnicamente non può muoversi e di spostare sul pubblico ciò che deve scalare. Un’architettura ibrida, del resto, riflette spesso l’infrastruttura reale dell’azienda, dal momento che collega l’hardware presente in ufficio con spazi esterni gestiti dai provider. I vantaggi riguardano la flessibilità in relazione al traffico, la sicurezza dei dati critici e il risparmio economico.
Multicloud
Con multicloud si fa riferimento all’uso di più servizi cloud in parallelo, tipicamente forniti da soggetti diversi. Nella pratica quotidiana significa avere Microsoft 365 per produttività e posta, un CRM in cloud, un servizio di archiviazione e magari uno strumento dedicato alla condivisione di file di grandi dimensioni.
Non nasce quasi mai da una scelta strategica di ridurre la dipendenza da un singolo fornitore, ma dall’esigenza concreta di usare per ogni funzione il servizio più adatto. Il beneficio sta proprio in questo, insieme a affidabilità e continuità operativa. Il rovescio della medaglia è l’aumento della complessità gestionale, che riguarda soprattutto identità, permessi e monitoraggio dei costi sparsi su più contratti.
I modelli di Cloud a confronto
| Modello | Quando ha senso |
|---|---|
| Pubblico | Carichi variabili, necessità di partire in fretta, nessun investimento iniziale in hardware. |
| Privato | Requisiti normativi stringenti, prestazioni prevedibili, controllo diretto sull’ambiente. |
| Ibrido | Una parte dei dati deve restare su infrastruttura dedicata, il resto beneficia dell’elasticità. |
| Multicloud | Esigenza di ridurre la dipendenza da un singolo fornitore o di usare servizi specifici di provider diversi. |
Nel 2025 il mercato cloud italiano ha raggiunto 8,13 miliardi di euro, in crescita del 20% sull’anno precedente. I modelli pubblici e ibridi pesano per il 72% del totale, con 5,8 miliardi di euro e un aumento del 21%, mentre il private cloud cresce del 23%, spinto da esigenze di controllo e da requisiti regolatori[1].
3. Virtualizzazione, hypervisor e macchine virtuali
La virtualizzazione è la tecnica che converte una componente fisica nella corrispondente componente virtuale, rendendola utilizzabile non in modo diretto ma attraverso la sua rappresentazione software. In un ambiente virtualizzato ritroviamo così tutte le componenti tipiche di un server: vCPU, vRAM, vStorage, vNetwork, vGraphicCard.
Queste componenti vengono assegnate a macchine virtuali (VM), cioè server a tutti gli effetti autonomi, con un proprio sistema operativo e un proprio indirizzo di rete, che convivono sulla stessa macchina fisica senza interferire tra loro.
L’hypervisor è il software che rende possibile la virtualizzazione. Agisce come un amministratore che divide e assegna le risorse, tiene isolati gli ambienti e gestisce l’avvio e lo spegnimento delle macchine.
C’è un aspetto che raramente compare nelle offerte e che invece incide parecchio. L’hypervisor può assegnare complessivamente più risorse virtuali di quelle fisicamente presenti, e il rapporto tra le due grandezze determina quante macchine virtuali condividono la stessa risorsa fisica. Un moltiplicatore alto significa più VM sullo stesso hardware e, di conseguenza, prestazioni inferiori per ciascuna. È uno dei motivi per cui a parità di risorse dichiarate il prezzo tra un provider e l’altro può cambiare in modo sensibile, e vale la pena chiedere come sono dimensionati gli ambienti prima di confrontare due preventivi.
Il vantaggio pratico della macchina virtuale sta nella sua indipendenza dall’hardware: può essere spostata su un altro nodo fisico, clonata o ripristinata da backup senza toccare il ferro, ed è questa proprietà a rendere possibili continuità operativa e disaster recovery in tempi impensabili con i server tradizionali.
4. Container e orchestrazione
I container vengono spesso presentati come l’evoluzione della macchina virtuale, ma l’accostamento più corretto è con il PaaS. Un container, infatti, impacchetta la singola applicazione con tutto il software necessario alla sua esecuzione, senza dipendere da un ambiente di virtualizzazione.
La differenza si vede quando si prova a spostarli. Una macchina virtuale creata su una determinata piattaforma di virtualizzazione non può essere trasferita così com’è su una piattaforma diversa, perché resta legata all’ambiente in cui è nata. Un container, al contrario, gira su qualsiasi macchina dotata dello stesso motore di esecuzione, indipendentemente dalla piattaforma e dal sistema operativo sottostante. A questo si aggiunge il fatto che occupa meno risorse e si avvia in pochi secondi.
L’orchestrazione è la gestione automatica dei container, specialmente quando il loro numero inizia a diventare importante. Questa attività definisce dove avviarli, quanti tenerne attivi, come sostituire quelli che smettono di rispondere. In materia di orchestrazione sentirai spesso parlare di due strumenti: Kubernetes, la piattaforma open source più diffusa e usata al mondo, e Docker Swarm, uno strumento nativo più semplice e agile pensato per progetti ridotti.
5. Scalabilità, elasticità e modello a consumo
Anche in questo caso si tratta di concetti correlati tra loro. La scalabilità è la capacità di aumentare le risorse assegnate a un servizio quando il carico cresce. L’elasticità aggiunge la direzione opposta e l’automatismo, descrivendo il processo automatico per cui le risorse crescono nei momenti di picco e si riducono quando questo picco è passato, senza intervento manuale.
Il modello a consumo (pay-per-use) è semplicemente la logica di fatturazione che ne deriva. Non si paga un canone o un costo fisso ma ciò che si utilizza davvero, misurato in ore di calcolo, gigabyte occupati, traffico generato.
Un aspetto rilevante su cui vale la pena soffermarsi un attimo è quello inerente alla gestione del budget IT. Investire nel Cloud significa non avere l’impegnativa spesa inziale richiesta dall’acquisto del “ferro” ma affrontare un costo che segue l’andamento dell’uso. È una spesa variabile, quindi, che se non viene presidiata adeguatamente tende a crescere in silenzio. Ecco perché sono richiesti monitoraggio, disciplina e ottimizzazione dei costi.
6. La famiglia “As-a-Service”
Come anticipato al punto 1, il suffisso AaS, sigla per As-a-Service, si è esteso a qualsiasi servizio informatico ed è estremamente comune quando si parla di ecosistema Cloud. È un acronimo che indica un modello di distribuzione in cui una risorsa non viene acquistata come bene fisico, ma viene “noleggiata” come servizio on-demand, solitamente tramite un abbonamento.
Di seguito trovi le sigle che compaiono più spesso.
| Sigla | Per esteso | Cosa comprende |
|---|---|---|
| IaaS | Infrastructure as a Service | Macchine virtuali, storage e rete erogati come servizio |
| DCaaS | Data Center as a Service | Spazio, alimentazione, raffreddamento e connettività di data center fruiti come servizio, senza acquistare né gestire la struttura |
| StaaS | Storage as a Service | Spazio di archiviazione scalabile, fatturato sull’occupazione effettiva |
| NaaS | Network as a Service | Connettività e servizi di rete progettati e gestiti dal provider |
| BaaS | Backup as a Service | Backup gestito, con politiche di conservazione e verifica dei ripristini |
| DRaaS | Disaster Recovery as a Service | Ambiente di ripartenza per il ripristino dei sistemi dopo un incidente |
| FWaaS | Firewall as a Service | Firewall erogato e monitorato dal provider, senza apparato in sede |
Un piccolo appunto: BaaS e DRaaS sono due servizi che si valutano guardando principalmente RPO e RTO, cioè quanti dati si è disposti a perdere e per quanto tempo si può restare fermi. Sono due parametri che qui non approfondiamo perché li abbiamo spiegati nel glossario Data Center.
7. Migrazione al cloud e vendor lock-in
Nell’ambito del cloud computing è importante avere consapevolezza delle modalità di implementazione di queste tecnologie e delle dinamiche che ti legano, in quanto cliente, al fornitore a cui decidi di affidarti.
La migrazione
La migrazione è il processo di trasferimento di applicazioni e dati verso il cloud. Le modalità sono differenti e, di conseguenza, variano anche tempistiche e costi.
L’approccio più rapido è il lift-and-shift, che consiste nel prendere i server virtuali così come sono e spostarli sull’infrastruttura del provider. Funziona ed è veloce, ma porta con sé eventuali difetti e inefficienze del sistema di partenza. Va detto che è praticabile soprattutto verso cloud privati: sul cloud pubblico i provider difficilmente lo accettano, perché significherebbe accogliere macchine con sistemi operativi obsoleti o non più supportati, licenze non in regola, indirizzamenti di rete incompatibili e vulnerabilità note. Sono proprio licenze, indirizzi di rete e versioni del software i tre punti su cui si arena la maggior parte dei progetti impostati così.
Il refactoring, al lato opposto, riscrive l’applicazione per sfruttare l’architettura cloud. È l’approccio preferibile, perché restituisce sicurezza e affidabilità insieme all’aggiornamento applicativo, ma resta interamente a carico del cliente in termini di costi e di lavoro.
La via di mezzo è il replatforming, che interviene soltanto su alcune componenti, per esempio sostituendo un database gestito in proprio con uno gestito dal fornitore.
Il vendor lock-in
Il vendor lock-in è la dipendenza tecnica ed economica nei confronti di un fornitore, al punto da rendere il cambio difficile o troppo oneroso. Nasce da formati proprietari, servizi gestiti non replicabili altrove, costi di estrazione dei dati.
Su questo fronte il quadro normativo è recentemente cambiato. Il Data Act europeo, applicabile dal 12 settembre 2025, fissa un preavviso massimo di due mesi a carico del cliente, prevede un periodo di transizione che di norma non supera i 30 giorni (prorogabile nei casi tecnicamente motivati), obbliga il fornitore ad assistere il cliente nel trasferimento e stabilisce l’abolizione dei costi di uscita a partire dal 2027. Fino a quella data vale un regime transitorio in cui possono essere addebitati solo i costi direttamente connessi al passaggio.
La norma, tuttavia, elimina la barriera economica, non quella tecnica. Un’architettura costruita su servizi difficilmente replicabili altrove resta complicata da spostare anche quando l’uscita è gratuita.
8. Tenant e multi-tenancy
Il tenant è l’ambiente cloud dedicato e completamente isolato assegnato a un singolo cliente, all’interno del quale il cliente dispone di accesso amministrativo e può gestire ogni componente, servizio e impostazione, fino alla personalizzazione di grafica e loghi. Dati, utenze e configurazioni restano separati da quelli di chiunque altro.
La multi-tenancy è la capacità di una piattaforma di replicare quello stesso ambiente per più clienti sulla medesima infrastruttura fisica, senza che tra i tenant esista alcun legame, relazione o dipendenza. L’isolamento è logico, garantito da meccanismi di segregazione a livello di rete, storage e identità, non dalla presenza di macchine fisiche separate.
Per il cliente finale la distinzione ha un impatto limitato. Diventa rilevante per chi rivende servizi informatici, perché è la multi-tenancy a consentire di fornire a ogni proprio cliente un ambiente dedicato e amministrabile in autonomia. Sul lato del provider, invece, è la condizione tecnica che rende gestibili i servizi aaS su larga scala
9. Responsabilità condivisa
Il modello di responsabilità condivisa definisce la linea che separa ciò di cui risponde il provider da ciò di cui risponde il cliente. Non è una linea fissa: si sposta a seconda del servizio acquistato.
La tabella del punto 1 lo mostra per i tre modelli di base. Nello IaaS il provider risponde di data center, hardware e virtualizzazione, mentre sistemi operativi, aggiornamenti e applicazioni restano al cliente. Con PaaS il provider si fa carico anche del sistema operativo e del mantenimento del servizio, e al cliente resta la sola applicazione. Attraverso il SaaS al cliente resta la configurazione dell’applicativo e la gestione di chi vi accede.
Il ragionamento vale anche per gli altri servizi della famiglia. In un BaaS il provider garantisce l’esecuzione, la conservazione e la verificabilità dei backup, mentre stabilire cosa vada salvato e con quale frequenza è una decisione dell’azienda. In un DRaaS il provider mette a disposizione l’ambiente di ripartenza e le procedure, ma le priorità di ripristino e il collaudo periodico del piano vanno definiti insieme al cliente.
Attraverso tutti i modelli resta però una costante: configurazioni, gestione delle utenze, permessi, autenticazione a più fattori e classificazione dei dati sono sempre in capo al cliente. Una parte consistente degli incidenti su ambienti cloud nasce proprio da questa metà del confine. Sui termini della sicurezza informatica abbiamo pubblicato un glossario dedicato, e la nostra divisione cybersecurity Orazero si occupa di presidiarla
10. Residenza del dato e sovranità del dato
Concludiamo il glossario con un’ultima distinzione che riguarda il dato.
Residenza del dato
La residenza del dato indica dove risiedono fisicamente le informazioni, cioè in quale data center e in quale Paese. È un’informazione che deve comparire in modo esplicito e riguardare anche le copie di backup, qualora siano conservate in località diverse rispetto agli originali.
Definire adeguatamente la residenza del dato a livello contrattuale permette di rispettare la normativa nazionale ed europea, come il GDPR, e ottimizzare la sicurezza, evitando trasferimenti non desiderati all’estero.
Sovranità del dato
Distinta dalla residenza è la sovranità del dato, che riguarda la giurisdizione a cui i dati sono soggetti e quindi quali autorità possono avanzare richieste di accesso. Il tema si intreccia con la nazionalità del fornitore, oltre che con la posizione geografica dei server, e lo abbiamo approfondito nel glossario Data Center.
FAQ — Glossario Cloud: le domande più frequenti
In questa sezione rispondiamo ad alcune delle domande che riceviamo più spesso quando si parla di cloud.
La differenza sta in quanta parte dell’infrastruttura viene gestita dal fornitore. Tramite IaaS il provider dà macchine virtuali, storage e rete, mentre il cliente installa e gestisce sistemi operativi e applicazioni. Attraverso il PaaS, invece, il provider gestisce anche sistema operativo, database e aggiornamenti, e il cliente si occupa solo delle proprie applicazioni. Con SaaS, infine, il software è pronto all’uso e accessibile da browser, e il cliente gestisce esclusivamente i propri dati, gli utenti e i permessi.
Il cloud ibrido combina cloud pubblico e infrastruttura privata o dedicata, distribuendo i carichi di lavoro tra i due ambienti. Conviene quando alcuni dati o applicazioni devono restare su infrastruttura dedicata per motivi normativi, di prestazioni o di controllo, mentre altri servizi traggono vantaggio dall’elasticità del cloud pubblico. È l’assetto verso cui converge la maggior parte delle organizzazioni che partono da un’infrastruttura già esistente e non vogliono spostare tutto in una volta.
La virtualizzazione è la tecnica che permette a una singola macchina fisica di ospitare macchine virtuali. Un software chiamato hypervisor suddivide le risorse di calcolo, memoria e rete tra i diversi ambienti e li mantiene isolati. È la tecnologia che sta alla base del cloud e che rende possibile spostare, clonare o ripristinare un server senza intervenire sull’hardware.
Significa che il costo del servizio è calcolato sulle risorse effettivamente utilizzate, misurate in ore di calcolo, spazio occupato o traffico generato, anziché su un investimento iniziale in hardware. Il modello sposta la spesa da investimento in conto capitale a costo operativo ricorrente. Richiede però un monitoraggio periodico, perché una spesa variabile non presidiata tende a crescere con l’aumentare dell’uso.
È il criterio che stabilisce quali aspetti della sicurezza sono in capo al fornitore e quali restano al cliente. Il provider risponde della sicurezza dell’infrastruttura, quindi data center, hardware, virtualizzazione e piattaforma. Al cliente restano le configurazioni, la gestione delle utenze e dei permessi, l’autenticazione e la classificazione dei propri dati, in tutti i modelli di servizio compreso il SaaS.
Dipende dal fornitore e va verificato nel contratto. La residenza del dato indica il data center e il Paese in cui le informazioni risiedono fisicamente, e va richiesta esplicitamente anche per le copie di backup, che non sempre si trovano nella stessa sede dei dati primari. Distinto dalla residenza è il tema della sovranità, che riguarda la giurisdizione a cui i dati sono soggetti e quindi quali autorità possono richiederne l’accesso.
Il vendor lock-in è la dipendenza tecnica ed economica da un fornitore che rende difficile o troppo oneroso il passaggio a un altro. Per limitarlo conviene privilegiare formati e tecnologie standard, verificare prima della firma in quale formato e in quanto tempo i dati vengono restituiti e definire una strategia di uscita già in fase contrattuale. Dal 12 gennaio 2027 il Data Act europeo vieta ai fornitori cloud di applicare costi per il cambio di provider, ma la barriera tecnica resta e va valutata a monte.
Perché affidarsi al cloud di Planetel
I nostri servizi cloud girano sulla nostra infrastruttura e nei nostri data center in Italia. Sette strutture collegate da rete in fibra ottica proprietaria in modo interconnesso e ridondato, per assicurare il massimo della performance e della scurezza. A ciò si aggiungerà il nuovo Edge Data Center di Padova, ormai in fase di finalizzazione.
Inoltre, sarai seguito da professionisti esperti e qualificati; non ti venderemo mai pacchetti standardizzati ma soluzioni in linea con le tue esigenze.
Se stai valutando uno spostamento in cloud o vuoi ottimizzare la tua strategia infrastrutturale siamo disponibili per un confronto diretto. Puoi scrivere alla nostra area Cloud all’indirizzo [email protected] oppure chiamare il numero 035 204461.
[1] Osservatorio Cloud Transformation del Politecnico di Milano