Revolut down, Google Cloud manda in tilt pagamenti e prelievi: il rischio nascosto che riguarda tutti

Pagamenti rifiutati, trasferimenti non disponibili, difficoltà di accesso all’app e problemi con i prelievi. Il down di Revolut del 20 ottobre 2026 ha mostrato quanto anche una delle banche digitali più conosciute al mondo possa diventare vulnerabile quando si verifica un guasto presso un grande fornitore cloud.

All’origine del disservizio c’è stato infatti un problema nell’infrastruttura di Google Cloud, utilizzata da Revolut e da numerose altre aziende per gestire servizi e applicazioni digitali.

L’incidente non ha riguardato soltanto la fintech britannica. Anche altre banche e organizzazioni europee hanno segnalato malfunzionamenti, riportando al centro del dibattito un tema sempre più importante: la dipendenza delle imprese da pochi grandi fornitori tecnologici.

Revolut down oggi: cosa è successo

Il guasto è iniziato nella mattinata europea e ha interessato la regione londinese europe-west2 di Google Cloud.

Secondo il bollettino ufficiale, un evento elettrico nella zona europe-west2-b ha reso indisponibili numerosi servizi cloud. Gli effetti si sono propagati anche al resto della regione, causando errori e problemi di rete intermittenti.

L’incidente è durato complessivamente sette ore e 52 minuti e ha coinvolto decine di prodotti Google Cloud, tra cui servizi di elaborazione, database, archiviazione, rete e bilanciamento del traffico. Google Cloud Service Health

Durante il down, gli utenti Revolut hanno segnalato problemi con:

• pagamenti con carta;
• trasferimenti bancari;
• prelievi agli sportelli automatici;
• accesso all’app;
• cambio valuta;
• servizi per clienti Business;
• assistenza tramite chat;
• alcune operazioni su investimenti e criptovalute.

Revolut ha assicurato che il denaro e i dati personali dei clienti sono rimasti al sicuro. La società ha successivamente ripristinato i servizi interessati. Il guasto ha coinvolto anche banche come HSBC, Lloyds e Halifax. Associated Press

Perché il guasto di Google Cloud ha colpito Revolut

Il cloud consente alle aziende di utilizzare server, database e infrastrutture informatiche gestiti da fornitori specializzati. In questo modo è possibile espandere rapidamente i servizi, gestire milioni di utenti e ridurre la necessità di mantenere data center proprietari.

Ma essere “nel cloud” non significa essere automaticamente protetti da qualsiasi guasto.

Se un’applicazione critica dipende eccessivamente da una singola zona geografica, da una regione o da un componente condiviso, l’indisponibilità di quel componente può provocare un effetto domino.

Non è possibile ricostruire dall’esterno l’intera architettura tecnica di Revolut o stabilire quali sistemi di failover fossero operativi durante l’incidente. Il caso dimostra però che la continuità di un servizio non dipende soltanto dall’affidabilità del provider: dipende anche da come l’infrastruttura viene progettata e distribuita.

Cos’è la ridondanza cloud e perché è fondamentale

La ridondanza cloud consiste nel duplicare applicazioni, dati e componenti critici in ambienti indipendenti. Se una parte dell’infrastruttura smette di funzionare, una seconda risorsa può continuare a erogare il servizio.

Un singolo server di riserva, però, non basta. La ridondanza deve essere costruita su più livelli:

• più server per proteggersi dal guasto di una macchina;
• più zone per resistere al blocco di un data center;
• più regioni per affrontare incidenti geografici estesi;
• sistemi separati per database, autenticazione, rete e monitoraggio;
• backup isolati e verificati;
• procedure automatiche per spostare il traffico.

Un’infrastruttura può avere decine di server duplicati e restare comunque vulnerabile se tutti dipendono dalla stessa rete, dallo stesso database o dalla stessa zona cloud.

Multi-zona, multi-regione e multi-cloud: quali sono le differenze

Una strategia di ridondanza può essere realizzata in modi diversi.

Architettura multi-zona

L’applicazione viene distribuita tra più data center appartenenti alla stessa regione cloud. Se una zona smette di funzionare, le altre possono continuare a gestire il traffico.

Questa configurazione protegge dai guasti locali, ma potrebbe non essere sufficiente quando il problema coinvolge servizi condivisi o una parte più ampia della regione.

Architettura multi-regione

Applicazioni e dati vengono replicati in regioni geograficamente separate. In caso di down della regione principale, il traffico può essere trasferito verso quella secondaria.

Per i servizi finanziari critici, Google raccomanda una topologia distribuita su almeno due regioni e tre zone per ciascuna regione. Google Cloud Architecture Framework

Architettura multi-cloud

L’azienda utilizza contemporaneamente più fornitori, per esempio Google Cloud insieme ad Amazon Web Services o Microsoft Azure.

Questa soluzione riduce la dipendenza da un solo provider, ma introduce costi e complessità. Database, sicurezza, applicazioni e sistemi di monitoraggio devono funzionare in ambienti tecnologicamente differenti.

Il multi-cloud non è quindi una garanzia assoluta: un’architettura multi-cloud gestita male può essere meno affidabile di una solida infrastruttura multi-regione.

Active-active o active-passive?

Anche il meccanismo di failover può essere organizzato in due modi principali.

In una configurazione active-active, due o più regioni servono gli utenti contemporaneamente. Se una si blocca, le altre assorbono il traffico. Il ripristino può essere quasi immediato, ma la sincronizzazione dei dati è complessa.

In una configurazione active-passive, l’infrastruttura secondaria rimane pronta a subentrare solo in caso di emergenza. Costa meno, ma il passaggio può richiedere più tempo.

In entrambi i casi, il sistema alternativo deve disporre della capacità necessaria per gestire l’aumento improvviso del traffico. Una regione di emergenza sottodimensionata rischia di crollare proprio durante il failover.

Perché avere un backup non basta

Backup e ridondanza non sono la stessa cosa.

Il backup permette di recuperare i dati dopo un incidente. La ridondanza consente invece di mantenere operativo il servizio, o di ripristinarlo in tempi molto brevi.

Un’azienda può avere copie perfette dei propri database e restare comunque offline per ore se non dispone di server alternativi, procedure automatiche e personale in grado di attivare il piano di emergenza.

La Banca centrale europea raccomanda che i backup siano separati fisicamente e logicamente dai sistemi originali. Sottolinea inoltre la necessità di testare periodicamente le procedure di recupero e di valutare il rischio di dipendenza da un singolo fornitore. Guida BCE sui servizi cloud

Il problema della concentrazione del cloud

Il down di Google Cloud riaccende anche il dibattito sulla concentrazione tecnologica.

Una parte significativa dell’economia digitale dipende da pochi grandi operatori. Quando uno di questi subisce un guasto, il problema può colpire contemporaneamente banche, piattaforme di pagamento, servizi pubblici, siti web e applicazioni apparentemente indipendenti.

Il regolamento europeo DORA impone alle società finanziarie di gestire i rischi derivanti dai fornitori tecnologici esterni. Esternalizzare un servizio, infatti, non significa trasferire anche la responsabilità della sua continuità. Regolamento DORA

La vera lezione del down di Revolut

Il caso Revolut non dimostra che il cloud sia inaffidabile. Dimostra, al contrario, che il cloud deve essere utilizzato con un’architettura capace di prevedere il guasto.

La domanda corretta non è: “Il nostro provider può andare offline?”. La risposta sarà sempre sì.

La vera domanda è: “Che cosa succede ai nostri clienti quando il provider va offline?”

Per una banca digitale, la ridondanza non è soltanto una scelta tecnica. Significa permettere alle persone di pagare, prelevare denaro e accedere al proprio conto anche durante un’emergenza.

Il cloud fornisce gli strumenti per costruire servizi estremamente resistenti. Ma la resilienza non si acquista con un contratto: deve essere progettata, automatizzata e soprattutto testata.

Domande frequenti

Perché Revolut è andata offline?

Il disservizio del 20 ottobre 2026 è stato collegato a un guasto nell’infrastruttura Google Cloud di Londra, che ha interessato numerosi servizi digitali e finanziari.

I soldi dei clienti Revolut erano a rischio?

Revolut ha dichiarato che il denaro e i dati dei clienti sono rimasti al sicuro durante l’incidente.

Che cos’è la ridondanza cloud?

È la duplicazione di applicazioni, dati e risorse informatiche in infrastrutture indipendenti, così da mantenere il servizio disponibile quando uno dei sistemi si guasta.

Il multi-cloud impedisce qualsiasi down?

No. Può ridurre la dipendenza da un singolo fornitore, ma aumenta la complessità. Deve essere accompagnato da sincronizzazione dei dati, failover automatico e test periodici.

Qual è la differenza tra backup e disaster recovery?

Il backup conserva una copia dei dati. Il disaster recovery comprende sistemi e procedure necessari per ripristinare concretamente l’operatività entro tempi prestabiliti.