Cuando el Fallo es del Proveedor Cloud: lo Que la Caída de Azure del 30 de Septiembre Enseña Sobre la Recuperación ante Desastres
Más de uno de cada cuatro incidentes empieza en un proveedor y tarda más del doble en resolverse. La caída de Azure del 30 de septiembre muestra por qué: cuando el problema está al otro lado del contrato, el equipo interno solo puede esperar. Lo que se controla es la preparación.
La noche del 30 de septiembre, varias empresas europeas perdieron la conexión entre sus oficinas y la nube. Ninguna había cambiado nada. Los equipos internos abrieron incidentes, confirmaron que la configuración era correcta y se quedaron mirando la página de estado del proveedor. No había nada más que hacer.
Ese es el punto de este artículo. No el fallo en sí, que les ocurre a todos los proveedores, sino lo que revela sobre dónde está el control cuando el fallo no es nuestro.
Qué pasó el 30 de septiembre
Según el historial de estado de Microsoft Azure, entre las 20:30 UTC del 30 de septiembre y las 02:15 UTC del 1 de octubre de 2026, unas cinco horas y cuarenta y cinco minutos, varios servicios de red tuvieron fallos de conexión en varias regiones. Entre los afectados estaban las pasarelas de conexión privada (ExpressRoute), las conexiones por red privada virtual (VPN Gateway), Azure Firewall, Application Gateway y Azure VMware Solution. Microsoft cita, entre las regiones todavía afectadas al final del incidente, North Europe, UK South, UK West y France Central.
La causa indicada en el resumen del incidente fue un cambio reciente en un servicio regional de gestión de pasarelas, que generó una carga superior a la prevista mientras un mantenimiento de sistema operativo, sin relación con ese cambio, avanzaba por varias regiones. El cambio se revirtió y el mantenimiento se suspendió.
Fíjese en el tipo de servicio afectado. No fue una aplicación. Fue la conexión entre la empresa y la nube. Cuando esa conexión cae, las aplicaciones pueden estar perfectamente sanas y, aun así, inaccesibles.
Por qué estos fallos tardan más
La caída de Azure no es un caso aislado. Es un patrón medido.
El informe analizó unos 178.000 registros públicos de páginas de estado, que corresponden a aproximadamente 109.000 incidentes no planificados en más de 390 empresas de 13 sectores, entre 2018 y junio de 2026. El mismo estudio contó 223 empresas afectadas, aguas abajo, por la caída de AWS del 20 de octubre de 2025.
La diferencia entre 96 y 247 minutos no es técnica. Es de control. En un fallo interno, el equipo diagnostica, corrige y confirma. En un fallo del proveedor, el equipo diagnostica que no puede corregir. Todo lo que reduce ese tiempo tiene que haberse decidido antes.
La resiliencia no se compra al proveedor
Los acuerdos de nivel de servicio de los proveedores cloud cubren la disponibilidad de su servicio, normalmente con créditos en la factura cuando fallan. No cubren la continuidad de la operación de quien los usa. Un crédito de unos pocos puntos porcentuales en una factura mensual no compensa una noche de ventas perdidas ni una línea de producción parada.
Es el modelo de responsabilidad compartida leído desde su lado menos cómodo. El proveedor responde por la infraestructura que opera. Cómo distribuye cada empresa sus cargas entre regiones, cuántas conexiones tiene con la nube y qué hace cuando una de ellas cae sigue siendo responsabilidad de quien diseña la arquitectura.
En la práctica, muchas organizaciones descubren la dependencia el día en que falla. La arquitectura creció región a región, servicio a servicio, y nadie dibujó el mapa de quién depende de quién.
Las cuatro preguntas de un mapa de dependencias
Un mapa de dependencias útil no necesita una herramienta nueva. Necesita cuatro respuestas por cada servicio crítico.
- ¿De qué proveedor y de qué región depende? Incluidas las dependencias indirectas, como la conexión privada, el proveedor de identidad o el servicio de nombres de dominio.
- ¿Qué sigue funcionando cuando esa región cae? Nada, una versión degradada o una alternativa en otra región. La respuesta honesta suele ser "nada".
- ¿Cuánto tiempo y cuántos datos se pueden perder? Son el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO). Si nadie los definió, la arquitectura los definió por omisión.
- ¿Quién decide activar la alternativa, y en cuánto tiempo? Una alternativa que exige una reunión de dirección a las dos de la madrugada no es una alternativa.
Estas cuatro preguntas separan un plan de recuperación de un documento llamado plan de recuperación. La diferencia entre tener copias de los datos y poder volver a operar se explica en Una copia de seguridad no es recuperación ante desastres.
Lo que la NIS2 ya exige
La directiva europea NIS2, transpuesta en Portugal por el Decreto-Ley 125/2025, en vigor desde el 3 de abril de 2026, trata este tema directamente. El artículo 21, apartado 2 incluye entre las medidas mínimas de gestión de riesgos la continuidad de las actividades, incluida la gestión de copias de seguridad y la recuperación ante desastres, y la seguridad de la cadena de suministro, incluidas las relaciones con proveedores directos y prestadores de servicios.
Un proveedor cloud es, a efectos prácticos, parte de esa cadena. Y, según el Centro Nacional de Ciberseguridad de Portugal, los órganos de gestión de las entidades afectadas deben ahora aprobar formalmente las políticas de gestión de riesgos, supervisar su implantación y asegurar la respuesta y la recuperación en caso de incidente.
Para quien es proveedor de una entidad afectada, la misma exigencia llega por vía contractual, como se explica en NIS2 en Portugal: qué cambia para los proveedores de entidades esenciales.
Por dónde empezar
No hace falta un programa multicloud para reducir el riesgo. Cuatro pasos cubren la mayor parte de la exposición.
Inventariar los servicios críticos y sus dependencias. Responder a las cuatro preguntas anteriores para los cinco a diez servicios de los que el negocio no puede prescindir.
Probar la caída de una región. No en papel. Cortar, en un entorno de pruebas o en una ventana controlada, el acceso a una región y cronometrar el tiempo hasta que la operación vuelve. El número que sale de esa prueba es el RTO real.
Tener más de un camino hasta la nube. Una única conexión privada es un punto único de fallo, incluso cuando el proveedor tiene redundancia interna. Una segunda conexión, o una alternativa por red privada virtual probada, cambia el escenario.
Escribir quién decide. Nombre, sustituto y criterio de activación. Un incidente a las dos de la madrugada no es el momento de descubrir que nadie tiene autoridad para mover el tráfico a otra región.
Preguntas frecuentes
¿Tener cargas en dos regiones del mismo proveedor lo resuelve? Resuelve una parte. Protege contra la caída de una región, no contra un problema que atraviese varias regiones a la vez, como el del 30 de septiembre. La decisión depende de cuánto cuesta una hora de parada para cada servicio.
¿Es obligatoria una estrategia multicloud? No. Para la mayoría de las empresas, una segunda región probada y un plan de recuperación cronometrado reducen más riesgo por euro invertido que una arquitectura multicloud completa.
¿No es el proveedor el responsable del fallo? Del fallo de su servicio, sí, en los términos del contrato. De la continuidad de la operación de cada cliente, no. Esa continuidad se diseña y se prueba del lado de quien usa la nube.
Conclusión
La caída del 30 de septiembre duró menos de seis horas y la resolvió el proveedor. Para las empresas afectadas, la pregunta útil no es por qué falló Azure. Es qué habría cambiado si, la víspera, alguien hubiera respondido a las cuatro preguntas del mapa de dependencias.
Para mapear las dependencias críticas de la operación cloud y probar la recuperación, es posible reservar una Sesión de Orientación, sin compromiso.