La caída de Google Cloud afecta a casi todas las operaciones bancarias y de otro tipo en Europa

Una caída de energía en la región europe-west2 (Londres) de Google Cloud dejó fuera de servicio a múltiples bancos y fintechs europeos, impidiendo a los clientes acceder a sus cuentas, hacer pagos o incluso desbloquear bicicletas compartidas. Los comentaristas usan el incidente para examinar por qué infraestructuras financieras críticas dependen de una sola zona de nube, debatiendo las realidades del diseño multirregión, las ventajas y desventajas de la nube pública frente al autoalojamiento, y los riesgos añadidos de las normas de soberanía de datos y de los proveedores con sede en EE. UU. Muchos lo ven como un caso de prueba para marcos regulatorios como la Ley de Resiliencia Operativa Digital de la UE y un recordatorio de que “la nube” no elimina la necesidad de una planificación rigurosa de la redundancia.

Impacto en los usuarios y fiabilidad de los neobancos

  • Muchos comentaristas informan de caídas en neobancos y fintechs (p. ej., Revolut), con fallos en pagos con tarjeta, retiradas en cajeros automáticos y acceso a la app.
  • Algunos usuarios destacan la falta de soporte telefónico o de contacto humano durante los incidentes como una gran desventaja de los bancos solo por app.
  • Otros comparan esto con neobancos que invirtieron en sistemas separados y simplificados de “stand-in” en distintos proveedores, que preservaron las funciones bancarias básicas durante caídas anteriores.
  • Unos pocos usuarios evitaron o abandonaron ciertos neobancos por preocupaciones sobre la regulación, el bloqueo de cuentas o la mala gestión de incidentes, prefiriendo bancos tradicionales con soporte telefónico fiable.

Causa y alcance de la caída

  • La página de estado de Google atribuye el problema a un “power event” en la zona europe-west2-b, con restauración parcial en unos 30 minutos y más mitigación después.
  • A los comentaristas les sorprende que grandes bancos y servicios financieros parezcan haber concentrado cargas de trabajo críticas en una sola zona/región, en lugar de arquitecturas multizona o multirregión.
  • Algunos informan de que servicios en otras zonas o regiones también tuvieron problemas, pero el alcance y la causa raíz del impacto entre zonas no están claros.

Arquitectura en la nube, resiliencia y pruebas

  • Varios comentarios subrayan que las configuraciones multi-AZ o multirregión solo importan si se prueban con regularidad; muchas organizaciones nunca simulan la pérdida total de una AZ.
  • Los profesionales señalan que la multicloud y la verdadera redundancia geográfica son difíciles y caras, especialmente con una consistencia estricta y dependencias heredadas.
  • Hay críticas a que los hyperscalers puedan tener dependencias entre zonas/regiones y límites de capacidad, lo que provoca problemas de “thundering herd” cuando falla una zona.
  • Otros sostienen que también habría caídas si todos colocaran su propio hardware en el mismo centro de datos; el verdadero problema es la falta de redundancia correctamente implementada.

Soberanía, regulación y DORA

  • La discusión sobre “soberanía de la IA” frente a “soberanía de cómputo/datos”: algunos dicen que depender de una sola región de un hyperscaler contradice los objetivos de soberanía.
  • Otros distinguen soberanía (dónde residen los datos) de redundancia (cuántas ubicaciones hay), argumentando que reguladores y empresas deben considerar ambas.
  • Surgen preguntas sobre las implicaciones regulatorias en la UE/Reino Unido (p. ej., DORA), con la idea de que las instituciones pueden enfrentarse a revisiones y planes de mejora, pero es poco probable que haya grandes multas si este es el primer gran problema.
  • Se citan normas de residencia legal/geográfica y el Brexit como razones por las que algunos bancos mantienen las cargas de trabajo del Reino Unido estrictamente en regiones del Reino Unido, lo que limita las opciones de redundancia.

Comparaciones entre proveedores de nube y sentimiento general

  • Opiniones divididas sobre los proveedores: algunos sitúan a AWS y Azure por encima de “todo lo demás”, mientras que otros afirman que GCP suele tener menos caídas y una fuerte seguridad.
  • Azure se describe como bien diseñado en el nivel de plano de control, pero torpe en la implementación y la documentación.
  • Es común el escepticismo sobre que “la nube será más barata y más resiliente”; muchos ven la nube como un cambio de lugar de los fallos, no como su eliminación.