Il disservizio di Google Cloud dimostra che la resilienza è una scelta aziendale

Un disservizio del cloud non è più soltanto una brutta mattinata per un ingegnere. Quando un guasto presso un provider interrompe servizi bancari, videoconferenze giudiziarie e servizi pubblici, diventa un test di quanto un’intera società abbia concentrato silenziosamente la propria infrastruttura digitale in un unico punto.

Il 20 ottobre, Google Cloud ha subito un disservizio nella regione europe-west2, con la zona europe-west2-b particolarmente colpita. Reuters riferisce che gli utenti hanno segnalato problemi con Lloyds, HSBC e Rightmove, mentre altre notizie hanno indicato Revolut, ING Germany e Halifax tra i servizi interessati. La pagina dedicata agli incidenti di Google ha comunicato che i servizi non erano disponibili nella zona colpita e che alcuni servizi in tutta la regione potevano registrare un aumento degli errori. Il disservizio si è poi attenuato, ma la domanda importante non è se Google abbia alla fine ripristinato il servizio. È perché così tante aziende siano state esposte allo stesso guasto.

“Il cloud” non è una strategia se tutti usano lo stesso provider

Il cloud computing viene spesso venduto come una via d’uscita dalle fragili infrastrutture interne. La promessa è reale: un grande provider può offrire distribuzione geografica, ripristino automatico e competenze operative che molte aziende non potrebbero ricreare in modo economicamente sostenibile. Le stesse indicazioni di Google per il disaster recovery si basano esplicitamente sulla progettazione di carichi di lavoro capaci di resistere ai guasti dell’infrastruttura cloud.

Ma la resilienza non coincide con la disponibilità. Un cliente può operare in una moderna regione cloud e dipendere comunque da un solo provider, una sola regione, una sola zona o un piccolo insieme di servizi condivisi. Il risultato è un sistema che appare distribuito in un diagramma architetturale, pur rimanendo concentrato nella pratica.

Questa è la lezione centrale dell’incidente. Il guasto non doveva mandare fuori uso tutti i servizi Google Cloud nel mondo per provocare un’interruzione diffusa. Doveva soltanto raggiungere un numero sufficiente di clienti le cui applicazioni, i flussi di pagamento o i sistemi rivolti al pubblico erano legati alla stessa infrastruttura regionale. Una piattaforma cloud può essere enorme e creare comunque un punto di guasto circoscritto per le aziende che vi hanno costruito i propri sistemi.

Ecco perché l’espressione “passare al cloud” è diventata troppo generica per essere utile. La domanda rilevante non è se un’azienda utilizzi un’infrastruttura cloud. È quanti percorsi indipendenti rimangano quando quell’infrastruttura diventa indisponibile.

La ridondanza costa, e fingere il contrario è peggio

La parte scomoda è che la soluzione non consiste semplicemente nell’aggiungere un’altra spunta in uno strumento di distribuzione. Una vera resilienza può richiedere un secondo provider cloud, dati duplicati, sistemi di identità indipendenti, canali di pagamento alternativi, procedure di failover collaudate e team capaci di operare in condizioni degradate. Tutto questo costa e aggiunge complessità.

Può anche rendere i sistemi più difficili da gestire. Un’architettura multi-cloud può ridurre la dipendenza da un singolo fornitore, ma introdurre servizi incompatibili, monitoraggio più complesso e ulteriore lavoro sul fronte della sicurezza. Replicare un database tra provider non è automaticamente più sicuro se il processo di replica, le credenziali o il piano di ripristino continuano a condividere una dipendenza comune.

La risposta giusta, quindi, non è chiedere d’istinto a ogni azienda di abbandonare Google Cloud. Sarebbe semplicistico quanto presumere che un singolo provider sia sempre sufficiente. La domanda sensata riguarda la proporzionalità: cosa succede se questo servizio non è disponibile per ore, e qual è il costo finanziario o pubblico di quell’interruzione?

Per uno strumento interno a basso rischio, accettare una certa concentrazione può essere perfettamente razionale. Per l’accesso ai servizi bancari o per un servizio pubblico, la risposta dovrebbe essere diversa. A dover decidere se il risparmio e la comodità giustifichino l’esposizione è il cliente, non soltanto il provider cloud.

Un guasto regionale può diventare un problema per le infrastrutture pubbliche

Il disservizio bancario rende il problema particolarmente evidente perché i clienti non vivono l’architettura cloud come una scelta tecnica astratta. La vivono come una carta che non funziona, un conto a cui non riescono ad accedere o un servizio che smette di rispondere. La BBC ha riferito che il disservizio ha colpito tribunali, banche e altre attività online, una combinazione che trasforma un incidente del fornitore in una questione di resilienza istituzionale.

Questo non significa che Google sia l’unico responsabile di ogni guasto a valle. Le aziende scelgono come progettare i propri sistemi e la documentazione disponibile non dimostra che tutte le banche europee si affidassero alla stessa architettura. La conclusione più difendibile è più circoscritta, ma anche più seria: un disservizio regionale di Google Cloud è stato in grado di colpire diversi servizi essenziali perché molte organizzazioni avevano accettato una dipendenza comune.

C’è anche un avvertimento a non trattare i dati storici sulla disponibilità come sostituti dei piani di ripristino. Google Cloud ha subito altri incidenti, tra cui un disservizio di Cloud Storage nella regione us-central1 l’8 ottobre 2026, quando caricamenti e scritture hanno registrato latenza ed errori elevati per 12 ore e 30 minuti. La ricostruzione di IncidentHub riporta che la spiegazione preliminare di Google riguardava l’esaurimento delle risorse dopo un’ottimizzazione per l’ordinamento del traffico, insieme a un problema distinto al database. Regioni e cause differenti non dimostrano che ogni carico di lavoro sia esposto allo stesso modo, ma indeboliscono l’idea rassicurante che una piattaforma importante possa essere trattata come un servizio invisibile.

I clienti dovrebbero pagare per l’indipendenza quando un guasto conta

La grande comodità del settore cloud è anche la sua vulnerabilità politica ed economica: permette a migliaia di organizzazioni di esternalizzare decisioni infrastrutturali difficili a pochi provider. È efficiente finché la decisione esternalizzata non si trasforma in una modalità di guasto comune.

La nostra opinione è che autorità di regolamentazione e consigli di amministrazione dovrebbero smettere di chiedersi soltanto se un provider vanti dati impressionanti sulla disponibilità. Dovrebbero domandarsi se un servizio critico possa funzionare quando la sua regione principale, il provider o il piano di controllo condiviso non sono disponibili. La risposta deve essere documentata, verificata e finanziata, non lasciata a una slide sul disaster recovery.

Google Cloud resta una piattaforma potente e questo disservizio non la rende insolitamente irresponsabile. Dimostra però che la resilienza ha un prezzo e che quel prezzo non può essere cancellato chiamando l’infrastruttura “cloud”. Per i carichi di lavoro non critici, la concentrazione può ancora essere la scelta più conveniente. Per banche e servizi pubblici, invece, l’indipendenza non è una duplicazione dispendiosa. Fa parte del servizio stesso.