La caída de Google Cloud demuestra que la resiliencia es una decisión empresarial

Una caída de la nube ya no es solo una mala mañana para un ingeniero. Cuando un fallo de un proveedor interrumpe la banca, el vídeo judicial y los servicios públicos, se convierte en una prueba de hasta qué punto una sociedad ha concentrado discretamente su infraestructura digital en un único lugar.

El 20 de octubre, Google Cloud sufrió una interrupción en la región europe-west2, con la zona europe-west2-b especialmente afectada. Reuters informa de que los usuarios comunicaron problemas con Lloyds, HSBC y Rightmove, mientras que otros informes mencionaron a Revolut, ING Germany y Halifax entre los servicios afectados. La página de incidencias de Google indicó que los servicios no estaban disponibles en la zona afectada y que algunos servicios de la región podían experimentar un aumento de los errores. La caída se ha calmado desde entonces, pero la pregunta importante no es si Google acabó restableciendo el servicio. Es por qué tantas empresas quedaron expuestas al mismo fallo.

«La nube» no es una estrategia cuando todos usan el mismo proveedor

La computación en la nube suele venderse como una vía de escape frente a la frágil infraestructura interna. La promesa es real: un gran proveedor puede ofrecer distribución geográfica, recuperación automatizada y experiencia operativa que muchas empresas no podrían reproducir de forma rentable. La propia guía de recuperación ante desastres de Google se basa explícitamente en diseñar cargas de trabajo capaces de soportar interrupciones de la infraestructura de la nube.

Pero la resiliencia no es lo mismo que la disponibilidad. Un cliente puede operar en una región moderna de la nube y seguir dependiendo de un único proveedor, una única región, una única zona o un pequeño conjunto de servicios compartidos. El resultado es un sistema que parece distribuido en el diagrama de arquitectura, pero que en la práctica sigue estando concentrado.

Esa es la lección central de este incidente. El fallo no tuvo que dejar fuera de servicio todos los servicios de Google Cloud en todo el mundo para provocar una interrupción generalizada. Solo tuvo que alcanzar a suficientes clientes cuyas aplicaciones, flujos de pago o sistemas públicos dependían de la misma infraestructura regional. Una plataforma en la nube puede ser enorme y, aun así, crear un punto único de fallo para las empresas construidas sobre ella.

Por eso la expresión «migrar a la nube» se ha vuelto demasiado imprecisa para resultar útil. La pregunta pertinente no es si una empresa usa infraestructura en la nube. Es cuántas vías independientes quedan cuando esa infraestructura deja de estar disponible.

La redundancia es cara, y fingir lo contrario es aún peor

La parte incómoda es que la solución no consiste simplemente en marcar otra casilla en una herramienta de despliegue. Una resiliencia real puede exigir un segundo proveedor de nube, datos duplicados, sistemas de identidad independientes, rutas de pago alternativas, procedimientos de conmutación por error probados y equipos capaces de operar en condiciones degradadas. Esas medidas cuestan dinero y añaden complejidad.

También pueden dificultar la gestión de los sistemas. Un diseño multinube puede reducir la dependencia de un proveedor, pero introducir servicios incompatibles, una monitorización más complicada y trabajo adicional de seguridad. Replicar una base de datos entre proveedores no es automáticamente más seguro si el proceso de replicación, las credenciales o el plan de recuperación siguen compartiendo una dependencia común.

Por tanto, la respuesta adecuada no es exigir por reflejo que todas las empresas abandonen Google Cloud. Eso sería tan simplista como dar por hecho que un único proveedor siempre es suficiente. La pregunta sensata es la proporcionalidad: ¿qué ocurre si este servicio deja de estar disponible durante horas y cuál es el coste económico o público de esa interrupción?

En una herramienta interna de bajo riesgo, aceptar la concentración puede ser perfectamente racional. Para el acceso bancario o un servicio público, la respuesta debería ser distinta. Es el cliente —no solo el proveedor de la nube— quien debe decidir si el ahorro y la comodidad justifican la exposición.

Un fallo regional puede convertirse en un problema de infraestructura pública

La interrupción bancaria hace que el problema sea especialmente visible porque los clientes no experimentan la arquitectura de la nube como una decisión técnica abstracta. La viven como una tarjeta que no funciona, una cuenta a la que no pueden acceder o un servicio que deja de responder. La BBC informó de que la caída afectó a tribunales, bancos y otras empresas online, una combinación que convierte un incidente de proveedor en una cuestión de resiliencia institucional.

Eso no significa que Google sea el único responsable de todos los fallos posteriores. Las empresas eligen cómo diseñar sus sistemas, y la documentación disponible no demuestra que todos los bancos europeos dependieran del mismo diseño. La conclusión más defendible es más concreta —y más grave—: una interrupción regional de Google Cloud fue capaz de afectar a varios servicios esenciales porque muchas organizaciones habían aceptado una dependencia común.

También es una advertencia contra tratar el tiempo de actividad registrado en el pasado como sustituto de la planificación de la recuperación. Google Cloud ha sufrido otros incidentes, incluida una interrupción de Cloud Storage en us-central1 el 8 de octubre de 2026, cuando las subidas y escrituras sufrieron una latencia elevada y errores durante 12 horas y 30 minutos. El relato de IncidentHub afirma que la explicación preliminar de Google apuntaba al agotamiento de recursos tras una optimización para clasificar el tráfico, junto con un problema de base de datos independiente. Que las regiones y las causas sean distintas no demuestra que todas las cargas de trabajo estén expuestas del mismo modo, pero sí desmonta la reconfortante idea de que una gran plataforma puede tratarse como un servicio público invisible.

Los clientes deben pagar por la independencia allí donde un fallo importe

La gran comodidad de la industria de la nube es también su debilidad política y económica: permite que miles de organizaciones externalicen decisiones difíciles de infraestructura a unos pocos proveedores. Es eficiente hasta que la decisión externalizada se convierte en un modo de fallo compartido.

Nuestra opinión es que los reguladores y los consejos de administración deberían dejar de preguntar únicamente si un proveedor ofrece unas cifras de disponibilidad impresionantes. Deberían preguntar si un servicio crítico puede funcionar cuando su región principal, su proveedor o su plano de control compartido no están disponibles. La respuesta debe documentarse, probarse y financiarse, no quedar relegada a una diapositiva de recuperación ante desastres.

Google Cloud sigue siendo una plataforma potente, y esta caída no la convierte en un proveedor especialmente irresponsable. Sí demuestra que la resiliencia tiene un precio y que no se puede hacer desaparecer llamando «nube» a la infraestructura. Para las cargas de trabajo no críticas, la concentración puede seguir siendo un acuerdo inteligente. Para la banca y los servicios públicos, sin embargo, la independencia no es una duplicación inútil. Forma parte del propio servicio.