El incidente que afectó el 20 de octubre de 2025 a Amazon Web Services en la región US-EAST-1 (Virginia) nos ha recordado lo complicado que es mantener la continuidad operativa en infraestructuras globales que gestionan millones de solicitudes por segundo.
Un incidente localizado, pero capaz de generar un efecto dominó a nivel mundial, que ha vuelto a poner en el punto de mira un tema clave: la resiliencia arquitectónica.
Incluso en los entornos más avanzados, el diseño sigue siendo el factor decisivo para garantizar la disponibilidad y la estabilidad de los servicios.

Cronología y causa del accidente

Las primeras anomalías se detectaron al final del día 19 de octubre (hora del Pacífico), y se intensificaron durante las primeras horas del 20 de octubre.
AWS ha identificado el origen del problema en los servicios DNS vinculados a DynamoDB en la región US-EAST-1.

El problema no se limitó a la base de datos, sino que afectó a los servicios que dependen directa o indirectamente de ese mecanismo de resolución.
En cuestión de minutos, los tiempos de espera y los fallos en los controles de estado hicieron que algunos componentes clave del ecosistema de AWS se volvieran inestables, lo que extendió el impacto mucho más allá de la región de origen.

El servicio se fue restableciendo poco a poco durante las horas siguientes, pero algunos clientes siguieron notando retrasos y atascos incluso después de que todo volviera oficialmente a la normalidad.

En resumen, ¿qué ha pasado?

La interrupción se debió a un error en el sistema DNS automatizado de DynamoDB, que generó registros erróneos para el punto de conexión regional.
Esto hizo que el servicio dejara de estar disponible temporalmente y, como DynamoDB es la base de muchos otros servicios de AWS, se produjo un efecto dominó que afectó a EC2, Lambda y Network Load Balancer, con errores de conexión y retrasos en el inicio de nuevas instancias.

El problema se solucionó en unas 15 horas, tras realizar algunas intervenciones manuales en los sistemas DNS y reinicios controlados de los componentes internos.

Arquitectura y resiliencia: el diseño marca la diferencia

El incidente del 20 de octubre ha demostrado que, incluso en la nube, la continuidad de los servicios depende de las decisiones arquitectónicas.
No todos los clientes de AWS se vieron afectados de la misma manera: la diferencia radica en cómo están diseñadas las infraestructuras.

Unos sistemas bien distribuidos, configuraciones multi-AZ y mecanismos de conmutación por error bien configurados te permiten mantener la plena operatividad incluso cuando surgen problemas localizados.

Diseñar para prevenir

Más que hablar de multicloud o de estrategias de redundancia complejas, vale la pena pensar en cómo se diseñan las cargas de trabajo.
El objetivo no es eliminar todos los riesgos, sino minimizar sus efectos, creando entornos capaces de adaptarse y recuperarse rápidamente.

El apagón de octubre dejó algo muy claro: un buen diseño es la mejor protección.
A diferencia de muchas plataformas grandes —como Canva, Snapchat, Coinbase y Roblox—, que sufrieron interrupciones durante el incidente, los clientes de VMEngine, aunque operaban en la región afectada, no sufrieron ningún impacto ni interrupción en sus servicios.

Un resultado que confirma que la resiliencia no es una característica del proveedor, sino de la arquitectura: cuando el diseño es sólido, incluso los imprevistos se pueden absorber sin que haya consecuencias operativas.