Come scegliere un provider cloud: i criteri che contano davvero

Scegliere dove ospitare un sito, un’applicazione o un intero sistema aziendale è una di quelle decisioni che sembrano solo tecniche e invece pesano sul portafoglio per anni. Il mercato del cloud offre decine di fornitori, ognuno con la sua tabella dei prezzi, e il rischio è confrontarli guardando la voce sbagliata. Questa guida mette in fila i criteri che contano davvero, senza spingere un provider in particolare: l’obiettivo è aiutare a ragionare, non vendere.

Con “cloud provider” si intende un’azienda che affitta risorse informatiche via Internet: potenza di calcolo, spazio di archiviazione, rete. Invece di comprare un server e tenerlo in ufficio, si paga un canone per usarne uno (o mille) da remoto. Fin qui è semplice. La complessità arriva quando si prova a capire quanto costa davvero.

Il modello di prezzo: hyperscaler contro VPS

Semplificando, i fornitori si dividono in due grandi famiglie. Da una parte gli hyperscaler - i colossi globali come Amazon Web Services (AWS), Microsoft Azure e Google Cloud - che vendono un catalogo di centinaia di servizi separati, dalle istanze di calcolo tradizionali fino ai nuovi chip ARM pensati per abbattere i costi. Dall’altra i provider di VPS (Virtual Private Server, cioè “server privati virtuali”): una macchina virtuale a canone fisso, con un prezzo quasi tutto compreso.

La differenza non è solo di scala, è di filosofia. L’hyperscaler non ti vende “una macchina”: ti vende l’istanza di calcolo, e poi - a voci separate - l’indirizzo IP pubblico, lo spazio disco, le copie di sicurezza, il bilanciatore di carico, il traffico di rete e il piano di supporto. Il prezzo dell’istanza è la punta dell’iceberg. Un VPS parte invece dall’idea opposta: un canone che include già disco, traffico e indirizzo IP. È meno flessibile, ma molto più facile da preventivare.

Nessuno dei due modelli è “giusto” in assoluto. Il punto è che confrontarli solo sul prezzo orario dell’istanza è fuorviante, perché in quel prezzo i due casi comprendono cose diverse.

I costi nascosti: la banda in uscita

Se c’è una voce che fa saltare i preventivi, è la banda in uscita (in inglese egress): il traffico di dati che esce dal cloud verso Internet, cioè verso gli utenti. Ogni immagine, video, download o risposta di un’API che raggiunge un visitatore è traffico in uscita.

Sugli hyperscaler questo traffico si paga a consumo, al gigabyte. AWS, per esempio, include 100 GB al mese gratuiti aggregati su tutti i servizi, e poi fattura ogni gigabyte successivo. Sembra poco, ma un sito con molte immagini o un servizio che distribuisce file può muovere terabyte al mese: a quel punto la banda diventa una delle voci più pesanti della fattura, a volte più dell’istanza stessa.

I provider di VPS di solito ribaltano la logica: includono nel canone una quota di traffico molto generosa e fanno pagare pochissimo l’eventuale eccedenza. La conseguenza pratica è semplice: se l’applicazione muove molti dati verso l’esterno, il modello a consumo può costare ordini di grandezza in più. Se invece consuma soprattutto CPU e database con poco traffico, la differenza si assottiglia. La regola è stimare la banda in uscita prima di scegliere, non dopo la prima bolletta.

Servizi gestiti o self-managed?

Qui il confronto si ribalta. Un servizio gestito (managed) è una risorsa che il provider mantiene per conto tuo: un database gestito, per esempio, viene aggiornato, salvato e replicato in automatico, con sostituzione del nodo in caso di guasto. L’alternativa è il self-managed: il provider ti dà la macchina “nuda” e database, aggiornamenti, backup e monitoraggio li configuri e li tieni in piedi tu.

Gli hyperscaler eccellono nei servizi gestiti, dal database completamente amministrato alle GPU serverless per l’inferenza AI: hanno cataloghi enormi che tolgono lavoro operativo. I VPS offrono soprattutto materia prima, ottima e a buon prezzo, ma da amministrare. La domanda giusta non è “chi ne ha di più”, ma “quanto vale il mio tempo”. Un database gestito costa più di uno installato a mano, però quel sovrapprezzo è il lavoro (e la reperibilità notturna) che non devi fare tu. Se in casa ci sono le competenze per gestire l’infrastruttura, il self-managed fa risparmiare; se non ci sono, il servizio gestito spesso costa meno del personale che servirebbe. Il self-managed non è gratis: è un costo che si sposta dalla fattura del cloud alle ore di chi amministra.

Un provider ha data center - i capannoni pieni di server - in zone geografiche chiamate region. La scelta della region conta per due motivi. Il primo è la latenza: più il server è vicino agli utenti, più le risposte arrivano in fretta. Il secondo, spesso più importante, è legale.

Il GDPR, il regolamento europeo sulla protezione dei dati, pone regole precise su dove possono finire i dati personali. Il suo Capo V (articoli 44 e seguenti) stabilisce che il trasferimento di dati personali fuori dall’Unione Europea è vietato salvo condizioni specifiche. Tradotto: se tratti dati di cittadini europei, il luogo fisico in cui risiedono quei dati non è un dettaglio.

C’è però una sottigliezza che sfugge a molti. Scegliere una region europea non basta a mettere i dati al riparo da ogni richiesta esterna. Per via del CLOUD Act statunitense, la giurisdizione americana segue l’azienda, non il server: un fornitore soggetto al diritto USA può essere obbligato a consegnare i dati che controlla anche se sono archiviati in un data center europeo. Non significa che gli hyperscaler americani siano “fuori legge” - hanno costruito offerte apposite per rispondere al tema - ma che la sovranità dei dati va valutata sul prodotto e sull’entità legale che lo gestisce, non sulla bandiera nel logo.

Il rischio di lock-in

Lock-in significa dipendenza tecnica: quanto è costoso e complicato cambiare fornitore una volta entrati. Su un VPS è basso, perché di solito è una macchina Linux standard che si migra altrove in un pomeriggio. Su un hyperscaler può essere alto, perché i servizi proprietari - database su misura, funzioni serverless, code di messaggi - non esistono uguali altrove, e riscriverli costa.

C’è anche una forma più subdola di lock-in: la gravità dei dati. Più dati accumuli in un servizio, più costa portarli via, perché l’uscita di quei terabyte passa proprio dalla banda in uscita a pagamento. Il costo dell’egress diventa così anche un pedaggio che scoraggia la migrazione. La difesa è progettuale: preferire, dove possibile, componenti standard e aperti, descrivere l’infrastruttura con strumenti di Infrastructure as Code invece che a mano, e sapere fin dall’inizio quanto costerebbe traslocare. Il lock-in non è un difetto morale, è una scelta da fare con gli occhi aperti.

Il supporto

Ultimo criterio, spesso sottovalutato: cosa succede quando qualcosa si rompe alle tre di notte. I livelli di supporto variano moltissimo. Alcuni provider includono un’assistenza di base nel canone; gli hyperscaler vendono i piani di supporto a parte, spesso come percentuale della spesa mensile. Vale la pena leggere lo SLA (Service Level Agreement, l’accordo sul livello di servizio): promette una certa disponibilità e certi tempi di risposta, ma spesso il “rimborso” per un disservizio è solo un credito sulla fattura, non un risarcimento del danno reale. Il supporto non si valuta dal numero verde in homepage, ma da cosa c’è scritto nel contratto.

In sintesi

Non esiste “il cloud migliore”: esiste il modello giusto per un carico specifico. Conviene procedere per ordine. Prima stimare la banda in uscita, che è la variabile che più spesso ribalta i conti. Poi decidere quanto lavoro operativo delegare, scegliendo tra servizi gestiti e self-managed in base alle competenze disponibili. Quindi verificare dove devono stare i dati e chi può essere obbligato a consegnarli. Infine mettere in conto il rischio di lock-in e leggere per davvero le condizioni di supporto. Il prezzo orario dell’istanza, quello che tutti confrontano per primo, è quasi sempre la voce meno importante.

# Come scegliere un provider cloud: i criteri che contano davvero