--- title: "Segunda gran caída en la nube en siete días: Microsoft Azure sufre un fallo global por Azure Front Door y arrastra a Microsoft 365 y Xbox" description: "Una semana después del incidente masivo de Amazon Web Services (AWS), Microsoft Azure vivió el miércoles 29 de octubre otra avería de gran calado que dejó fuera de juego a servicios de la propia Micro..." url: https://revistacloud.com/segunda-gran-caida-nube-siete-dias-microsoft-azure-sufre-un-fallo-global/ date: 2025-10-30 modified: 2025-10-30 author: "Antonio" image: https://revistacloud.com/wp-content/uploads/2023/11/microsoft-azure-cloud-unsplash.jpg categories: ["Cloud", "Noticias"] tags: ["azure", "microsoft"] type: post lang: es --- # Segunda gran caída en la nube en siete días: Microsoft Azure sufre un fallo global por Azure Front Door y arrastra a Microsoft 365 y Xbox Una semana después del incidente masivo de Amazon Web Services (AWS), **Microsoft Azure** vivió el miércoles **29 de octubre** otra **avería de gran calado** que dejó fuera de juego a servicios de la propia Microsoft y de terceros. El problema, que **comenzó a las 15:45 UTC (16:45 en Canarias / 17:45 en la España peninsular)** y quedó **mitigado a las 00:05 UTC del 30 de octubre**, tuvo su origen en **Azure Front Door (AFD)**, la red global de distribución de contenidos y aplicaciones de Azure. La consecuencia inmediata fueron **latencias, timeouts y errores** en cascada para **Microsoft 365**, **Xbox**, **Minecraft**, portales de administración y un abanico de **aplicaciones empresariales** que dependen de Azure. Aunque el impacto no alcanzó el [nivel del apagón de AWS](https://revistacloud.com/caida-aws-espana-a-fondo-dependencia-excesiva-ha-sin-plan-b-y-la-oportunidad-de-un-cloud-europeo-mas-resiliente/) de la semana pasada, la sucesión de incidentes en dos de los grandes proveedores de nube **reabre el debate** sobre la **resiliencia** de Internet y la **dependencia** mundial de un puñado de hiperescalares para operar negocios y servicios críticos. ## Qué pasó y por qué Microsoft publicó un **PIR preliminar** (Post Incident Review) que señala un **cambio de configuración involuntario** en **Azure Front Door** como desencadenante del fallo. Ese despliegue de configuración provocó un **estado inválido o inconsistente** en **numerosos nodos AFD**, que **dejaron de cargar correctamente**. A medida que esos nodos “no saludables” **salían del pool global**, el tráfico se **repartió de manera desequilibrada** entre los nodos restantes, amplificando la indisponibilidad con picos de **errores y tiempos de espera**. La respuesta de ingeniería pasó por **bloquear de inmediato** cualquier **nuevo cambio de configuración**, **revertir** AFD al **“último estado conocido bueno”** y **recuperar** progresivamente los nodos, **re-equilibrando** el tráfico para evitar sobrecargas al volver a servicio. Microsoft atribuye la causa raíz a un **defecto de software** en los **mecanismos de validación** de despliegues, que permitió que la configuración defectuosa **se colara** pese a las salvaguardas existentes. **Cronología (resumen):** - **15:45 UTC** del 29/10: inicia el impacto en clientes. - **16:18–16:20 UTC**: primeras comunicaciones públicas y avisos dirigidos a clientes en Azure Service Health. - **17:30 UTC**: **bloqueo** de cambios de configuración. - **17:40–18:45 UTC**: **despliegue** global de la configuración corregida y **recuperación manual** de nodos, con **ruteo gradual** hacia nodos sanos. - **00:05 UTC** del 30/10: Microsoft da por **mitigado** el impacto de AFD, con “cola larga” residual en un pequeño número de clientes. ## Qué servicios se vieron afectados El alcance fue **transversal**. Además de **Microsoft 365** —con **Word, Excel, PowerPoint y Outlook** inaccesibles para muchos usuarios durante las horas críticas—, **OneDrive** y **Teams** sufrieron **indisponibilidad intermitente**. También hubo **fallos de actualización** en **Windows Defender** y afectación a **Copilot** en determinados entornos. En el ecosistema de entretenimiento, **Xbox Live** y **Minecraft** registraron **caídas**. En la **capa Azure**, los problemas alcanzaron a **App Service**, **Azure SQL Database**, **Container Registry**, **Azure Databricks**, **Azure Virtual Desktop**, **Media Services**, **Azure Maps**, **Azure Portal**, **Microsoft Entra ID** (componentes de identidad y gestión), **Microsoft Sentinel (Threat Intelligence)**, **Microsoft Purview**, **Microsoft Copilot for Security** y **Healthcare APIs**, entre otros. Más allá de Microsoft, el **efecto dominó** afectó a empresas que **frentean** sus aplicaciones con AFD o consumen servicios alojados en Azure. Durante las horas del incidente, **compañías aéreas**, **retailers** y **operadores** reportaron **interrupciones**: **Alaska Airlines** tuvo problemas de **check-in**; **Starbucks** y otras marcas experimentaron **fallos transaccionales**; **Heathrow** y **Vodafone UK** figuran entre los nombres citados en la cobertura internacional. Los picos de reportes en **Downdetector** para **Azure** y **Microsoft 365** reforzaron la **escala** del evento. ## ¿Está resuelto? A las **00:05 UTC** del 30 de octubre, Microsoft informó de que **errores y latencias** habían regresado a **niveles previos** al incidente, con una **pequeña cola** de clientes aún viendo **incidencias** mientras continuaban las **mitigaciones** finales. **Los cambios de configuración de clientes en AFD** **siguen temporalmente bloqueados** mientras se termina de estabilizar el sistema; la compañía notificaría la **retirada del bloqueo** vía **Azure Service Health**. ## Por qué duele tanto cuando falla AFD **Azure Front Door** es, a grandes rasgos, el **delantero** de muchos servicios: un **CDN** y **front de aplicación** global que sirve contenido y enruta peticiones hacia **backends** distribuidos, con funciones de **equilibrado**, **aceleración** y **seguridad**. Si AFD **falla** o **pierde capacidad** rápidamente a escala global, no solo **se degrada** la entrega de contenido; también **se “atascan”** los accesos a **portales** y **APIs** críticas que administran otros servicios de Azure. De ahí que un problema en AFD **trascienda** a múltiples capas: desde el **usuario final** que no puede abrir un documento en la web, hasta el **administrador** que no puede entrar al **portal de Azure** para solventarlo. ## La coincidencia con AWS: dos sustos en una semana El **20 de octubre**, **AWS** afrontó un **apagón** prolongado anclado en **US-EAST-1** cuyo origen se relacionó con un **problema de DNS** en la **automatización** de su ecosistema (un registro vacío generado por error en el sistema de gestión DNS ligado a DynamoDB). La avería sacó de servicio a miles de aplicaciones y servicios globales y obligó a **desactivar** temporalmente la automatización afectada mientras se desplegaban **salvaguardas** adicionales. Que **dos hiperescalares** encadenen **incidentes relevantes** en apenas **siete días** no es habitual. Sin embargo, la explicación técnica converge en un punto: **la complejidad** y la **automatización a gran escala** son **ventaja**… y también **frontera de riesgo** cuando se **validan** (o **no** se validan) cambios de forma defectuosa. ## Qué pueden hacer las organizaciones (más allá del titular) Ningún proveedor —sea nube pública, privada o “on-prem”— está libre de **incidentes**. La clave está en **diseñar** con la **asunción** de que **fallarán**. Estas son algunas **líneas de defensa** que el sector recomienda y que este incidente vuelve a poner en primer plano: - **Separación de control y datos.** Si el **plano de control** (portales/APIs) cae, disponer de **métodos programáticos alternativos** (CLI/PowerShell, automatizaciones fuera del portal) **evita la ceguera operativa**. - **Multi-región de verdad.** Servicios desplegados en **varias regiones** con **conmutación automática** o **manual guiada** —y **pruebas** regulares de “**game days**”— reducen el **tiempo de indisponibilidad**. - **Dependencias explícitas.** Cartografiar **qué servicios pasan por AFD** (o por el CDN/WAF análogo en otros proveedores) y **reducir monocultivo**: por ejemplo, **multi-CDN** para sitios públicos de alta criticidad. - **Cachés y modos degradados.** Para **webs transaccionales**, dotar de **modos reducidos** que permitan **operar** funciones esenciales si el backend **no responde** (p. ej., lectura en caché de catálogos o contenidos críticos). - **Copias y continuidad**. Mantener **copias inmutables** (WORM), **snapshots** y **planes de DR** probados. En productividad, conocer los **modos offline** de suites como **Microsoft 365** (por ejemplo, **Outlook** en caché, **OneDrive** con **archivos locales**) **amortigua** el impacto. - **Alertas de salud**. Configurar **Azure Service Health** (y el equivalente en otros proveedores) para **recibir alertas** por **correo, SMS, push o webhooks** y **disparar** playbooks automáticos en cuanto se detecten **degradaciones**. ## Lecciones de ingeniería (y de producto) 1. **Guardarraíles de configuración.** Las **validaciones** en pipelines de despliegue deben ser **bloqueantes** y con **doble control** en cambios **multitenant** o **globales**. Un “**inocente**” cambio de **tenant** no puede propagarse **sin freno** a una red que sirve a **millones** de usuarios. 2. **Reversiones rapidísimas** y **“último estado bueno”** siempre al alcance. Mantener **snapshots de configuración** y **circuit breakers** que permitan **cortar** la propagación antes de que el problema **se desborde**. 3. **Recuperaciones graduales.** Reintegrar **nodos** a un **pool global** **paso a paso** evita **re-fallos** por **sobrecarga**; es más **lento**, pero **estable**. 4. **Comunicación útil.** Los **PIR** con **líneas de tiempo**, **causa técnica**, **acciones** y **medidas preventivas** aportan **confianza** al cliente y orientan **mejoras** internas. ## Contexto: la nube sigue, pero con ojos abiertos Las **ventajas** de la nube —**elasticidad**, **catálogo de servicios**, **escalabilidad**— **no desaparecen** por dos incidentes. Pero estos episodios recuerdan que **externalizar infraestructura** no significa **externalizar responsabilidad**: la **arquitectura** y el **plan de continuidad** siguen siendo **de cada empresa**. Para muchas organizaciones, el **modelo híbrido** (combinando **on-prem**, **cloud privada** y **nube pública**) ofrece **equilibrios** razonables entre **control**, **coste** y **agilidad**. --- ### Preguntas frecuentes **¿Qué es exactamente Azure Front Door y por qué su fallo deja tantos servicios KO?** **Azure Front Door** es un **front global** (CDN + balanceo + seguridad) que **intermedia** millones de peticiones hacia servicios de Microsoft y de clientes. Si AFD **entra en un estado inválido** a escala, **se rompen** rutas de acceso y **se disparan** latencias/errores en **portales**, **APIs** y **aplicaciones** que dependen de él. **¿Cuánto duró la incidencia y qué hizo Microsoft para arreglarla?** El impacto **arrancó a las 15:45 UTC** del **29 de octubre** y se **dio por mitigado** a las **00:05 UTC** del **30 de octubre**. Microsoft **bloqueó cambios**, **revirtió** a la **última configuración válida**, **recuperó** nodos manualmente y **re-equilibró** el tráfico de forma **gradual** para estabilizar el sistema. **¿Está relacionado con la caída de AWS de la semana pasada?** No directamente. En **AWS**, el 20 de octubre, el detonante fue un **problema de DNS** en **US-EAST-1** ligado a **automatización**. En Azure, el 29 de octubre, se trató de un **cambio de configuración** en **Azure Front Door** que **bypaseó** controles por un **defecto de software**. Comparten un patrón: **automatización** y **validación** insuficiente de cambios en **planos críticos**. **¿Qué puede hacer una empresa para mitigar estos eventos?** Adoptar **multi-región** real, **métodos programáticos** alternativos al portal, **multi-CDN** en sitios críticos, **modos degradados** y **cachés**, **copias inmutables** y **DR** probados, además de **alertas** de salud (**Azure Service Health**) que activen **playbooks** automáticos. --- **Fuentes (selección):** - **[Microsoft Azure – Status History](https://azure.status.microsoft/en-gb/status/history/)** (PIR preliminar del 29/10/2025; tracking ID YKYN-BWZ, cronología e impacto por AFD).