Quince Horas de Internet Roto: Lo que el Apagón de AWS de Octubre de 2025 Reveló sobre Vivir en una Sola Región de la Nube

A las 3:11 de la madrugada, hora del este de Estados Unidos, del 20 de octubre de 2025, algo dejó de resolver correctamente un nombre de dominio dentro de un solo centro de datos de Amazon Web Services en el norte de Virginia. Fue, según reportes posteriores, una actualización técnica mal ejecutada sobre el sistema de nombres de dominio que usa DynamoDB, una de las bases de datos internas más utilizadas de AWS. Ese fallo, contenido en principio a un servicio interno de una sola región llamada us-east-1, terminó arrastrando durante las siguientes quince horas a Snapchat, Fortnite, Roblox, Alexa, las cámaras Ring, la aplicación de McDonald's, Coinbase, Robinhood y Perplexity, entre cientos de servicios más.

Le pregunté a un arquitecto de infraestructura que trabajaba esa madrugada en el equipo de operaciones de una empresa de pagos digitales cómo se enteraron del problema. "Lo primero que notamos fue que no podíamos hacer login en nuestra propia consola de AWS," me contó. "Ahí entendimos que no era nuestro código. Era la nube completa, la que se supone que nunca se cae."

Para la tarde de ese mismo día, los rastreadores de caídas habían acumulado más de 6,5 millones de reportes de usuarios, y se calculó que más de mil empresas quedaron afectadas de una u otra forma. No fue un servicio menor el que falló: us-east-1 es, desde hace más de una década, la región más antigua y más usada de toda la infraestructura de AWS, y buena parte de internet la trata, sin decirlo en voz alta, como si fuera la única región que existe.

El giro: la empresa que nadie notó porque siguió funcionando

Mientras medio internet reportaba pantallas en blanco, una empresa de autenticación de identidad llamada Authress no apareció en ningún titular de esa mañana. No porque el problema no la tocara: sus sistemas también dependían de servicios alojados en us-east-1. La diferencia fue que, meses antes, el equipo de Authress había diseñado su arquitectura para operar en varias regiones al mismo tiempo, con un enrutamiento de conmutación por error que no necesitaba intervención humana para activarse, y había reducido al mínimo su dependencia de los servicios de plano de control de AWS, esos que gestionan la configuración interna y que fueron justamente los más golpeados esa madrugada. Cuando us-east-1 empezó a fallar, el tráfico de Authress simplemente se movió a otra región, y la empresa mantuvo el nivel de servicio prometido a sus clientes durante toda la interrupción.

Algo parecido les pasó a los clientes de la plataforma Temporal que ya tenían replicación multi-región o multi-nube configurada de antemano: sus cargas de trabajo evacuaron us-east-1 de forma automática, y equipos como el de la empresa FireHydrant solo tuvieron que aumentar la capacidad de procesamiento en la región de respaldo para seguir operando con normalidad, sin ninguna decisión de emergencia de por medio.

Piénsalo un momento: la diferencia entre pasar la mañana apagando incendios y no aparecer en ningún reporte de caída no fue el tamaño de la empresa, ni su presupuesto de tecnología. Fue una decisión de arquitectura tomada con calma, meses antes, cuando nadie estaba mirando y todo funcionaba bien.

Por qué la mayoría de las empresas descubren su dependencia de una sola región el día que falla

La gran mayoría de las organizaciones que usan la nube pública operan, sin haberlo decidido de forma explícita, en una sola región. No es negligencia pura: multiplicar regiones cuesta dinero, complica el despliegue y exige mantener sincronizados datos que antes vivían en un solo lugar. El problema es que esa decisión de ahorro casi nunca se documenta como un riesgo aceptado conscientemente. Se convierte, con el tiempo, en un supuesto invisible: "la nube no se cae", hasta que se cae.

Las organizaciones que dependían de procesos manuales de conmutación por error tardaron, en promedio, entre dos y cuatro horas solo en confirmar qué tan grave era el problema, y otras una o dos horas más en ejecutar el cambio de región. Eso significa entre tres y seis horas de interrupción que, con automatización previa, se hubieran resuelto en minutos.

Hay preguntas concretas que cualquier equipo de tecnología puede responder esta misma semana, sin esperar el próximo apagón:

Verificar si la aplicación crítica del negocio depende de una sola región de un solo proveedor de nube, y si esa dependencia fue una decisión documentada o simplemente un hábito heredado del primer despliegue.

Probar, en un ejercicio programado y no durante una crisis real, cuánto tiempo toma mover el tráfico a una región secundaria, y si ese movimiento requiere que una persona específica esté despierta y disponible para ejecutarlo.

Identificar qué servicios de plano de control del proveedor (los que gestionan configuración, identidad y enrutamiento, no el procesamiento en sí) representan un punto único de falla, porque suelen ser los primeros en fallar y los últimos en visibilizarse en un diagnóstico rápido.

Mantener, para los procesos verdaderamente críticos, una vía de respaldo fuera del proveedor principal, aunque sea a menor escala, para no depender por completo de que un solo proveedor resuelva su propio incidente a tiempo.

Ninguno de estos pasos exige abandonar la nube ni duplicar el presupuesto de tecnología de un día para otro. Exige tratar la disponibilidad de una sola región como lo que realmente es: una apuesta, no una garantía.

El cierre

Amazon restableció el servicio la tarde de ese 20 de octubre, y para el día siguiente la mayoría de las aplicaciones afectadas ya operaban con normalidad. Lo que no volvió a la normalidad fue la sensación, dentro de muchos equipos de tecnología, de que "la nube" era un concepto único y siempre disponible. El arquitecto de infraestructura que me contó su versión de esa madrugada lo dijo de una forma que se quedó conmigo: "Pasamos quince horas recordando que la nube de otra persona sigue siendo un edificio con servidores adentro, con un solo interruptor de luz."