La gran caída de AWS en octubre y sus causas
Durante más de 14 horas, la columna vertebral más crítica de internet se tambaleó bajo el peso de un fallo de DNS. Los días 19 y 20 de octubre, Amazon Web Services (AWS) sufrió una avería en cascada en su región del norte de Virginia (us-east-1), uno de sus centros de datos más grandes y esenciales. La incidencia comenzó a última hora de la noche, pero sus efectos en cadena golpearon desde los lanzamientos de EC2 hasta las invocaciones de Lambda, los servicios de contenedores e incluso el enrutamiento de llamadas de Amazon Connect.
Puedes consultar el informe oficial de AWS aquí. A continuación detallamos lo que ocurrió.
Comenzó con un fallo de DNS
A las 11:48 PM PDT del 19 de octubre, DynamoDB de AWS, la base de datos NoSQL que sostiene innumerables aplicaciones y servicios internos de AWS, empezó a arrojar tasas elevadas de error. En la práctica, eso significaba que todo empezaba a fallar.
El culpable fue una sutil condición de carrera en lo más profundo del sistema automatizado de gestión de DNS de DynamoDB. Imagina a 2 ingenieros intentando editar la misma hoja de cálculo a la vez. Uno termina y guarda, y el otro, trabajando sobre una versión antigua, sobrescribe los cambios. El resultado fue un registro DNS vacío que dejó a DynamoDB fuera de servicio para cualquiera que intentara conectarse mediante su endpoint público.
Podría parecer un contratiempo manejable, pero las consecuencias fueron enormes. DynamoDB es un servicio fundamental, y si tose, todo a su alrededor empieza a asfixiarse.
Cuando la automatización juega una mala pasada
Para entender por qué un fallo de DNS desmoronó la infraestructura, hay que mirar bajo el capó de cómo gestiona AWS sus puntos de enlace. DynamoDB opera miles de balanceadores de carga. Para orquestar todo ese tráfico, AWS confía en un planificador de DNS automatizado (para construir planes) y ejecutores de DNS (para aplicarlos a Route53).
Estos sistemas deberían trabajar en perfecta armonía, pero esa noche un ejecutor se retrasó. Mientras aplicaba lentamente un plan de DNS antiguo, otro ejecutor avanzó a toda velocidad con un plan más nuevo. Ese desajuste temporal provocó que el ejecutor atrasado sobrescribiera el plan más reciente, y después ese mismo plan quedó eliminado durante una limpieza. El endpoint público se desvaneció, el enrutamiento DNS se rompió y miles de aplicaciones se toparon con un muro.
Como el sistema automatizado fijó ese estado defectuoso, el problema fue mucho más allá de una simple mala configuración de DNS, y fue necesaria la intervención humana directa para desenredar el nudo.
El cuello de botella en EC2
Al caer DynamoDB, también fallaron partes de EC2, aunque no por los motivos más previsibles. Las instancias en ejecución siguieron funcionando bien, pero crear instancias nuevas fue otra historia.
El proceso de arranque de nuevas instancias de EC2 depende de un subsistema llamado DWFM (Droplet Workflow Manager). DWFM utiliza DynamoDB para gestionar las concesiones de servidores físicos (droplets). En cuanto el caos de DNS derribó DynamoDB, DWFM no pudo renovar esas concesiones y perdió progresivamente el control sobre la infraestructura.
Cuando AWS recuperó DynamoDB, DWFM se apresuró a restablecer las concesiones, pero la cola acumulada era inmensa y los reintentos agotaban los tiempos de espera. La situación derivó en lo que los ingenieros de AWS denominaron un "colapso congestivo". La solución exigió limitar el tráfico, reiniciar componentes y recurrir a intervenciones manuales clásicas.
Hacia el mediodía del 20 de octubre, la creación de instancias en EC2 estaba prácticamente normalizada, pero los problemas no terminaron ahí.
Los balanceadores de carga perdieron el paso
El servicio Network Load Balancer (NLB) fue el siguiente en caer en el efecto dominó. NLB utiliza comprobaciones de estado para determinar si los destinos del backend (típicamente instancias EC2) están listos para recibir tráfico. El problema fue que esas comprobaciones se ejecutaron antes de que el estado de red de EC2 estuviera totalmente restablecido, por lo que NLB marcó como caídos a destinos perfectamente sanos.
Esto generó un bucle sin fin: las comprobaciones fallaban y se retiraban instancias, luego pasaban la prueba y se volvían a añadir. Ese vaivén saturó el sistema de comprobación de estado y provocó conmutaciones de DNS por error, lo que irónicamente retiró aún más capacidad útil. Varios usuarios vieron cómo su tráfico se desviaba para acabar de nuevo en la misma ruta inestable.
La estabilidad volvió hacia las 9:36 AM, momento en el que AWS desactivó temporalmente la conmutación automática por error.
Lambda, ECS y Redshift: daños colaterales
Los servicios construidos sobre DynamoDB y EC2 también comenzaron a resquebrajarse.
Las funciones Lambda no lograban ejecutarse, los sistemas internos no podían consultar las colas SQS y las fuentes de eventos sufrieron estrangulamiento.
ECS, EKS y Fargate no pudieron arrancar nuevos contenedores, porque EC2 no podía proporcionar la capacidad de cómputo subyacente.
Amazon Connect, la solución de centro de atención en la nube, perdió la capacidad de gestionar chats, llamadas o tareas. Algunos usuarios recibían tono de ocupado y otros solo un silencio sepulcral.
Redshift tuvo dificultades para ejecutar consultas y refrescar nodos del clúster. Las integraciones de IAM fallaron, y la dependencia de EC2 dejó a varios clústeres bloqueados en el limbo.
Incluso la consola de administración de AWS sufrió el caos. Los usuarios de IAM que intentaban iniciar sesión encontraban errores de autenticación y, en ciertos casos, los flujos completos de acceso federado se vinieron abajo.
¿Qué medidas está tomando AWS?
Hay que reconocer que AWS no anduvo con rodeos. Admitió la caída, detalló las causas de raíz y trazó una hoja de ruta para evitar que vuelva a ocurrir. Estos son los cambios en marcha:
- La automatización de DNS de DynamoDB queda desactivada a escala global hasta corregir la condición de carrera e incorporar nuevas salvaguardas.
- El ejecutor de DNS recibirá mayores protecciones para evitar que planes antiguos sobrescriban planes válidos.
- NLB implementará un control de velocidad, básicamente un mecanismo para limitar la rapidez con la que retira capacidad ante fallos en las comprobaciones de estado.
- El DWFM de EC2 se someterá a pruebas de estrés más exigentes y a una lógica mejorada de limitación de colas.
Dicho esto, corregir problemas de automatización se parece a reparar un barco en plena travesía. Además de tapar vías de agua, AWS tiene que rediseñar la forma en que estos servicios esenciales dialogan entre sí a gran escala, y ese equilibrio siempre es delicado.
La perspectiva general
Si esta caída nos ha enseñado algo, es que la nube dista de ser una fuerza invulnerable: funciona como una compleja orquesta de sistemas automatizados donde la nota discordante más pequeña, como una condición de carrera en un ejecutor de DNS, puede desbaratarlo todo.
Para los desarrolladores y las empresas, el incidente es un recordatorio contundente de la necesidad de diseñar pensando tanto en los fallos como en la disponibilidad. Eso exige redundancia en múltiples regiones, mecanismos de degradación elegante y, siempre que sea posible, mecanismos de control humano capaces de anular la automatización cuando las cosas se tuercen.
La caída de AWS en el norte de Virginia no ha sido el mayor incidente en la historia de la nube, pero sí uno de los más reveladores. Dejó al descubierto hasta qué punto está interconectada la infraestructura moderna, expuso las contrapartidas de la automatización y demostró con claridad que hasta los sistemas más robustos pueden tener puntos ciegos.
En cuanto a AWS, tiene una tarea monumental por delante. El futuro de la nube sigue descansando sobre sus hombros, pero durante unas horas de octubre, esos hombros temblaron visiblemente.