AWS, Azure o Google Cloud: quale scegliere

Devi scegliere un provider cloud e ogni articolo che apri sembra scritto dall'ufficio marketing di uno dei tre. Nel frattempo la decisione resta ferma, perché sembra irreversibile e costosa da sbagliare. In questo articolo trovi un confronto onesto tra AWS, Azure e Google Cloud, dove ciascuno è effettivamente più forte, e perché nella maggior parte dei casi stai dando peso ai fattori sbagliati.

La differenza di fondo

Per il 90% dei progetti i tre provider sono funzionalmente equivalenti, e la scelta giusta dipende quasi sempre da fattori che non sono tecnici.

Ti serve una macchina virtuale, spazio per i file, un database gestito, un modo per eseguire codice a evento, una rete di distribuzione, un sistema di permessi. Tutti e tre ce l'hanno, tutti e tre lo fanno bene, con prezzi abbastanza simili da non spostare la decisione. I nomi cambiano, i concetti no.

Il confronto tecnico diventa decisivo solo se hai un requisito specifico e insolito. Se non ce l'hai — e la maggior parte dei progetti non ce l'ha — stai scegliendo tra tre buone opzioni, e il criterio deve essere un altro.

I fattori che decidono davvero

In ordine di importanza reale, non di quanto se ne parla.

Cosa sa già il tuo team

Un provider che qualcuno conosce vale più di un provider tecnicamente superiore che nessuno ha mai toccato. La curva di apprendimento del cloud non è sulle singole funzioni: è su permessi, reti, fatturazione e su come si diagnostica un problema alle tre di notte. Quella conoscenza non si trasferisce leggendo la documentazione in un pomeriggio. Se qualcuno nel team ha già gestito produzione su uno dei tre, la discussione è finita.

Cosa usa già l'azienda

Se l'organizzazione vive dentro Microsoft 365, con Active Directory, Teams e licenze Windows Server, Azure parte con un vantaggio strutturale: identità già presenti, licenze riutilizzabili, contratti già firmati. Non è burocrazia, è metà del lavoro di integrazione già fatto. E vale al contrario: se non c'è nulla di Microsoft, quel vantaggio non esiste.

I crediti startup

Tutti e tre offrono crediti significativi per startup e progetti iniziali, spesso tramite acceleratori o programmi partner. Un pacchetto che copre un paio d'anni di infrastruttura è molto più concreto di una differenza del 5% su un benchmark. Chiedili prima di scegliere, non dopo.

Il mercato del lavoro

Se stai imparando per lavorare, AWS ha il numero maggiore di annunci e Azure lo segue da vicino, specialmente in Italia dove il tessuto enterprise è molto microsoftizzato. Se devi assumere, il ragionamento è lo stesso all'inverso.

Dove stanno i dati

Con vincoli di conformità o di residenza dei dati, verifica quali regioni sono disponibili dove ti serve e quali certificazioni ha il provider. È un criterio raro ma, quando c'è, batte tutti gli altri — vedi GDPR per sviluppatori.

Dove ciascuno è effettivamente più forte

Detto che si equivalgono nella media, le differenze reali esistono ai margini. Queste sono quelle che ho visto contare davvero.

AWS: ampiezza e maturità

È il più vasto e il più anziano, e questo dà due vantaggi pratici. Il primo: qualsiasi cosa ti serva, per quanto di nicchia, esiste già come servizio gestito. Il secondo pesa di più: qualunque problema tu abbia, qualcun altro l'ha già avuto e ha scritto la risposta. Discussioni, guide, moduli Terraform, librerie. Quando sei bloccato vale moltissimo.

Il rovescio è la complessità: console disordinata, nomi opachi, permessi con una curva di apprendimento vera. Per un principiante può essere scoraggiante — ne parlo in cos'è AWS.

Azure: ecosistema Microsoft ed enterprise

Se l'azienda è già Microsoft, Azure non è una scelta tra pari: è la scelta ovvia. Integrazione con l'identità aziendale, licenze riutilizzabili sul cloud, modello ibrido tra data center proprio e cloud, e la parte contrattuale gestita da chi già ti vende il resto.

È anche il più a suo agio con .NET e Windows Server, e ha il modello ibrido più curato dei tre: molte aziende non spostano tutto e tengono metà in casa, scenario per cui Azure è costruito.

Il punto debole storico è l'esperienza da sviluppatore: portale pesante, parti progettate più per amministratori di sistema che per chi scrive codice, qualità dei servizi meno uniforme che su AWS.

GCP: dati, Kubernetes, machine learning

È il più piccolo dei tre ma il più forte dove Google è forte. Il data warehouse e l'analisi su grandi volumi sono un riferimento del settore: se il problema è "ho tanti dati e devo interrogarli", GCP è la risposta che sento più spesso da chi ci lavora.

Su Kubernetes ha un vantaggio genealogico: nasce in Google, e il servizio gestito di GCP è considerato il più curato. Se la tua architettura è fatta di container da orchestrare con il minimo attrito, è un argomento serio.

C'è poi il machine learning, dove ha strumenti competitivi. E la console è la più pulita dei tre: sembra poco, ma sulle prime settimane si sente.

I punti deboli sono la quota di mercato più bassa — meno risposte pronte quando cerchi un problema specifico — e la reputazione, meritata o no, di dismettere prodotti con disinvoltura.

La tabella

	AWS	Azure	Google Cloud
Punto di forza	Ampiezza del catalogo e maturità	Integrazione Microsoft ed enterprise	Dati, Kubernetes, ML
Quota di mercato	La più alta	Seconda, in crescita	Terza
Documentazione e community	Enorme	Buona, molto enterprise	Buona ma più piccola
Curva di apprendimento	Alta	Media-alta	La più dolce
Esperienza console	Disordinata	Pesante	La più pulita
Modello ibrido	Presente	Il più curato	Presente
Mondo .NET / Windows	Supportato	Casa propria	Supportato
Data warehouse e analytics	Molto buono	Molto buono	Riferimento del settore
Kubernetes gestito	Buono	Buono	Il migliore
Prezzi	Comparabili, sconti a impegno	Comparabili, leva sulle licenze	Comparabili, sconti automatici all'uso
Sorpresa in fattura	Traffico in uscita	Traffico in uscita	Traffico in uscita

L'ultima riga non è un refuso: il traffico in uscita è la voce che sorprende su tutti e tre, e nessuno la mette in evidenza nei preventivi.

Sui prezzi, una cosa sola

Niente cifre qui, perché cambiano di continuo e un numero vecchio è peggio di nessun numero. Conta il metodo:

• I prezzi di listino si assomigliano. Sui servizi paragonabili si parla di pochi punti percentuali, che si spostano nel tempo.
• Gli sconti a impegno pluriennale sono la leva vera e tagliano la spesa in modo significativo se il carico è prevedibile. Ma ti legano.
• Il conto non lo fa il prezzo orario della macchina. Lo fanno traffico in uscita, database gestiti, bilanciatori, log e decine di servizi accessori.
• Confronta sulla tua architettura, non sui listini.

Vale quanto scrivo in quanto costa un sito web: la voce imprevedibile non è mai quella che guardi.

Il lock-in e come limitarlo

Il timore di restare bloccati è legittimo, ma va calibrato: il lock-in non è binario, è una scala, e tu decidi dove stare.

Poco vincolante: macchine virtuali, dischi, reti, container. Sono concetti standard, e spostarli è lavoro noioso ma lineare.

Molto vincolante: i servizi gestiti proprietari — code, orchestratori, database serverless specifici, funzioni con i loro innesti agli eventi. Sono anche quelli che ti fanno risparmiare più tempo. Questo è il compromesso vero: la produttività che compri oggi è esattamente la cosa che ti lega domani.

Come tenerlo sotto controllo senza rinunciare a tutto:

• Usa container. Un'applicazione in Docker gira ovunque, e da sola copre il pezzo più grosso della portabilità.
• Descrivi l'infrastruttura come codice con Terraform. Non rende automatica la migrazione, ma rende esplicito e ricostruibile tutto quello che hai: è la metà difficile del lavoro.
• Isola il codice specifico del provider dietro una tua interfaccia. Se cambi il servizio di archiviazione, tocchi un file, non trenta.
• Preferisci gli standard aperti a parità di costo: PostgreSQL invece di un database proprietario, l'API S3 per l'archiviazione, Kubernetes al posto di un orchestratore chiuso.
• Tieni i backup fuori dal provider, come in come fare backup del sito: è l'unica precauzione che vale anche contro l'account bloccato.

Ma non esagerare nell'altro senso. Un'astrazione che funziona su tutti e tre costa tempo, complica il codice e ti lascia il minimo comune denominatore. È ottimizzazione per un problema che spesso non arriva mai: un po' di lock-in consapevole è ragionevole.

Cosa fa perdere tempo e soldi

Passare settimane a scegliere. Il costo dell'indecisione supera quasi sempre quello di aver scelto il secondo migliore. Se dopo un'ora non emerge un vincitore chiaro è perché non c'è: prendi quello che il team conosce.

Scegliere in base a un benchmark. Misurano casi che non sono il tuo, su configurazioni che non userai, in un momento già passato.

Adottare il multi-cloud "per non legarsi". Due provider significano due sistemi di permessi, due modelli di rete, due fatture, due competenze da mantenere. Ha senso per requisiti reali di continuità, non come polizza preventiva.

Non attivare un budget con avviso. Vale su tutti e tre, e va fatto il primo giorno.

Sovradimensionare all'inizio. Cluster e ambienti multipli per un progetto con dieci utenti. Il cloud si ridimensiona: parti piccolo.

Confondere la scelta del cloud con quella dell'architettura. Molti progetti convinti di dover scegliere tra i tre non hanno bisogno di nessuno dei tre: la domanda vera è scegliere lo stack, e spesso la risposta è una piattaforma gestita o un VPS.

Il verdetto, caso per caso

Progetto personale o applicazione piccola: nessuno dei tre. Una piattaforma di deploy o un VPS costano meno in denaro e molto meno in tempo.

Startup che parte da zero: quello con i crediti migliori, a parità di competenze. Sul serio.

Azienda già Microsoft: Azure, senza discussione.

Prodotto centrato sui dati o sull'analisi: GCP, ed è il caso in cui la differenza tecnica pesa davvero.

Architettura Kubernetes-first: GCP per la qualità del gestito, AWS se il resto dell'infrastruttura è già lì.

Servizi di nicchia e molta orchestrazione: AWS, perché la copertura del catalogo è la sua ragione d'essere.

Vuoi imparare per lavorare: AWS come primo, Azure se punti all'enterprise italiano. I concetti si trasferiscono tra i tre.

In sintesi

Per la maggior parte dei progetti i tre si equivalgono, e cercare il vincitore tecnico è tempo speso male.

Decidono i fattori non tecnici: cosa sa il team, cosa usa già l'azienda, dove ci sono i crediti, chi trovi sul mercato.

Le differenze reali stanno ai margini: AWS sull'ampiezza e sulla quantità di risposte disponibili, Azure sull'ecosistema Microsoft e sull'enterprise, GCP su dati, Kubernetes e machine learning.

Il lock-in si limita, non si elimina, e conviene farlo con container, infrastruttura come codice, standard aperti e backup fuori dal provider — senza costruire astrazioni che ti fanno perdere il vantaggio dei servizi gestiti.

E la sorpresa in fattura è la stessa su tutti e tre: il traffico in uscita.

Se stai partendo adesso, il punto di ingresso è cos'è AWS spiegato ai principianti; per il quadro concettuale generale, cos'è il cloud computing.