Hosting e cloud per imprese: ubicazione dati, SLA e criteri di scelta

Hosting e cloud per imprese: cosa valutare davvero

Hosting e cloud non sono sinonimi. L'hosting è l'ospitalità di un server o di un'applicazione in una struttura gestita da terzi; il cloud è un modello di erogazione di risorse di calcolo, memoria e storage accessibili da remoto via rete.

Nel cloud i costi sono legati all'utilizzo effettivo e molte offerte sono ibride. Un'impresa può avere applicazioni in cloud pubblico, un server dedicato in housing e un database gestito dal fornitore, tutto nello stesso disegno infrastrutturale.

Amazon, Google e Microsoft sono i colossi ICT che hanno costruito infrastrutture proprie a supporto del cloud. IBM pubblica documentazione dedicata agli SLA.

Per Microsoft Azure il cloud computing è un pilastro delle operazioni aziendali moderne. Per le organizzazioni di ogni settore, spostare i carichi di lavoro nel cloud può portare a maggiore scalabilità, a un risparmio sui costi dell'infrastruttura IT e all'accesso a tecnologie come intelligenza artificiale e apprendimento automatico.

Azure ricorda che la scelta di un provider di servizi cloud è una decisione strategica e richiede di valutare molti fattori. Tra questi c'è l'impegno del provider a offrire strumenti flessibili e scalabili per innovare in modo sicuro anche in prospettiva futura.

Il cloud storage aziendale riguarda la conservazione dei dati; il cloud computing riguarda l'uso di software e risorse di elaborazione in remoto. Le offerte per le imprese spesso combinano entrambi.

Per il cloud pubblico i nomi di riferimento sono Microsoft Azure e AWS. Azure è il cloud di Microsoft; AWS è il cloud di Amazon. AWS pubblica documentazione sulle tipologie e sugli elementi comuni dei contratti sul livello di servizio applicati ai propri servizi. IBM pubblica documentazione dedicata agli SLA e alle tre tipologie più comuni: a livello di cliente, a livello di servizio e multilivello.

Adottare un cloud aziendale significa accedere a risorse, applicazioni e dati tramite connessione Internet, archiviando e gestendo le informazioni in modo flessibile ed efficiente, senza dipendere da costosi server fisici o infrastrutture on-premise. La possibilità di lavorare da remoto favorisce una maggiore flessibilità operativa, consentendo ai dipendenti di collaborare da qualsiasi luogo. La sicurezza avanzata dei servizi cloud assicura la protezione dei dati sensibili, con procedure di crittografia e protezione delle informazioni costantemente aggiornate.

Sul fronte dei nomi, Azure è il cloud di Microsoft; AWS è il cloud di Amazon. AWS offre contratti sul livello di servizio per i propri servizi e ne pubblica tipologie ed elementi comuni; IBM pubblica documentazione dedicata agli SLA e alle tre tipologie più comuni: a livello di cliente, a livello di servizio e multilivello.

Ubicazione dei dati e territorialità: residenza, sovranità e prossimità

Quando si parla di ubicazione dei dati conviene distinguere residenza e sovranità. La residenza riguarda il luogo, fisico o logico, in cui i dati sono archiviati ed elaborati: un'area geografica, un data center, una regione cloud. La sovranità riguarda invece l'insieme di leggi, autorità e poteri che si applicano a quei dati. Può incidere su chi vi può accedere e a quali condizioni.

Sono piani diversi. Un dato residente in Italia può essere sottoposto a obblighi di fornitori esteri. Un dato ospitato all'estero può rientrare in un assetto contrattuale che ne limita l'accesso.

Le normative su privacy e sicurezza dei dati variano da Paese a Paese e la conformità può essere complessa per le aziende che operano a livello globale. Per un'impresa italiana la posizione dei dati non è solo una scelta di prestazioni: è un elemento da verificare rispetto agli obblighi di protezione dei dati applicabili.

In Italia il tema della territorialità è tornato di stretta attualità con il GDPR, il regolamento sulla gestione della privacy e dei dati che mira a normare i nuovi paradigmi IT. Molti provider hanno investito nella costruzione di nuovi data center. Hanno insistito sul valore, per le imprese, di avere sul proprio territorio uno spazio cloud sicuro a cui affidare server, dati e informazioni.

I data center vengono descritti come il cuore pulsante del business. Sono sale che ospitano server, storage, gruppi di continuità e tutte le apparecchiature che consentono di governare processi, comunicazioni e servizi a supporto delle attività aziendali.

Le stime sulle strutture italiane non concordano. Secondo alcune rilevazioni sono più di 1000; secondo altre circa 54. Tra i grandi provider con infrastrutture a supporto del cloud figurano Amazon, Google e Microsoft.

L'offerta italiana affianca data center proprietari, data center di grandi provider nati per servizi pay per use e spazi per imprese sul territorio. Accanto agli aspetti legali c'è la prossimità fisica, che ha effetti pratici: la distanza tra i sistemi dell'impresa, gli utenti e il data center incide sulla latenza percepita.

La collocazione dei backup e delle copie di sicurezza determina quanto rapidamente si può ripartire dopo un incidente. La vicinanza geografica può rendere più semplici interventi, trasferimenti di grandi volumi di dati e verifiche.

Prima di firmare è utile farsi indicare per iscritto il Paese. Va chiesta anche la regione e, dove possibile, la struttura che ospiterà dati e repliche.

In colocation e housing il data center garantisce connettività, alimentazione ridondata, raffreddamento e sicurezza fisica. Sono elementi da verificare quando si valuta la prossimità fisica.

Per i grandi provider cloud come Microsoft Azure e AWS, prima di firmare va chiesto in quale regione vengono creati e replicati i dati. Va verificato se la scelta della regione è garantita dal contratto o resta una configurazione modificabile dal fornitore.

Modelli di servizio: pubblico, privato, ibrido, housing e colocation

Il cloud pubblico è gestito da un provider esterno. Mette a disposizione risorse condivise tra più clienti.

Le aziende usano l'infrastruttura come servizio, o IaaS, per ospitare applicazioni, eseguire carichi di lavoro e gestire dati senza investire in infrastrutture fisiche.

In questo modello un cloud server è un server virtuale, o un insieme di server, che opera in un ambiente di cloud computing. Rende disponibili risorse di calcolo, memoria e storage accessibili da remoto tramite rete.

A differenza di un server fisico installato e gestito internamente, è ospitato presso data center di terze parti ed erogato come servizio. I costi sono commisurati all'utilizzo effettivo.

Un'impresa può così memorizzare dati e accedere alle proprie applicazioni senza dover conservare tutto su server locali.

Il cloud privato è un'infrastruttura dedicata a una singola organizzazione. È ospitata presso il fornitore o presso l'impresa stessa.

Il cloud ibrido combina i due approcci e consente di tenere su ambienti dedicati o on-premise i carichi più sensibili o quelli con requisiti di latenza stringenti. Permette di usare il pubblico per le parti che devono crescere o ridursi rapidamente, come picchi di traffico, ambienti di test o elaborazioni temporanee.

Housing e colocation rappresentano l'altra grande famiglia di opzioni. In queste formule il cliente mantiene la proprietà del proprio hardware.

Nell'housing il server di proprietà dell'impresa viene ospitato in un data center di terzi. Nella colocation il fornitore mette a disposizione spazio, alimentazione, raffrescamento e connettività. Il cliente installa e gestisce le proprie macchine.

Sul mercato italiano housing e colocation sono offerte presenti. Sono affiancate ai data center dei grandi provider nati per erogare servizi pay per use.

Chi sceglie il cloud pubblico si orienta verso piattaforme come Microsoft Azure e AWS. Chi mantiene hardware proprio guarda invece a housing e colocation, presenti nell'offerta italiana.

Queste formule interessano le imprese che hanno hardware già ammortizzato, requisiti di controllo particolare o vincoli che rendono preferibile non cedere la gestione dello stack. Il criterio pratico per orientarsi è quanta parte dello stack si vuole gestire internamente. Più si sale verso housing e colocation, maggiore è il controllo su configurazione, prestazioni e sicurezza. Aumenta però l'onere di manutenzione, aggiornamenti e gestione degli incidenti.

Più si scende verso il cloud pubblico, minore è il carico operativo. Si dipende però dalle scelte del fornitore su architetture, tempi di aggiornamento e costi di uscita.

Il modello di costo segue la stessa logica. Il cloud tende a essere pay per use. Housing e colocation comportano canoni più stabili e legati allo spazio e all'energia occupati.

Accanto ai data center dei grandi provider nati per erogare servizi pay per use, l'offerta italiana colloca spazi per imprese sul territorio. La scelta tra i modelli resta legata al controllo che l'impresa vuole mantenere.

Colocation e housing sono soluzioni per continuità operativa, sicurezza dei dati e alte performance. Permettono di ospitare server fisici in data center altamente sicuri ed efficienti. Sempre più professionisti IT, startup, agenzie digitali e PMI scelgono data center in Italia per affidabilità, scalabilità e sicurezza.

Per housing e colocation la scelta riguarda data center in Italia. IBM pubblica documentazione dedicata agli SLA; per il cloud pubblico i nomi di riferimento restano Microsoft Azure e AWS.

SLA: definizione, tipologie e clausole essenziali

Un accordo sul livello di servizio, o SLA, è un contratto tra un fornitore di servizi e un cliente. Definisce il servizio da fornire e il livello di prestazioni previsto.

Uno SLA descrive anche come le prestazioni verranno misurate e approvate. Indica cosa succede se i livelli di prestazioni non vengono soddisfatti.

È uno strumento tipico dei contratti di outsourcing e dei fornitori di tecnologia dell'informazione. Fornisce una visione end-to-end del rapporto di lavoro, definisce le aspettative del cliente, responsabilizza il fornitore e aiuta a risolvere in anticipo incertezze e punti di contesa.

Non tutti gli SLA sono stipulati con soggetti esterni. Le aziende li usano anche internamente, per formalizzare accordi tra dipartimenti o team. Un esempio è un accordo tra team di sviluppo e team aziendali che delinea la cadenza di implementazione di un'applicazione o di un prodotto.

Un esempio di SLA a livello cliente riguarda un fornitore di servizi cloud di terze parti e un'azienda tecnologica. Delinea le aspettative di prestazioni delle applicazioni ospitate nel cloud.

Le tipologie più comuni sono tre. Lo SLA a livello di cliente copre tutti i servizi utilizzati da quel cliente. Contiene i dettagli specifici dei servizi, le disposizioni sulla disponibilità, la definizione delle responsabilità, le procedure di escalation e i termini per la cancellazione.

Lo SLA a livello di servizio descrive un singolo servizio offerto con le stesse condizioni a più clienti. È la forma usata quando il fornitore eroga lo stesso livello di servizio e assistenza indipendentemente dal cliente. I team di gestione dei servizi IT possono adottare un unico SLA per tutti i clienti.

Lo SLA multilivello integra in un unico sistema più livelli di condizioni. È adatto ai fornitori che servono clienti diversi a tariffe o con livelli di servizio differenti. AWS indica queste tre tipologie come le più comuni.

Alcuni elementi non dovrebbero mai mancare. Anzitutto la panoramica del contratto, con le date di inizio e fine e il perimetro del servizio.

Poi le metriche: quali parametri vengono misurati, con quale metodo, su quale finestra temporale e da chi. AWS cita tra i parametri tipici i tempi di attività, di consegna, di risposta e di risoluzione.

Servono anche la definizione delle responsabilità delle parti e le procedure di escalation, con i canali e i referenti da attivare. Vanno indicate le azioni previste in caso di mancato rispetto degli impegni.

Un punto spesso trascurato è il regime delle esclusioni: manutenzioni programmate, interventi di emergenza sulla sicurezza, eventi fuori dal controllo del fornitore. Vanno letti con attenzione perché possono svuotare di significato una percentuale di disponibilità dichiarata in copertina.

Lo SLA standard offerto da un grande provider è un documento pensato per una pluralità di clienti. È il punto di partenza della trattativa, non necessariamente l'assetto definitivo, soprattutto quando i carichi di lavoro hanno carattere critico.

AWS pubblica sul proprio sito le tipologie e gli elementi comuni dei contratti sul livello di servizio applicati ai propri servizi. È un riferimento utile per confrontare lo SLA standard di un provider con quello che l'impresa deve chiedere.

Un SLA non è solo un documento legale. Definisce standard precisi di servizio, dalle percentuali di uptime ai protocolli di sicurezza. Per hosting e cloud, questi standard vanno chiesti per iscritto.

IBM definisce lo SLA come contratto tra fornitore di servizi e cliente. Descrive come le prestazioni vengono misurate e approvate e cosa accade se i livelli non sono soddisfatti. AWS indica tre tipologie comuni: a livello di cliente, a livello di servizio e multilivello.

Nello SLA a livello di servizio, più clienti che usano lo stesso servizio clienti virtuale ricevono lo stesso contratto. AWS offre contratti sul livello di servizio per i propri servizi; IBM ha pubblicato il 30 maggio 2024 una definizione di SLA come contratto tra fornitore e cliente.

Metriche e penali: disponibilità, latenza, sicurezza e crediti di servizio

Le metriche di uno SLA per hosting e cloud si concentrano su alcune famiglie ricorrenti. La disponibilità è la più nota.

Viene espressa in percentuale su un periodo, di norma mensile. Indica quanto spesso il servizio è risultato accessibile e operativo.

AWS richiama tra i parametri anche i tempi di attività, di consegna, di risposta e di risoluzione. Sono il tempo tra la segnalazione di un problema e le diverse fasi della sua gestione. Accanto a queste vanno considerate la latenza, la capacità di elaborazione garantita, la frequenza e la tempistica dei backup, la finestra di ripristino in caso di incidente.

Per capire come si traducono questi principi in soglie concrete è utile guardare a un modello pubblicato per gli SLA di rete aziendale. Propone disponibilità minima dal 99,9% al 99,95%, misurata dal punto di vista dell'autenticazione dell'utente finale e non del semplice ping dell'hardware. Resta un esempio di connettività, non un valore degli SLA di Azure o AWS.

Indica latenza di autenticazione inferiore al secondo per gli accessi 802.1X e OpenRoaming. Prevede crittografia TLS 1.2 o superiore per i dati in transito e AES-256 per i dati a riposo.

Fissa finestre di patch da 24 a 48 ore per le vulnerabilità di sicurezza critiche. Prevede crediti di servizio a livelli, dal 10% al 50% della fattura mensile, collegati a tempi di inattività o violazioni verificate.

Sono esempi riferiti a contesti di connettività, ma il criterio metodologico vale anche per hosting e cloud. La disponibilità va misurata dal punto di vista del processo o dell'utente che deve lavorare, non solo dalla presenza di tensione nel rack.

Trasferite a hosting e cloud, le stesse grandezze vanno chieste per iscritto: disponibilità misurata sull'utente finale, latenza, standard di crittografia, finestre di patch e crediti di servizio. Sono le voci su cui si costruisce il confronto tra fornitori.

Sul fronte delle penali, il credito di servizio è un meccanismo previsto in modelli di SLA per la rete aziendale. Consiste in un credito sull'importo fatturato, collegato a tempi di inattività o violazioni verificate.

AWS cita espressamente, tra le azioni da intraprendere quando i requisiti non sono soddisfatti, il supporto aggiuntivo o gli sconti sui prezzi. È importante verificare come si attiva il credito: se è automatico o va richiesto, entro quali termini, con quali prove. Va controllato se esistono soglie minime di interruzione al di sotto delle quali non scatta nulla.

Un'ultima distinzione utile è quella tra SLA e KPI. Un KPI è un indicatore che si monitora per capire l'andamento del servizio. Lo SLA è un impegno contrattuale con conseguenze definite in caso di violazione.

Un fornitore può esporre una dashboard ricca di KPI senza che questo si traduca automaticamente in obblighi e penali. Prima di firmare conviene quindi chiedere esplicitamente quali indicatori siano coperti da impegno contrattuale e quali siano invece solo informativi.

Criteri di scelta del provider: scalabilità, costi, sicurezza, supporto e ubicazione

La scalabilità è il primo criterio da valutare. Per le organizzazioni, spostare i carichi di lavoro nel cloud può portare a una maggiore scalabilità e a un risparmio sui costi dell'infrastruttura IT. Il risultato dipende però dal fornitore.

In concreto va verificato quanto rapidamente si possono aggiungere o togliere risorse. Vanno controllati gli eventuali limiti contrattuali alla crescita e la copertura delle tecnologie che l'impresa intende usare nei prossimi anni.

Il secondo criterio è il costo complessivo, non il prezzo di listino. Oltre al canone o al consumo base, vanno considerati il traffico in uscita, lo spazio di backup e la sua replicazione, le licenze, il supporto a livelli superiori e gli interventi professionali.

Il modello pay per use tipico del cloud premia la flessibilità ma richiede controllo costante, perché la spesa segue l'utilizzo. Housing e colocation offrono maggiore prevedibilità, ma con costi fissi legati allo spazio e all'energia. Un confronto onesto mette a fianco queste voci su un orizzonte di più anni.

Il terzo criterio è la sicurezza: crittografia dei dati in transito e a riposo, gestione degli accessi e dei privilegi, segregazione tra ambienti, log delle attività, procedure di gestione delle vulnerabilità e tempi di applicazione delle patch. A questo si collega la conformità: se il fornitore non è in grado di documentare dove risiedono i dati e quali misure adotta, l'impresa si assume un rischio che non può trasferire.

Il quarto criterio è il supporto: canali disponibili, orari di copertura, lingua, presenza di referenti tecnici identificati, tempi di risposta garantiti e procedure di escalation. Un fornitore economico ma irraggiungibile nei momenti critici ha un costo reale molto più alto di quanto appaia in fattura.

Il quinto criterio è l'ubicazione: dove si trovano i data center che ospitano dati, repliche e backup, e in quali Paesi. La territorialità è diventata centrale per le imprese, e molti provider hanno investito in strutture sul territorio italiano.

Per il cloud pubblico i nomi di riferimento sono Microsoft Azure e AWS. Azure è il cloud di Microsoft e indica l'impegno a strumenti flessibili e scalabili per innovare in modo sicuro anche in prospettiva futura.

AWS è il cloud di Amazon e pubblica le tipologie e gli elementi comuni dei contratti sul livello di servizio applicati ai propri servizi. IBM pubblica documentazione dedicata agli SLA. Amazon, Google e Microsoft hanno infrastrutture proprie a supporto del cloud.

Confrontando i nomi citati, Azure insiste su strumenti flessibili e scalabili per innovare in modo sicuro. AWS pubblica tipologie ed elementi comuni degli SLA applicati ai propri servizi. IBM pubblica documentazione dedicata agli SLA e alle tre tipologie più comuni.

Su Azure, AWS e IBM il confronto va fatto su ciò che è documentato. Azure insiste su strumenti flessibili e scalabili per innovare in modo sicuro; AWS pubblica tipologie, elementi comuni e parametri degli SLA applicati ai propri servizi; IBM pubblica documentazione sugli SLA e sulle tre tipologie più comuni. Percentuali di uptime e importi delle penali vanno chiesti per iscritto, perché non sono uniformi.

Per housing e colocation la scelta riguarda data center in Italia. Connettività, alimentazione ridondata, raffreddamento e sicurezza fisica sono elementi da verificare. Sempre più professionisti IT, startup, agenzie digitali e PMI scelgono data center in Italia per affidabilità, scalabilità e sicurezza.

A chiusura del quadro va valutata la portabilità: formati dei dati, possibilità di esportarli, uso di tecnologie standard, tempi e costi di uscita dal contratto. Per i fornitori considerati vanno chieste per iscritto ubicazione, metriche, penali e costi di uscita. Un fornitore trasparente su questi punti è generalmente un fornitore più affidabile anche sul resto.

La sicurezza cloud include procedure di crittografia e protezione delle informazioni costantemente aggiornate. Questo aspetto va verificato insieme a gestione accessi, segregazione e log.

Checklist per l'impresa: domande da fare e punti da verificare prima di firmare

Sui dati e la loro ubicazione: in quali Paesi e in quali strutture risiedono i dati di produzione, le repliche e i backup? Sono previsti trasferimenti verso altre regioni e in quali circostanze?

Il fornitore è in grado di documentare per iscritto la localizzazione e le misure di sicurezza adottate? Quali soggetti, anche appartenenti a ordinamenti esteri, possono accedere ai dati e a quali condizioni?

Se il fornitore è un grande provider cloud come Microsoft Azure o AWS, va chiesto in quale regione vengono creati e replicati i dati. Va verificato se la scelta della regione è garantita dal contratto o resta una configurazione modificabile dal fornitore. Per housing e colocation va chiesto quali strutture sul territorio italiano ospitano le macchine.

Sul livello di servizio: qual è la disponibilità garantita e su quale finestra temporale viene misurata? Come viene calcolata e chi produce i dati di misurazione? L'impresa ha accesso diretto ai dati e ai log di monitoraggio?

Quali eventi sono esclusi dal calcolo della disponibilità? Quali crediti di servizio sono previsti, in quale misura e a quali condizioni si attivano? Il riconoscimento è automatico o deve essere richiesto, entro quali termini e con quali prove?

Quali sono i tempi di risposta e di chiusura garantiti e come si distinguono per gravità dell'incidente? Chi si contatta, con quali canali, in orario e fuori orario? Esiste una procedura di escalation con referenti nominativi?

Su sicurezza e gestione operativa: quali standard di crittografia sono applicati ai dati in transito e a riposo? Con quale tempistica vengono applicate le patch alle vulnerabilità critiche e come vengono comunicate all'impresa?

Come sono gestiti accessi, privilegi e tracciamento delle attività? Come vengono eseguiti e verificati i ripristini da backup, non solo i backup stessi?

Su costi e vincoli contrattuali: qual è il costo complessivo considerando traffico, backup, licenze e supporto? Esistono penali o costi aggiuntivi legati all'aumento dell'utilizzo o al superamento di soglie?

Quali sono la durata del contratto, i termini di preavviso e le condizioni di rinnovo? Cosa accade alla fine del rapporto: in quali formati e in quali tempi vengono restituiti i dati, con quali costi di uscita?

Alcune clausole indicano da sole se il contratto è negoziabile. Uno SLA a livello di cliente copre i dettagli specifici dei servizi, le disposizioni sulla disponibilità, la definizione delle responsabilità, le procedure di escalation e i termini per la cancellazione. La panoramica del contratto, con le date di inizio e fine, rientra tra gli elementi comuni di uno SLA. Se il contratto non riporta questi elementi, va chiesto di integrarli.

Una volta raccolte le risposte, la verifica più utile è la coerenza. Se il fornitore garantisce una certa disponibilità ma non indica come la misura, il rischio resta. Se promette trasparenza sulla localizzazione ma non la mette per iscritto, il rischio resta.

Se le penali esistono solo sulla carta, il rischio contrattuale resta in capo all'impresa. Le domande di questa checklist servono anche a questo: distinguere ciò che è documentato da ciò che è soltanto dichiarato.

Per gli SLA, chiedere il contratto sul livello di servizio applicato ai servizi utilizzati. Un contratto sul livello di servizio deve includere le date di inizio e fine, i dettagli specifici dei servizi, le disposizioni sulla disponibilità, le responsabilità, le procedure di escalation e i termini per la cancellazione. Chiedere che questi elementi siano presenti per iscritto.

Per lo SLA, chiedere anche la tipologia: a livello di cliente, a livello di servizio o multilivello. AWS indica queste tre tipologie come le più comuni; IBM definisce lo SLA come contratto che descrive misurazione, approvazione e conseguenze. La scelta dipende da quanti servizi e quanti clienti coinvolge il contratto.

Per le metriche, AWS cita i tempi di attività, di consegna, di risposta e di risoluzione. Chiedere quali sono coperti da SLA e quali restano indicatori informativi.