Un hosting cloud aziendale non si sceglie confrontando soltanto memoria, spazio disco e canone mensile. Il servizio deve sostenere un’applicazione concreta, mantenere dati recuperabili, reagire ai picchi e offrire un percorso di uscita. La domanda utile non è quindi “quanto cloud compro?”, ma “quale servizio deve continuare a funzionare, entro quali limiti e con quali responsabilità?”.
Il termine cloud copre offerte molto diverse: hosting gestito, macchine virtuali, container, piattaforme applicative e servizi interamente amministrati dal fornitore. Due preventivi con la stessa quantità di CPU possono trasferire al cliente attività opposte. Prima del prezzo vanno chiariti modello operativo, confine della gestione e risultato atteso.
Che cosa si sta acquistando davvero
Nel modello IaaS il provider gestisce datacenter, rete, hardware e virtualizzazione; il cliente conserva normalmente sistemi operativi, configurazioni, applicazioni e molti controlli. Nel PaaS una parte maggiore dello stack viene amministrata dal fornitore. Nell’hosting gestito, invece, il contratto può includere patch, monitoraggio e assistenza applicativa, ma la parola “gestito” non ha un contenuto identico per tutti.
Il capitolato deve elencare ogni livello: dominio, DNS, certificati, bilanciamento, sistema operativo, runtime, database, backup, monitoraggio, sicurezza e applicazione. Per ciascuno si indica chi configura, aggiorna, controlla e interviene. Una matrice di responsabilità semplice evita che un guasto venga scoperto nel punto lasciato implicitamente a carico dell’altra parte.
Occorre poi distinguere risorse garantite da limiti massimi. “Quattro vCPU” può significare capacità condivisa soggetta a contesa oppure quota riservata. Lo stesso vale per IOPS del disco, memoria e banda. Senza metodo di misura, un numero in scheda non dimostra la prestazione ottenibile dall’applicazione.
| Area | Domanda da porre | Prova o dato utile |
|---|---|---|
| Calcolo | Risorse riservate, condivise o scalabili? | vCPU, RAM, limiti, burst e test al picco |
| Storage | Quali prestazioni e quale ridondanza? | IOPS, latenza, replica, snapshot e quota |
| Disponibilità | Dove viene misurata e quali esclusioni esistono? | SLA, storico incidenti, zone e rimedio |
| Backup | Quanto si può perdere e quanto dura il ripristino? | RPO, RTO, retention e verbale dei test |
| Sicurezza | Chi protegge identità, dati e configurazioni? | MFA, log, cifratura, ruoli e gestione incidenti |
| Uscita | Come si esporta e si cancella tutto? | Formati, tempi, costi e attestazione finale |
Dimensionare CPU, memoria e storage sul carico reale
Il numero medio di visitatori è un indicatore debole. Una pagina statica, un gestionale con query complesse e un e-commerce durante una promozione consumano risorse in modo diverso. Servono misure di CPU, memoria, latenza, operazioni disco, connessioni al database e traffico nelle ore di picco, includendo attività pianificate come backup e importazioni.
Per un sistema esistente conviene osservare almeno un periodo rappresentativo e segnare picco normale, picco eccezionale e crescita prevista. Per un servizio nuovo si parte da un test di carico con scenari dichiarati. Le ipotesi vanno conservate: consentono di capire se il dimensionamento era errato o se il comportamento è cambiato.
Lo storage richiede più attenzione dello spazio occupato. Un database può utilizzare pochi gigabyte ma necessitare bassa latenza e molte operazioni al secondo. Un archivio documentale può privilegiare capacità e durata. Il preventivo deve separare volume, prestazioni, snapshot, copie, letture, scritture e trasferimenti.
La scalabilità non elimina il dimensionamento: sposta il problema su soglie, tempi e costo. Un autoscaling troppo lento non protegge un picco improvviso; uno troppo aggressivo moltiplica le istanze e la fattura. Servono limite massimo, avvisi, regole di riduzione e un test che dimostri il ritorno alla capacità ordinaria.
SLA: come tradurre una percentuale in minuti
Uno SLA del 99,9% corrisponde, in un mese medio di 30,44 giorni, a circa 43 minuti e 50 secondi di indisponibilità. Il 99,95% vale circa 21 minuti e 55 secondi; il 99,99% circa 4 minuti e 23 secondi. Il calcolo è utile, ma non descrive ancora il contratto.
Bisogna leggere il punto di misura. Il provider può misurare soltanto la macchina virtuale, mentre il cliente percepisce il servizio completo: DNS, rete, database, applicazione e autenticazione. Se uno di questi elementi non rientra nell’indicatore, la piattaforma può risultare “disponibile” mentre gli utenti non riescono a lavorare.
Le finestre di manutenzione, gli eventi attribuiti al cliente e alcune dipendenze possono essere esclusi. Anche il rimedio conta: spesso è un credito sul canone e non il risarcimento del danno. La percentuale va quindi confrontata con architettura, storico degli incidenti, comunicazioni e procedura per chiedere il credito.
Un servizio critico richiede ridondanza vera. Due istanze nello stesso dominio di guasto non equivalgono a due zone indipendenti. Anche DNS, database e storage devono seguire il disegno. La guida CurioMondo sulla fibra aziendale e gli SLA aiuta a valutare l’altra metà del percorso: la connettività tra impresa e cloud.
Backup e disaster recovery non sono sinonimi
Il backup conserva copie da cui recuperare dati; il disaster recovery descrive come ripristinare un servizio dopo un evento grave. Avere snapshot automatici non significa possedere un piano di continuità. Lo snapshot può trovarsi nello stesso account, dipendere dallo stesso controllo amministrativo o non contenere tutte le componenti necessarie.
Due parametri aiutano a chiarire il risultato. L’RPO indica quanti dati l’impresa può accettare di perdere: con un RPO di un’ora, l’obiettivo è tornare a una copia vecchia al massimo sessanta minuti. L’RTO indica entro quanto tempo il servizio dovrebbe essere ripristinato.
La frequenza delle copie deve derivare dall’RPO, non da una formula standard. La retention deve coprire errori scoperti tardi e attacchi che alterano gradualmente i dati. Almeno una copia dovrebbe essere protetta da cancellazioni ordinarie e separata dal percorso amministrativo principale, con cifratura e accessi controllati.
Il test di ripristino è il controllo decisivo. Occorre ricostruire un ambiente, recuperare database e file, verificare coerenza e misurare il tempo. Un messaggio “backup completato” conferma l’esecuzione di un processo; non dimostra che l’azienda sappia tornare operativa.
Sicurezza: il cloud non trasferisce tutta la responsabilità
ENISA osserva da tempo che il cloud può offrire difese robuste e scalabili, ma concentra anche risorse appetibili e introduce dipendenze dal fornitore. Il rischio va valutato sull’architettura concreta. Una piattaforma certificata non corregge credenziali condivise, porte esposte o copie accessibili a chi non ne ha bisogno.
Il minimo operativo comprende autenticazione multifattore per gli amministratori, ruoli separati, principio del privilegio minimo, registrazione degli accessi, cifratura in transito e a riposo e procedura per le credenziali di emergenza. Gli account tecnici devono avere proprietario, scopo e rotazione; le chiavi non vanno lasciate nei repository o nei file di configurazione pubblici.
Se il servizio tratta dati personali, l’impresa resta titolare per le proprie finalità e deve inquadrare il fornitore secondo il GDPR. Il contratto deve disciplinare istruzioni, riservatezza, sicurezza, subfornitori, assistenza, restituzione o cancellazione. Il Garante ricorda inoltre che il responsabile deve informare tempestivamente il titolare quando conosce una violazione.
I log devono essere sufficienti a ricostruire eventi e modifiche, protetti dall’alterazione e conservati per un periodo motivato. La quantità ha un costo. Prima di abilitare tutto, si definiscono eventi indispensabili, destinazione, accessi, avvisi e responsabilità di risposta.
Supporto: il tempo di risposta non è il tempo di soluzione
Un’assistenza “24/7” può indicare soltanto la possibilità di aprire un ticket. Il contratto deve distinguere presa in carico, prima risposta, aggiornamenti e ripristino. Per ogni livello di gravità servono criteri oggettivi: quanti utenti sono bloccati, quale funzione manca e quale soluzione temporanea è accettabile.
È utile conoscere il canale di escalation, la lingua, le competenze incluse e le attività escluse. Il provider può risolvere l’infrastruttura ma non il codice dell’applicazione. Un fornitore gestito può intervenire anche sul database o sul sistema operativo. Il confronto è corretto soltanto se copre lo stesso perimetro.
La reperibilità interna completa il servizio esterno. Se nessuno può autorizzare una modifica DNS o fornire una chiave durante la notte, la risposta del provider non basta. Il piano deve indicare contatti, deleghe, accessi di emergenza e criteri per comunicare a clienti e dipendenti.
Come calcolare il costo totale del cloud
Il canone base comprende raramente tutto. Al costo di calcolo e memoria si aggiungono storage, snapshot, backup, IP pubblici, bilanciatori, database, monitoraggio, log, protezioni, supporto e trasferimento dei dati. Alcune voci crescono con il traffico; altre con numero di richieste, zone o ore di utilizzo.
Un esempio semplice mostra il problema. Un preventivo da 280 euro mensili può aggiungere 90 euro di backup, 70 di log, 120 di supporto e una media di 160 per traffico e servizi collegati. Il totale diventa 720 euro prima delle ore interne. Non è un prezzo di mercato: è un modello per rendere comparabili le voci.
Il calcolo annuale dovrebbe includere migrazione iniziale, configurazione, test, formazione, gestione ordinaria e uscita. Per i picchi si costruiscono almeno tre scenari: normale, alto e straordinario. Gli avvisi di budget non sostituiscono un limite tecnico, ma permettono di intervenire prima della fattura.
La gestione economica deve conservare il legame con la prestazione. Ridurre copie, log o ridondanza può abbassare il costo e aumentare il rischio. L’obiettivo non è la spesa minima, ma il costo più basso compatibile con continuità, sicurezza e recuperabilità dichiarate.
Portabilità e uscita: progettare il cambio prima dell’ingresso
Il Regolamento europeo sui dati, noto come Data Act, contiene regole per agevolare il passaggio tra servizi di trattamento dati. Il quadro europeo non rende però ogni applicazione automaticamente portabile. Formati, dipendenze, database, automazioni e servizi proprietari continuano a determinare la complessità tecnica.
Il contratto deve specificare quali dati vengono esportati, in quale formato, con quali metadati e in quanto tempo. Occorre includere configurazioni, log necessari, immagini di sistema, chiavi gestite dal cliente e documentazione. Un archivio di file senza schema del database può essere formalmente completo ma inutilizzabile.
Vanno definiti costi di trasferimento, assistenza, periodo di sovrapposizione e cancellazione finale. La cancellazione deve comprendere copie operative e seguire i tempi dichiarati per i backup, salvo obblighi di conservazione. Un’attestazione aiuta a chiudere il rapporto, ma l’impresa deve revocare anche account, token e integrazioni.
La portabilità si testa con piccole esportazioni durante il contratto. Questo controllo rivela formati incompleti, tempi inattesi e dipendenze nascoste. La stessa logica vale per l’analisi degli incidenti: la guida sulla forensic investigation informatica spiega perché log e catena di conservazione vanno pianificati prima dell’emergenza.
Una procedura di selezione in sette passaggi
Primo: descrivere servizi, utenti, dati e conseguenze di un’interruzione. Secondo: misurare il carico o documentare le ipotesi. Terzo: fissare RPO, RTO e disponibilità. Quarto: compilare la matrice delle responsabilità. Quinto: chiedere un costo totale per tre scenari.
Sesto: eseguire una prova limitata con carico, ripristino e assistenza reale. Settimo: verificare l’uscita esportando dati e configurazioni. Ogni prova deve avere criteri di accettazione scritti. Una demo fluida non sostituisce un test nel quale il fornitore deve affrontare un guasto, un picco o un recupero.
Il confronto finale può assegnare pesi a prestazioni, continuità, sicurezza, supporto, costo e portabilità. I punteggi non devono nascondere requisiti bloccanti. Un’offerta economica che non soddisfa l’RTO o non consente l’esportazione necessaria resta inadatta, anche se ottiene una media elevata.
FAQ sull’hosting cloud aziendale
Cloud hosting e hosting condiviso sono la stessa cosa?
No. Nell’hosting condiviso più clienti usano risorse dello stesso server secondo limiti prestabiliti; un servizio cloud può distribuire componenti e capacità su più sistemi. Il nome commerciale non basta: occorre leggere architettura, isolamento, risorse e responsabilità.
Uno SLA del 99,9% garantisce che il sito non si fermerà?
No. Lo SLA definisce misura, esclusioni e rimedi contrattuali; non elimina guasti, errori applicativi o dipendenze esterne. Il 99,9% corrisponde a circa 43 minuti e 50 secondi di indisponibilità in un mese medio, se misurato senza esclusioni.
Il backup incluso dal provider è sufficiente?
Solo se frequenza, retention, isolamento, cifratura, tempi di ripristino e test corrispondono alle esigenze aziendali. Una copia nello stesso dominio amministrativo non copre tutti gli scenari; il ripristino va provato.
Come evitare il lock-in del fornitore cloud?
Occorre definire prima dell’acquisto formati di esportazione, tempi, costi, assistenza alla migrazione, cancellazione dei dati e dipendenze proprietarie. La portabilità assoluta non esiste, ma una strategia di uscita riduce tempi e sorprese.
Qual è il costo mensile corretto da confrontare?
Il costo totale: capacità, traffico in uscita, storage, backup, log, IP, sicurezza, supporto, gestione, migrazione e costo atteso dei picchi. Confrontare soltanto il canone base produce preventivi incompleti.
Un buon hosting cloud rende verificabili capacità, continuità, recupero e responsabilità. Il contratto migliore non è quello con più servizi nominati, ma quello in cui l’impresa sa misurare ciò che riceve, ripristinare ciò che perde e trasferire ciò che le appartiene.