Dos caídas por configuración, con un año de diferencia: CloudFront y 1.1.1.1
El jueves pasado, 16 de julio, AWS CloudFront empezó a devolver errores 5xx en cualquier distribución que usara VPC Origins, y siguió haciéndolo de 07:45 a 11:18 UTC: tres horas y treinta y tres minutos. AWS situó la causa raíz en «una restricción interna en la flota que gestiona las conexiones a orígenes privados de VPC», que dejó a esa flota sin poder cargar su configuración de red actualizada. 1 Las distribuciones con otros tipos de origen no se vieron afectadas, pero CloudFront está delante de tanta parte de internet que el fallo de una sola función rompió o degradó servicios como Canvas, Blackboard, Hugging Face y Ubiquiti. 2
Dos días antes, el 14 de julio, pasó casi inadvertido el primer aniversario de un fallo de la misma forma. En 2025, el resolutor DNS público de Cloudflare 1.1.1.1 desapareció durante 62 minutos. A principios de junio, un servicio de preproducción de Data Localization Suite había quedado asociado por error a los prefijos de 1.1.1.1, y el error se quedó ahí, latente, hasta que un segundo cambio añadió una ubicación de pruebas fuera de línea y disparó una actualización global de configuración, retirando esos prefijos de todos los centros de datos de Cloudflare a la vez. Pese a las especulaciones de entonces, no fue un secuestro de BGP. El análisis de Cloudflare es explícito: las rutas las retiró su propia automatización. 3
No se cortó ninguna fibra. No ardió ningún centro de datos. En ambos casos las máquinas estaban bien y las instrucciones estaban mal.
Ahora la parte frágil es el plano de control
Este año hemos escrito sobre fallos físicos: los sucesos de AWS en Oriente Medio en marzo, el corte de fibra de Zayo que degradó media web el 22 de junio, los cables submarinos en general. Son fáciles de entender y, de forma extraña, hasta tranquilizan. Un cable es una cosa, y las cosas se pueden duplicar.
Con la distribución de configuración es más difícil, y por razones estructurales, no por falta de competencia.
Es global por diseño. Todo el valor de un plano de configuración distribuido está en que un cambio llegue rápido a todas partes, que es exactamente la propiedad que hace que un mal cambio llegue rápido a todas partes.
Y es además el camino de recuperación. Si tu sistema de configuración está enfermo, el mecanismo con el que normalmente arreglarías las cosas es el que está roto. La redundancia física no ayuda aquí: tienes muchos servidores sanos, todos haciendo obedientemente lo equivocado.
Y no tiene una frontera natural de radio de impacto. Las regiones y las zonas de disponibilidad acotan el fallo físico. Una sola flota dentro de CloudFront no pudo cargar una configuración, y los errores fueron mundiales. Un despliegue de configuración no respeta esas fronteras salvo que alguien lo haya diseñado así, y el despliegue por fases es esa clase de disciplina que se erosiona en silencio bajo presión de plazos.
Con el DNS es la misma historia una capa más arriba. Retirar una ruta es una afirmación de configuración. El resolutor estaba sano; dejó de ser alcanzable porque a la red se le dijo que no estaba ahí.
Cinco hábitos que vale la pena copiar
Lo incómodo es que hablamos de dos de las organizaciones operativamente más maduras de internet. Si la configuración distribuida les muerde a ellas, el Ansible de un equipo normal un viernes a las cinco de la tarde no es más seguro.
Despliega todo por fases, la configuración incluida. Si un cambio llega al 100 % de tu flota a la vez, tu radio de impacto es global por muchas regiones que tengas.
Ten un camino de recuperación que no pase por el plano de configuración: consola, un plan B estático, un archivo editable a mano; algo que funcione cuando la automatización no funciona.
No compres tu DNS autoritativo al mismo proveedor detrás del que escondes tu origen. Cuando ese fabricante tenga un mal día, te quitará de un golpe el problema y también tu capacidad de rodearlo.
Configura un segundo resolutor recursivo, público e interno. Julio de 2025 es el mejor argumento: un resolutor puede estar perfectamente sano y aun así ser inalcanzable, un segundo no cuesta nada, y si falla la resolución de nombres da igual todo lo demás que hayas construido.
Y conoce tu tiempo de reversión, medido y no estimado. «Podemos hacer rollback» no es un plan hasta que alguien lo ha cronometrado.
Una entrada para cuando la automatización falla
Somos un proveedor pequeño y no vamos a fingir que nuestro plano de configuración es más sofisticado que el de Cloudflare. Es más pequeño, lo que cambia los equilibrios en vez de resolverlos, y de vez en cuando juega a nuestro favor: menos piezas móviles y menos sitios por donde un despliegue global se vuelva realmente global.
Lo que damos a los clientes es lo que importa durante una caída de esta forma: una entrada que no depende de que nuestra automatización esté sana.
Todos los VPS y VDS de nuestro catálogo actual tienen consola noVNC desde el área de cliente, independiente de la red del propio sistema invitado. Cuando la configuración de red está mal, el cortafuegos te ha dejado fuera o la máquina no termina de arrancar, tienes una pantalla y un teclado. Sin SSH, sin ticket y sin enviarle una credencial a nadie.
KVM completo con acceso root significa que recuperas la máquina tú mismo, sin esperar a que un proveedor publique un arreglo en un panel que no puedes esquivar. Y el looking glass te deja comprobar nuestro enrutamiento con tus propios ojos, desde Tirana, Skopie, Ámsterdam y Dublín, en lugar de creerte una página de estado.
Y está el consejo de siempre, que repetimos porque sigue siendo útil. Pon un VPS de 5 €/mes en un sitio que no comparta plano de control con tu proveedor principal. No otra región del mismo proveedor, sino otro proveedor en otro país. Los dos días de los que hablamos, esa máquina habría sido la que todavía podía contarles a tus usuarios qué estaba pasando.
La tendencia que conviene vigilar
Casi todas las noticias de caídas de este año han sido físicas: el suceso de AWS en Oriente Medio en marzo, el corte de fibra de Zayo en junio. La del jueves no fue ni lo uno ni lo otro, y tampoco lo fue aquella cuyo aniversario casi compartió. El sector lleva veinte años aprendiendo a sobrevivir a los fallos de hardware, y ha dedicado bastante menos esfuerzo a sobrevivir a sus propias instrucciones.
Cada vez más, un sistema distribuido bien diseñado no falla rompiéndose. Falla funcionando a la perfección, en todas partes, sobre la entrada equivocada.