Introducción
El 20 de octubre de 2026, a las 07:08 hora de Londres, un corte de suministro eléctrico afectó a la zona europe-west2-b de Google Cloud. Ocho horas después, cuando finalmente se dio el visto bueno, bancos británicos, funcionarios judiciales, empresas de mensajería y millones de usuarios habían experimentado en carne propia lo que significa depender de una única zona de disponibilidad en un hyperscaler. El incidente puso de manifiesto una tensión tan antigua como los propios SLA cloud: la que existe entre la promesa de una arquitectura redundante y la realidad operativa en el momento de una interrupción.
Cuando la redundancia zonal no cumple lo que promete
Las regiones de Google Cloud se organizan en zonas de disponibilidad diseñadas para operar de forma independiente. En teoría, el fallo de europe-west2-b no debería arrastrar a los servicios de las otras dos zonas londinenses. En la práctica, ese día sufrieron perturbaciones 38 productos cloud: BigQuery, Cloud Run, Google Kubernetes Engine, App Engine y Cloud Filestore, entre otros.
La causa reside en la arquitectura de red: los equipos encargados de enrutar las respuestas salientes hacia Internet se encontraban en la zona privada de suministro eléctrico. Al apagarse esos equipos, las rutas anunciadas por Google fueron retiradas de las redes asociadas, dejando inaccesibles servicios mucho más allá de la zona afectada. Este mecanismo de cascada no era nuevo: en julio de 2022, la misma región europe-west2 había vivido un incidente similar con consecuencias comparables sobre los servicios regionales.
En un primer momento, Google no ofreció ninguna solución alternativa. La primera comunicación pública llegó dos horas y media después del inicio de las perturbaciones. Solo tras varias horas se formuló la recomendación: migrar las cargas de trabajo hacia una zona disponible. Para las aplicaciones no diseñadas para ese tipo de conmutación, el consejo llegó demasiado tarde.
Una economía entera concentrada en una sola zona
Lo que hace especialmente revelador este incidente es la naturaleza de los servicios afectados. Lloyds Banking Group, HSBC, Revolut, Royal Mail, Rightmove, DPD y BT figuraban entre las organizaciones impactadas. El servicio de videoconferencia judicial británico (HM Courts and Tribunals Service), utilizado para audiencias telemáticas en Inglaterra y Gales, también sufrió interrupciones.
La concentración de servicios tan heterogéneos —banca, justicia, logística, sector inmobiliario, telecomunicaciones— sobre una misma infraestructura cloud plantea una cuestión seria de gobernanza corporativa. No es sorprendente que un hyperscaler sufra una caída: todos lo hacen en algún momento. Lo verdaderamente llamativo es que organizaciones tan dispares compartan un mismo punto único de fallo, sin que sus planes de continuidad de negocio hayan anticipado aparentemente este escenario.
Lo que los arquitectos cloud deben revisar
Tres lecciones se imponen.
Contar con una arquitectura multi-zona no es suficiente. Es imprescindible probar regularmente la conmutación efectiva entre zonas y asegurarse de que la configuración DNS y de red lo permita en cuestión de minutos. El día de un incidente no es el momento de descubrir que una dependencia oculta ancla la aplicación a una única zona.
La monitorización del estado de los proveedores debe integrarse en las herramientas de observabilidad internas, sin esperar las comunicaciones oficiales. Dos horas y media de incertidumbre equivalen a tiempo de diagnóstico perdido y decisiones de escalado retrasadas, con el consiguiente impacto en el negocio.
Por último, para los servicios verdaderamente críticos, la resiliencia va más allá de la arquitectura cloud. Implica cuestionar la concentración en un único proveedor y evaluar seriamente las arquitecturas multi-cloud o híbridas, aunque la complejidad adicional resulte difícil de justificar en condiciones normales de operación. El próximo corte eléctrico tampoco avisará con antelación.