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 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)
- 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.
- 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.
- Recuperaciones graduales. Reintegrar nodos a un pool global paso a paso evita re-fallos por sobrecarga; es más lento, pero estable.
- 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 (PIR preliminar del 29/10/2025; tracking ID YKYN-BWZ, cronología e impacto por AFD).
