Caída de AWS us-east-1: por qué el riesgo de concentración sigue importando
A primera hora de la mañana del 20 de octubre, ingenieros de todo el planeta recibieron la llamada de atención que nadie desea. Sus paneles de monitoreo quedaron planos, las alarmas inundaron Slack (o no sonaron, porque Slack también estaba caído) y el panel de estado de AWS publicó el habitual y vago mensaje de "problema operativo" para la región US-EAST-1. Para entonces, el daño estaba hecho. Servicios esenciales para buena parte de la web moderna estaban fuera de combate y, durante horas, los equipos trataron desesperadamente de comprender lo que ocurría.
El causante fue el DNS, una vez más.
La ironía resulta evidente. Se supone que toda la infraestructura de AWS está diseñada en torno a la alta disponibilidad. Distribuida entre múltiples zonas de disponibilidad (AZ) dentro de cada región, se publicita como resistente por diseño. Sin embargo, cuando US-EAST-1, la región más veterana y grande de Amazon, colapsa de esta forma, saca a relucir algo que la comunidad técnica lleva años comentando: US-EAST-1 concentra mucho más peso que cualquier otra región de AWS.
Cómo un único registro DNS arruinó la fiesta
En el centro del problema estuvo DynamoDB, el motor NoSQL sin servidor de Amazon, que durante un buen rato resultó inaccesible. ¿El motivo? La resolución DNS de dynamodb.us-east-1.amazonaws.com falló por completo. Ese único punto de fallo provocó un efecto dominó, desencadenando caídas en al menos 82 servicios de AWS según los reportes de la comunidad, desde IAM hasta Lambda y EC2.
Tildar esto de simple tropiezo se queda muy corto; fue un golpe directo a la línea de flotación de la arquitectura. La caída de IAM (Identity and Access Management) impidió que otros servicios pudieran:
- Autenticarse
- Orquestar tareas
- Comunicarse entre sí
Sin DNS, los servicios dependientes del descubrimiento dinámico de endpoints simplemente se detuvieron. Si no podías resolver un nombre de host, no podías operar, y reintentar las peticiones una y otra vez no solucionaba nada.
East-1 no es opcional, y ahí radica el problema
AWS defiende la redundancia multirregión como el estándar de oro. No obstante, muchos de sus servicios globales, incluidos los planos de control de Route 53 (su propio servicio de DNS) y de IAM, mantienen un acoplamiento estricto con la región US-EAST-1. Por tanto, aunque tu aplicación esté distribuida entre us-west-2, eu-west-1 o ap-southeast-2, quedarás atrapado si el núcleo de control en us-east-1 deja de responder.
Los usuarios en comunidades de desarrollo lo señalaron de inmediato:
"AWS: para una máxima resiliencia necesitas redundancia en varias regiones. También AWS: muchos de nuestros servicios tienen un plano de control con un único punto de fallo en us-east-1"
Otro bromeaba al respecto:
"us-east-1 lleva años rota. Supongo que simplemente lo admitieron y la apagaron."
Más allá de la ironía, la dependencia sobre esta región concreta es sistémica. Hay quienes apuntan que AWS, al mantener los precios más bajos y las latencias más competitivas en us-east-1, incentiva de forma tácita a que los desarrolladores concentren sus despliegues en una única región, incluso cuando no deberían hacerlo.
Todas las AZ del mundo no te salvarán de un mal diseño
Las zonas de disponibilidad se concibieron para prevenir este tipo de incidencias. Cada AZ dispone de:
- Suministro eléctrico independiente
- Sistemas propios de climatización
- Infraestructura de red separada
La premisa indica que si un meteorito destruye un centro de datos, los demás asumirán la carga. Ese modelo solo responde eficazmente ante fallos físicos.
Cuando el origen es lógico, como una actualización defectuosa de DNS o un despliegue erróneo, poco importa la cantidad de AZ repartidas por el mapa. Si el punto de ruptura reside en el software y se propaga por toda la región, el servicio caerá igualmente. Un comentario lo resumió a la perfección:
"Las AZ reducen el riesgo de fallos físicos. No son inmunes a problemas de software que se despliegan en toda la región."
Eso fue exactamente lo que sucedió. Ya fuera por culpa de la automatización del despliegue, la propagación de una mala configuración o una debilidad en las dependencias, la anomalía no se quedó confinada en una sola AZ. Se extendió rápidamente a lo largo de las seis.
La caída en Slack, DockerHub, Ring y otras plataformas
Los estragos no se limitaron a pequeños desarrollos aislados. Plataformas de enorme envergadura se vieron afectadas:
| Servicio | Impacto |
|---|---|
| Slack | Comunicaciones caídas |
| DockerHub | Registro de contenedores inaccesible |
| Quay.io | Fallos en la descarga de imágenes |
| Datadog | Alertas de monitoreo silenciadas |
| Ring | Cámaras de seguridad fuera de línea |
Los usuarios no podían acceder a la consola de AWS, revisar las cámaras de seguridad ni recibir alertas de monitoreo. Muchos se enteraron de sus propias caídas gracias a que plataformas como Reddit o X seguían operativas.
Surgió además un momento cómico recurrente cuando los usuarios bromeaban: "Siempre es culpa del DNS", seguido de "Imposible que sea el DNS otra vez", para rematar con: "Pues sí, fue el DNS". Los foros parecían un compendio de humor negro y resignación. Se bromeaba con cafés derramados en servidores o arquitecturas embrujadas. Bajo las risas, sin embargo, crecía una desconfianza palpable ante la supuesta resiliencia de la nube.
Qué se debió hacer y qué se puede hacer todavía
AWS no incumplió acuerdos de nivel de servicio (SLA), ya que sus garantías legales contemplan estos márgenes de incidencia. La confianza, en cambio, es otra historia, y se resiente con cada tropiezo.
¿Qué medidas quedan?
Ciertos equipos solventaron el problema con éxito. Varios ingenieros reportaron que sus sistemas ejecutaron el failover de forma limpia hacia us-east-2 u otras regiones gracias a diseños activo-activo o replicación asíncrona. Las Global Tables de DynamoDB, bien configuradas, soportan escrituras multirregión, lo que representó un alivio en mitad del caos. Pero lograrlo exige dedicación, arquitectura reflexiva y una inversión económica considerable.
Ahí reside el dilema. Uno de los comentarios más respaldados lo explicaba con sensatez:
"El coste de hacer que una aplicación sea resistente a caídas regionales no siempre tiene sentido empresarial. Las regiones y los servicios son increíblemente estables, y una gran cantidad de aplicaciones de clientes pueden perder disponibilidad brevemente sin consecuencias graves."
Dicho de otro modo, la tolerancia al riesgo constituye una decisión de negocio. Puedes diseñar para alcanzar redundancia regional, pero para la mayoría de los proyectos todo se reduce a equilibrar costes y beneficios.
Un problema de fondo mucho mayor
Esta caída fue más que una anécdota. Refleja las complejidades de la arquitectura en la nube a gran escala: interdependencias ocultas, planos de control opacos y decisiones acumuladas durante años que terminan creando cuellos de botella inadvertidos.
Supone además un recordatorio de que, por mucho que avancemos en automatización, aprendizaje automático y buenas prácticas nativas de nube, los cimientos siguen importando. El DNS es una tecnología veterana pero indispensable. Si falla, la cadena entera se resiente.
Amazon corregirá esta incidencia. Los servicios ya operan con normalidad y publicarán un análisis postmortem detallado, cargado de terminología técnica y lecciones aprendidas.
La próxima vez que us-east-1 tiemble, y volverá a ocurrir, pregúntate qué aprendiste de la experiencia anterior. La región más demandada de la nube seguirá ahí, pero tu punto único de fallo quizá debería dejar de estarlo.