Caída de Azure: cuatro puertas y el sitio donde guardabas el plan B

Microsoft lista cinco servicios afectados en la caída de Azure del 30 de septiembre. Cuatro de ellos son el camino hasta tu infraestructura: ExpressRoute Gateway, VPN Gateway, Azure Firewall y Application Gateway con su WAF. El quinto es Azure VMware Solution.

Si tu empresa está en España y no tiene guardia de noche, probablemente te enteraste por la mañana. Empezó a las 22:30 del miércoles, hora peninsular, y se dio por mitigado a las 04:15 del jueves: cinco horas y cuarenta y cinco minutos. El expediente lleva el identificador 7Q30-010 y sigue publicado en el histórico de estado de Azure, que es de donde sale todo lo que se cita aquí.

Cuatro puertas y un destino

Las cuatro primeras entradas de la lista son el borde de tu red en Azure: por ahí aterriza la línea dedicada, por ahí entran los túneles y por ahí sale el tráfico que publicas a internet. La quinta, Azure VMware Solution, es otra cosa: ahí dentro corren máquinas virtuales. Si tu plan de contingencia para el entorno VMware pasa por AVS, el día 30 el camino y el posible destino estaban en la misma lista de servicios afectados.

Conviene decir enseguida lo que el parte no documenta, porque es tan importante como lo que sí: en ningún momento habla de pérdida de máquinas ni de datos. Lo que describe es esto, literalmente: «a subset of customers using gateway services in multiple regions experienced degraded or interrupted network connectivity. Impacted customers may have observed gateways failing to load in the Azure Portal, along with failures or delays in network management operations across the following impacted services».

Fíjate en el may have observed: Microsoft lo deja en condicional, y nosotros lo dejamos igual. La segunda mitad de esa frase es la que convierte un incidente del proveedor en un incidente tuyo. Las pasarelas podían no cargar en el portal, y las operaciones de gestión de red podían fallar o retrasarse. Lo que quedaba en duda, entonces, era la capacidad de tocar la red. Si tu procedimiento de contingencia dice «si cae la línea principal, levantamos el túnel de respaldo desde el portal», ese procedimiento necesitaba precisamente lo que estaba en duda.

Qué dice Microsoft que pasó

La explicación ocupa cuatro frases y una quinta con la mitigación. Van enteras, sin recortar, porque el detalle importa:

La atribución de Microsoft es clara y conviene no retorcerla: el cambio del gestor de pasarelas es the contributing, y es el que se revierte. El mantenimiento de sistema operativo solo se pausa as a precaution. Quien quiera la versión corta ya la tiene: alguien metió un cambio, el cambio generó más carga de la prevista y, al revertirlo, el servicio volvió.

Lo que nos interesa está en la primera frase, y es una lectura nuestra que marcamos como tal. La carga apareció cuando un mantenimiento unrelated —ajeno, sin relación con el cambio— iba avanzando gradually por varias regiones. Nadie que revisara el cambio del gestor de pasarelas tenía motivo para abrir el calendario del mantenimiento de sistema operativo: eran dos trabajos distintos sobre cosas distintas. Y avanzar por fases, que es la buena práctica y lo que recomendamos siempre, alarga en el tiempo la ventana en la que dos trabajos sin relación pueden coincidir sobre la misma infraestructura.

Esto no reatribuye nada: el cambio sigue siendo el que contribuyó. Lo que añade es una pregunta de gobernanza que vale para cualquier empresa, no solo para un hiperescalar. Un despliegue por fases responde bien a «¿rompe algo este cambio?». No responde a «¿qué más está rodando ahora mismo por esta infraestructura?». Y esa segunda pregunta casi nunca tiene dueño. La propia Microsoft dice que sigue investigando «the scaling behavior and the safeguards needed to help prevent recurrence».

El mecanismo del final de la cita merece una línea. El gestor escalaba solo normalmente; la demanda sobre los servicios de los que depende subió a causa de esa carga extra, y eso impidió que los servicios regionales escalaran como se esperaba. Hay ahí una cadena de dependencias que se satura entera, que es justo lo que convierte un autoescalado en un adorno. Contamos hace un mes el caso de una redundancia que no sobrevivió a un procedimiento, y la familia del problema es la misma: un supuesto que nadie llegó a escribir.

El reloj, que es la parte incómoda

El parte publica seis marcas de tiempo. Las restas de la última columna son nuestras, hechas sobre esas marcas:

Casi una hora hasta empezar a investigar, y cuando empezaron fue por un servicio en una región. Casi dos horas hasta identificar que el problema abarcaba varias. Dos horas y media hasta atar cabos con el mantenimiento. A partir de ahí quedó cerrado en tres horas y diez. Entender qué estaba pasando costó bastante más que arreglarlo. Esto no va de señalar a Microsoft: si a Microsoft le cuesta dos horas y media correlacionar dos trabajos propios, con toda su telemetría, tus opciones de correlacionar un cambio tuyo con uno de tu proveedor —a ciegas, de noche y sin ver su calendario— son bastante peores.

Cuántas regiones: la cifra que no está en la fuente

Estos días circula una cifra concreta: 18 o 19 regiones. Hemos ido a buscar ese número al histórico de estado y no está: el registro oficial dice «multiple regions», sin cantidad. La única lista de regiones que llega a dar aparece en la marca de las 01:36, y se refiere a las que quedaban por recuperar: «including France Central, North Europe, Southeast Asia, UK South, and UK West». Antes de eso solo nombra una, UK South, que es por donde empezó a investigar a las 21:29. Ese including indica además que ni siquiera esa enumeración está cerrada. Puede que esa cifra sea correcta; simplemente no se puede verificar contra la fuente primaria, y por eso aquí no la usamos como dato.

Hay un detalle más, escrito en la cabecera de la propia entrada, que explica bastante de por qué los números bailan: «Incorrect Region: correction: Impacted region(s) within a previous communication has been corrected». Microsoft corrigió la lista de regiones respecto de una comunicación anterior. Llevado a la práctica: el aviso que leíste en caliente, mientras decidías si conmutabas o esperabas, no es el aviso que queda. Quien aquella noche decidió con el criterio «mi región no sale en la lista» estaba usando un dato que después cambió. Ya escribimos sobre esta misma clase de letra pequeña al leer el perímetro que publica el proveedor, cuando contamos que tu nube aguanta perder una zona, no una región.

Tres cosas que sí están en tu mano

No puedes evitar que a tu proveedor se le crucen dos trabajos. Puedes conseguir que la próxima noche así te salga más barata. Tres cosas concretas, comprobables esta semana:

• Comprueba por dónde administras cuando el portal no responde. Si la única vía para tocar el cortafuegos o la pasarela es la consola del proveedor, un incidente del plano de gestión te deja sin manos. Vale la pena escribir cuál es la vía alternativa y, sobre todo, probarla una vez con el portal cerrado a propósito.
• Mide el camino, no solo el destino. Una monitorización que únicamente comprueba que la máquina virtual responde desde dentro de la nube se queda en verde durante un incidente de pasarela. Nosotros medimos latencia y pérdida extremo a extremo con Zabbix y SmokePing precisamente por esto: el síntoma que importa es el que ve el usuario desde donde está.
• Cronometra el plan. La pregunta útil es cuánto tardaste la última vez que lo ejecutaste de verdad. Nuestro último simulacro de recuperación completa fueron 14 minutos: es un dato interno, de una prueba propia, y lo damos como prueba y no como promesa. Lo que vale ahí es haber puesto el cronómetro.

El informe que lo explicará llegará, en teoría, a mediados de octubre

El parte incluye un compromiso: «Once that is completed, generally within 14 days, we will publish a Post Incident Review (PIR) to all impacted customers». Conviene leerlo con cuidado, porque hay dos supuestos encadenados. Los catorce días empiezan a contar cuando termine la retrospectiva interna, y de esa retrospectiva no hay fecha publicada, así que nuestra estimación de mediados de octubre es eso, una estimación. Y ese to all impacted customers señala a los afectados: el documento que diría qué salvaguarda han puesto —y por tanto si tu diseño tiene que cambiar— va dirigido a ellos.

De ahí la insistencia con las alertas de Azure Service Health configuradas con un destinatario real. La notificación en caliente llega tarde y con la lista de regiones a medio corregir, pero es el canal por el que después llega el análisis, y ese análisis es lo único que sirve para rediseñar algo.

El conflicto de interés por delante, como siempre: everyWAN vive de diseñar y operar infraestructura y cloud, así que cuando decimos «mide el camino» describimos algo que facturamos. Lo que no depende de nosotros es lo comprobable: el incidente 7Q30-010 está publicado y enlazado al final, las citas van en inglés y literales, y las restas de la tabla las puede rehacer cualquiera con las seis marcas de tiempo.

Fuentes (verificadas el 5 de octubre de 2026): ventana de impacto, lista de servicios afectados, descripción del síntoma, explicación de Microsoft sobre lo que sabe hasta ahora, reversión del cambio contribuyente, las seis marcas de tiempo, la nota de corrección de regiones y el compromiso del PIR — histórico de estado de Azure, incidente 7Q30-010 («Mitigated- Multiple services experiencing connectivity issues in multiple regions», 30-09-2026). Todas las citas en cursiva están tomadas literalmente de esa entrada. Son nuestros los siguientes elementos, y así se indican en el texto: la conversión a hora peninsular (UTC+2), las duraciones de la tabla, la estimación de mediados de octubre para el PIR y la lectura sobre la ventana que abre un despliegue por fases. La cifra de 18-19 regiones que circula estos días no aparece en el registro oficial y por eso no se usa aquí. El dato de los 14 minutos del simulacro de recuperación es interno de everyWAN, de una prueba propia, y se ofrece como prueba y no como compromiso contractual. Fotografía de portada: «Cable closet bh.jpg», Wikimedia Commons, dominio público; recortada y oscurecida por nosotros.