Un apagón generalizado en la nube de Amazon Web Services (AWS), que comenzó el lunes por la mañana, mostró la frágil interdependencia que tenemos con el internet: las principales plataformas financieras, de comunicación, sanitarias, educativas y gubernamentales de todo el mundo sufrieron interrupciones.

A medida que avanzaba el día, AWS realizó diagnósticos y comenzó a trabajar para corregir el problema, que se originó en la región crítica US-EAST-1 de la compañía, con sede en el norte de Virginia. Pero la serie de consecuencias tardó tiempo en resolverse por completo. Investigadores que han reflexionado sobre el incidente destacaron la duración de la interrupción, que comenzó alrededor de las 3 de la mañana ET del lunes 20 de octubre. Para las 6:01 de la tarde ET del mismo día, “todos los servicios de AWS volvieron a la normalidad”, según AWS en una actualización de estado.

La interrupción se derivó de las interfaces de programación de aplicaciones de base de datos DynamoDB, de Amazon. Según la compañía, “afectó” a otros 141 servicios de AWS. Varios ingenieros de redes y especialistas en infraestructuras le dijeron a WIRED que los errores son comprensibles, e incluso inevitables, en los llamados “hiperescaladores” como AWS, Microsoft Azure y Google Cloud Platform, dada su complejidad y tamaño. Pero también señalaron que esta realidad no debería absolver a los proveedores de la nube cuando tienen un tiempo de interrupción prolongado.

“La palabra retrospectiva es clave. Es fácil averiguar qué falló después del hecho, pero la confiabilidad general de AWS demuestra lo difícil que es prevenir todos los fallos”, afirma Ira Winkler, director de seguridad de la información de la empresa de fiabilidad y ciberseguridad CYE. “Idealmente, esto será una lección aprendida, y Amazon implementará más medidas que evitarían que un desastre como este ocurra en el futuro, o al menos que permanezcan fuera de servicio tanto tiempo como lo hicieron”.

AWS no respondió a las preguntas de WIRED sobre por qué se tardaron tanto en restablecer el servicio para sus clientes. Un portavoz de AWS dice que la compañía planea publicar uno de sus “resúmenes posteriores al evento” sobre el incidente.

“No creo que se tratara de una simple interrupción de servicio. Yo habría esperado que se reparara mucho más rápido”, dice Jake Williams, vicepresidente de investigación y desarrollo de Hunter Strategy. “Para darles crédito, los fallos en serie no son algo con lo que tengan mucha experiencia porque no tienen interrupciones muy a menudo. Eso es mérito suyo. Pero es muy fácil caer en la tentación de darle a estas empresas un pase gratuito, cuando no debemos olvidar que ellos crean esta situación intentando activamente atraer cada vez más clientes a su infraestructura. Los clientes no controlan si se están excediendo o por qué están pasando financieramente”.

El incidente se debió a algo común en las caídas de la web: los problemas de resolución del “sistema de nombres de dominio” (DNS, por sus siglas en inglés). El DNS es básicamente el sistema de agenda del internet para dirigir los navegadores a los servidores adecuados. Como resultado, los problemas de DNS son una causa común de interrupciones porque pueden causar fallos en las solicitudes e impedir que el contenido cargue.

“La computación en nube es una maravilla, pero su núcleo es una lista interminable de servicios complejos y dependencias que siempre están a una configuración de fallar”, dice Mark St. John, director de operaciones y cofundador de la startup de seguridad de sistemas Neon Cyber.

Hablando de las hiperescalas, St. John estuvo de acuerdo con la opinión de Williams de que, a cambio de la arquitectura y la base de las plataformas de la nube, los clientes ceden el control de su infraestructura digital subyacente y el grado en el que su proveedor de nube invierte (o no) en su capacidad de recuperación y planes de contingencia en un momento dado. “En cierta medida, la validación operativa de los proveedores de servicios no puede ser una casualidad de la reducción de costos”, afirma St. John.