Cuando la nube falla: cómo una caída de AWS tumbó medio internet

Alrededor de la medianoche, hora del Pacífico, el 20 de octubre, internet empezó a comportarse de forma extraña. Amazon no cargaba y Mercado Livre, el gigante brasileño del comercio electrónico, sufría fallos. Duolingo se colgó a mitad de una lección, los jugadores de Fortnite fueron expulsados en plena partida, los mensajes de Slack dejaron de enviarse y PagerDuty no envió alertas.

Lo que empezó como un momento de "vaya, quizá sea mi Wi-Fi" escaló rápidamente a una caída total de AWS, otra vez. Como un efecto dominó digital, aplicaciones, juegos, herramientas y sitios web de todo el mundo empezaron a apagarse, y todas las señales apuntaban a un sospechoso conocido: us-east-1.

Una región para dominarlos a todos

Amazon Web Services (AWS) es la columna vertebral invisible de gran parte de internet. Su región us-east-1 en el norte de Virginia es uno de sus centros de datos más antiguos y grandes, y también el centro neurálgico de muchos servicios globales. Cuando tropieza, una parte enorme de internet cae de golpe con ella, y eso es exactamente lo que ocurrió.

Según el propio panel de estado de AWS, el problema comenzó con "un aumento en las tasas de error y latencias" que afectó a un amplio abanico de servicios, incluidos CloudFront, EC2, DynamoDB, Kinesis, SageMaker y más. Siguió una cascada de incidencias que afectó al acceso a aplicaciones, transacciones e incluso servicios internos como Amazon.com y Audible. En otras palabras, la nube se rompió, y cuando AWS flaquea, se lleva por delante a una parte considerable del mundo digital.

"¿Quién más está de guardia? ¡Vamos allá!"

La caída golpeó al sector tecnológico como un tren de mercancías. Los ingenieros de DevOps se pusieron en marcha y las rotaciones de guardia se activaron de inmediato. De forma irónica, los sistemas de monitoreo como PagerDuty también sufrieron por la caída, dejando a algunos equipos a ciegas. Un usuario bromeaba: "Menos mal que AWS no usa PagerDuty", mientras otro señalaba con resignación: "¡500 tickets sev-2 ya, y sigue subiendo!".

Slack se llenó de mensajes y luego también se congeló para algunos usuarios. Jira estaba caído, los servicios de Autodesk no respondían y los portales bancarios en Brasil y Australia daban errores. OnlyFans, la app del Monopoly de McDonald's, Clash Royale e incluso Tidal mostraron algún tipo de problema, junto con prácticamente todo lo que se apoya en AWS. Alguien comentó: "Solo quería jugar a Fortnite y llevaba 30 bajas. RIP".

Fue una interrupción surrealista que atravesó múltiples sectores y dejó al descubierto hasta qué punto está centralizado el internet moderno.

El punto único de fallo del que nadie quiere hablar

Si algo dejó claro esta caída, es que hemos creado un mundo digital que depende en exceso de unos pocos proveedores de nube importantes, y a veces de una única región.

us-east-1 se ha vuelto tristemente célebre. Es donde van a parar muchos despliegues por defecto, y alberga planos de control para servicios que abarcan varias regiones. Por eso, cuando se satura, los planes de redundancia que parecen sólidos sobre el papel fallan en la práctica. "Los problemas de IAM afectarán a todas las regiones", señaló un usuario, destacando cómo los servicios centrales de identidad y acceso, a menudo alojados allí, pueden propagar fallos por sistemas supuestamente aislados.

Un comentario lo resumió a la perfección: "Esto es lo que pasa cuando centralizamos internet".

¿Fue un ciberataque?

Con Fortnite, Apex Legends y Epic Games afectados, la comunidad de jugadores enseguida arqueó las cejas. ¿Era un ciberataque? AWS no afirmó tal cosa, al menos en sus comunicaciones iniciales. Se limitaron a frases ambiguas como "investigando el aumento en las tasas de error".

Aun así, cuando una columna vertebral de la red global tambalea, los rumores se disparan. Hubo quien lo comparó con el sonado desastre de la actualización de CrowdStrike, y otros especularon con un despliegue defectuoso o un descuido interno. Una broma no tardó en circular: "Hola, acabo de empezar en AWS y vi un fallo en el clúster de DynamoDB. Lo arreglé y lo subí a producción antes de llevar a los niños al colegio. ¡Vuelvo pronto!".

El lado humano de la caída

Más allá del contexto técnico, los momentos más reveladores llegaron de personas reales lidiando con consecuencias reales:

• Un empleado público comentó con ironía que sus recursos empresariales basados en AWS estaban fuera de combate, pero bueno, estaba con permiso de empleo temporal, así que se encogió de hombros.
• Otro usuario en Polonia intentó entrar a Autodesk Fusion para hacer modelado 3D y solo recibió una tanda de errores: "Bing bong, no se puede iniciar sesión".
• Un estudiante universitario de Phoenix perdió dos plazos de entrega de trabajos porque sus herramientas habituales estaban fuera de línea.

Otros aprovecharon el momento con picardía. "Nadie está ganando premios en la app de McDonald's ahora mismo", se dio cuenta alguien. Otro usuario se lanzó y consiguió una tarjeta de regalo de $50 de DoorDash en cuanto los servidores volvieron parcialmente. Hubo caos, comedia y gestión de crisis a partes iguales.

Y ahora... ¿qué?

AWS terminó por mitigar el problema en unas pocas horas. Para muchos usuarios, eso significó que todo comenzó a revivir poco a poco durante la madrugada. Pero las preguntas siguen en el aire. ¿Por qué seguimos diseñando arquitecturas basadas en una sola región de la nube? ¿Por qué no hay más empresas adoptando estrategias de failover multirregión o incluso multinube?

Porque es complejo. Mantener réplicas activas entre regiones no es barato, y enrutar el tráfico cuando hay caídas exige una infraestructura que pocas empresas justifican cuando la nube "solo" falla una vez cada par de años. Como señaló un comentario: "Suena genial para los 34 minutos al año en los que te afecta... pero no tanto para los otros 364 días en los que te pasas de presupuesto".

La ilusión de la invencibilidad

AWS presume de disponibilidad: 99.99999% de tiempo de actividad y múltiples capas de redundancia. Sin embargo, una y otra vez vemos lo frágil que resulta la infraestructura cuando una pieza falla.

Un comentario sarcástico reflejó muy bien el ambiente: "Sí, nos lo venden como si fuera invencible, mientras que las demás nubes parecen atadas con alambre. Pero yo ni siquiera puedo silenciar mi cámara Ring".

Aun así, AWS no es toda la historia. El problema de fondo es nuestro exceso de confianza colectivo en la resiliencia de la nube y la costumbre de poner demasiados huevos en la misma cesta virtual.

Conclusiones, si alguien está escuchando

1. Diversifica tu infraestructura si puedes. En serio.
2. No des por hecho que las opciones por defecto (como desplegar en us-east-1) son seguras solo por ser populares.
3. Diseña estrategias de DR que tengan en cuenta el factor humano. Ten claro qué falla y quién debe enterarse.
4. Si estás de guardia, haz acopio de provisiones.

La caída fue una llamada de atención precisamente por lo cotidiana que resultó, pese a no ser catastrófica. Ocurrió de noche, en una ventana de despliegue rutinaria, y se resolvió en horas. Pero en esa pequeña ventana dejó a oscuras a millones de usuarios, muchos de los cuales ni siquiera sabían que AWS estaba detrás de sus aplicaciones hasta que todo falló. Cuando la nube cae, todos sufrimos la tormenta.