Una semana después del incidente de Amazon Web Services (AWS), Microsoft Azure sufrió una significativa avería el miércoles 29 de octubre, que afectó tanto a sus servicios como a los de terceros. La falla comenzó a las 15:45 UTC y fue mitigada a las 00:05 UTC del día siguiente, con un impacto que se originó en Azure Front Door (AFD), la red global de distribución de contenidos de Azure. Como resultado, se presentaron latencias, tiempos de espera y errores en servicios como Microsoft 365, Xbox, Minecraft y diversas aplicaciones empresariales que dependen de esta plataforma.
Aunque el incidente no igualó el nivel del apagón de AWS previo, la seguidilla de fallas en dos gigantes de la nube reabre el debate sobre la resiliencia de Internet y la dependencia global en unos pocos proveedores.
Qué ocurrió
Según el Post Incident Review preliminar de Microsoft, el problema se produjo por un cambio de configuración involuntario en AFD, que generó un estado inconsistente en numerosos nodos, afectando la carga correcta. Esto provocó una distribución desequilibrada del tráfico entre los nodos restantes, amplificando los problemas de disponibilidad.
La respuesta de Microsoft incluyó el bloqueo de cambios de configuración, revirtiendo AFD al «último estado conocido bueno» y recuperando progresivamente los nodos.
Servicios afectados
El impacto fue transversal, afectando a Microsoft 365 (incluyendo Word, Excel y Outlook), OneDrive, Teams, Windows Defender y Xbox Live, entre otros. Además, diversos servicios de Azure como App Service y Azure SQL Database también se vieron comprometidos. El efecto dominó alcanzó a empresas como Alaska Airlines, Starbucks, y Vodafone UK.
Soluciones y consideraciones
Microsoft aseguró que para las 00:05 UTC del 30 de octubre, los errores habían regresado a niveles previos al incidente. Sin embargo, los cambios de configuración siguen bloqueados mientras se estabiliza el sistema.
Finalmente, Microsoft enlistó varias líneas de defensa que las organizaciones podrían adoptar para mitigar el impacto de futuros incidentes, destacando la importancia de un diseño que asuma la posibilidad de fallas. Esto incluye la implementación de estrategias multi-región, modos degradados y un monitoreo eficaz de la salud del sistema. La lección es clara: externalizar infraestructura no implica externalizar responsabilidades, y la arquitectura resiliente sigue siendo clave para las empresas que operan en la nube.
Más información y referencias en Noticias Cloud.
