El plano de control es lo primero que se cae, y tu plan B lo necesita

Hace un año, un lunes a las 8:48 de la mañana hora de aquí, un registro DNS se quedó sin ninguna dirección dentro y arrastró a medio internet detrás. Lo que casi no se contó entonces, y consta en el informe oficial, es qué siguió funcionando: las máquinas encendidas. No se apagó ninguna. Lo que no se podía hacer era arrancar otra.

Qué pasó, con el reloj de aquí

AWS gestiona los registros DNS de sus endpoints con dos piezas automáticas: un DNS Planner, que mira la salud de los balanceadores y escribe un plan, y un DNS Enactor, que aplica ese plan desde tres zonas de disponibilidad independientes. Aquella noche un Enactor se quedó anormalmente retrasado reintentando sus actualizaciones. Mientras tanto, un segundo Enactor aplicó un plan más nuevo y disparó la limpieza de los viejos. Cuando el primero por fin terminó, sobrescribió el plan nuevo con el suyo, ya caduco, y la limpieza se llevó por delante ese plan obsoleto: el registro dynamodb.us-east-1.amazonaws.com se quedó sin una sola dirección dentro. La comprobación que debía evitarlo existía. En palabras de AWS, «la comprobación que se hacía al principio del proceso de aplicación del plan, que garantiza que el plan es más nuevo que el aplicado anteriormente, estaba caducada a esas alturas por los retrasos inusualmente altos en el procesamiento del Enactor».

El informe da las horas en hora del Pacífico. Traducidas a la península, para que se entienda lo que vio aquí quien lo vivió: el fallo empezó el lunes 20 de octubre de 2025 a las 8:48, justo cuando abrían las oficinas. A las 9:38 AWS ya sabía que la causa estaba en el estado del DNS de DynamoDB. A las 10:15 había mitigaciones temporales para que algunos de sus servicios internos volvieran a conectar. A las 11:25 el registro estaba restaurado y a las 11:40 habían expirado las cachés. Dos horas y cincuenta y dos minutos. Ese es el número que se quedó en los titulares, y es el que más engaña.

Las que ya estaban encendidas no se enteraron

El informe lo dice sin adornos: las instancias EC2 que ya estaban en marcha siguieron sanas y sin afectación. El plano de datos de EC2 aguantó: las máquinas encendidas, sus procesos y sus conexiones. El de DynamoDB no, porque nadie podía resolver su nombre, y por eso una aplicación perfectamente sana devolvía errores. Lo que reventó del todo fue el plano de control: la parte del sistema que sirve para crear, modificar y destruir cosas.

Repasa la lista de lo que estuvo caído y mírala como si fuera tu procedimiento de recuperación, porque se parece mucho: arrancar instancias nuevas, crear o actualizar funciones Lambda, levantar contenedores en ECS, EKS y Fargate, sustituir un clúster de Redshift, pedir credenciales temporales a STS, autenticarse en la consola y entrar en la consola de soporte para abrir un ticket. Todo eso es plano de control. Y todo eso es, casi literalmente, el guion que ejecuta alguien a las nueve de la mañana cuando decide que hay que irse a otro sitio.

La consola de soporte, por cierto, estuvo inaccesible desde las 8:48 hasta las 11:40. Exactamente la misma ventana. El canal para preguntar qué está pasando formaba parte de lo que estaba pasando.

La cola larga: 2 h 52 min de titular, 28 h 17 min de verdad

Cuando el DNS volvió, empezó el segundo acto. El subsistema que asigna trabajo a los servidores físicos de EC2 (el DropletWorkflow Manager) intentó renovar de golpe los contratos de todos los servidores físicos de la región y, en palabras del propio informe, «había entrado en un estado de colapso congestivo y era incapaz de avanzar en la recuperación de los contratos de los droplets». Lo arreglaron a mano, frenando el ritmo a las 13:14 y reiniciando servidores de forma selectiva hasta las 14:28. Es exactamente el patrón que contamos en la segunda caída la provocas tú: el sistema no se hunde por la caída, se hunde por la avalancha de la recuperación.

Y después vino el tercer acto, el más desagradable: las instancias recién creadas tardaban en tener red, el sistema de comprobación de salud las daba por buenas antes de tiempo, y el balanceador de red las metía y las sacaba en ciclos —retirando capacidad sana—. AWS acabó desactivando el failover automático a las 18:36. Con las horas de aquí puestas, el cuadro queda así:

Un día y medio largo entre el primer error y lo último que AWS dio por restablecido. (El impacto en contenedores arrancó tres minutos antes del minuto cero, a las 8:45; el resto de la columna cuenta desde las 8:48.) Si firmaste un acuerdo con un porcentaje anual de disponibilidad, ese porcentaje no te dijo nada de esto, y es el argumento que desarrollamos en un porcentaje anual no dice cuánto dura una caída. Lo que notó la empresa no fue el 99 coma lo que sea: fue que el martes a mediodía todavía había clústeres que no respondían a una consulta porque el reemplazo automático se había quedado a medias.

Por qué esto es un problema de plan B

Casi todos los planes de recuperación que leemos están escritos en verbos de creación. «Se levantan las máquinas en la región secundaria.» «Se escala el grupo a X nodos.» «Se emite un certificado.» «Se restaura la copia en una instancia nueva.» «Se abre incidencia con el proveedor.» Son verbos que suponen que, en el peor día del año, el proveedor te va a dejar crear. Y el peor día del año es precisamente el día en que lo que falla es la capacidad de crear.

Esto no es una peculiaridad de AWS. Es cómo está construida cualquier plataforma grande, la suya, la de al lado y la que montes tú. Hace dos semanas escribimos lo mismo con otro proveedor y otro síntoma —el portal no cargaba y las operaciones de gestión fallaban durante el incidente de Azure del 30 de septiembre—; la diferencia es que aquí el proveedor lo pone por escrito, con nombres y con horas. La separación entre plano de control y plano de datos es una buena decisión de ingeniería —gracias a ella las máquinas encendidas aguantaron— y, al mismo tiempo, es la razón por la que la pieza de la que depende tu recuperación es la frágil. Si ya leíste el perímetro que tu proveedor ya tiene escrito, esta es la segunda mitad de aquella idea: no basta con saber qué perímetro de daño aguanta tu proveedor; hay que saber qué operaciones te permite hacer mientras lo aguanta.

Las seis preguntas que hacemos a un plan de recuperación

Es lo que marcamos en rojo cuando nos sentamos con un procedimiento de continuidad delante.

• Cuenta los verbos de creación. Subraya en tu procedimiento cada paso que necesita que alguien de fuera te deje crear algo: arrancar, escalar, emitir, provisionar, pedir una IP, abrir un ticket. El número que te sale es la superficie de tu plan que no controlas.
• Mira dónde vive tu identidad de operación. Si para desplegar en Fráncfort tienes que autenticarte contra un servicio global que vive físicamente en otro sitio, ese otro sitio está en tu plan B aunque no aparezca en el diagrama. Aquel lunes STS dio errores y latencia de las 8:51 a las 18:59 de aquí, y AWS escribe que quien usaba credencial raíz o federación de identidad contra signin.aws.amazon.com tuvo errores al entrar en la consola «en regiones fuera de» Virginia del Norte.
• Ten capacidad creada, no por crear. Una máquina encendida y medio vacía en el sitio B cuesta dinero los 365 días y vale exactamente lo que vale el día que nadie te deja arrancar ninguna.
• Frena tus reintentos antes de necesitarlo. Espera creciente y un poco de aleatoriedad en cada cliente que reintenta. No lo arregla nadie a las nueve de la mañana: o está escrito en el código y en los proxies desde antes, o tu recuperación empuja en contra.
• Ten una vía de soporte que no sea la consola. Teléfono, contacto nominal, lo que sea. Si el único camino para abrir una incidencia es la web del proveedor y la web del proveedor está dentro del incidente, no tienes canal.
• Guarda el procedimiento fuera de lo que se cae. Un manual de recuperación que vive en el mismo servicio que estás recuperando es un chiste caro. Lo mismo para el inventario: nosotros lo llevamos en NetBox como fuente de verdad, precisamente para no depender de la memoria de nadie un lunes por la mañana.

Dónde no vale esta lectura

Declaramos el interés antes de la parte incómoda: everyWAN vende infraestructura y cloud, colocation con hierro propio y recuperación ante desastres. Tenemos un incentivo evidente para que esta historia termine en «móntatelo con nosotros». Pues no, no termina ahí.

Montarlo en tu propio hierro no te saca del problema: te lo deja en casa. Tu hipervisor tiene su plano de control, y si el quórum del clúster se rompe no arrancas ninguna máquina nueva aunque las que están corriendo sigan tan contentas; nosotros operamos Proxmox VE con Ceph en producción y esa escena la conocemos. Lo mismo con el directorio, con el DNS interno, con la autoridad que emite tus certificados. La diferencia real no es nube contra hierro: es si la pieza que te deja crear está en una mano, en dos, o en ninguna que puedas tocar. Y, en honor a la verdad, en una caída de tu propio plano de control hay algo que no tienes con un hiperescalar: el teléfono de quien puede arreglarlo.

El informe que puedes leer sigue siendo el de hace un año

La página de resúmenes públicos de incidentes graves de AWS arranca en 2011. Hay dieciocho entradas. El más reciente, a 19 de octubre de 2026, sigue siendo el de aquel lunes: ninguno de 2026 ha entrado todavía en esa página. No lo contamos como reproche —ese documento es bueno, detallado y mucho más de lo que publican otros—, sino como medida de lo raro que es tener un relato técnico de una caída grande. De casi todas las caídas que te afectarán no habrá nunca un informe. Quedará una línea en un panel de estado que desaparece, y lo que tú hayas apuntado mientras pasaba.

El eje de siempre, aplicado aquí: el fallo es inevitable, la avería es una decisión de diseño. Que a un proveedor se le vacíe un registro DNS a las nueve menos doce de un lunes no está en tu mano. Que eso signifique que tu empresa no puede trabajar durante catorce horas sí lo está, y se decide meses antes, cuando alguien escribe el plan B en verbos de creación sin preguntarse quién tiene que darle permiso.

Fuentes y método: todo el relato del incidente, las citas literales y las horas salen del resumen oficial de AWS «Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region» — aws.amazon.com/message/101925. Las horas de ese documento están en hora del Pacífico; la conversión a hora peninsular (nueve horas más, con ambos husos en horario de verano aquella fecha) y los cálculos de duración (2 h 52 min, 14 h 2 min, 14 h 21 min, 14 h 32 min y 28 h 17 min desde las 23:48 PDT del 19 de octubre) son nuestros, y cualquiera puede rehacerlos con las horas del informe. El recuento de dieciocho resúmenes publicados y el hecho de que el más reciente sea el del 19 de octubre de 2025 proceden de la página de resúmenes de AWS, consultada el 19 de octubre de 2026 — aws.amazon.com/premiumsupport/technology/pes. No tuvimos ningún cliente afectado por este incidente ni telemetría propia de aquel día: lo que contamos del caso es lectura de un documento público. Lo que decimos de nuestra forma de trabajar —Proxmox VE con Ceph en producción, NetBox como fuente de verdad del inventario— es nuestro y va sin cifras: no publicamos métricas internas que nadie pueda comprobar.