La fragilidad de Internet

El lunes 20 de octubre de 2025, algo tan sencillo como cargar la SUBE o hacer una transferencia bancaria se volvió imposible. Lo mismo pasó con escuchar música, mandar un mensaje, revisar si un paquete venía en camino, subirse a un avión o leer las noticias. Para millones de personas alrededor del mundo, grandes pedazos de internet no estuvieron disponibles.

Lo que ocurrió no fue ni el Apocalipsis, ni una tormenta solar ni un ciberataque masivo, sino algo así como un metafórico tropezón con un cable: falló una actualización menor en un servicio crítico en la región «us-east-1», un datacenter de Amazon. A medida que una falla se resolvía, las consecuencias aparecían en otros sistemas y el problema se fue propagando en cascada, lo que resultó en unas doce horas de servicios interrumpidos o intermitentes.

El evento fue un nuevo recordatorio de que la promesa de una internet distribuida y resistente es, en la práctica, poco más que una leyenda. Esta interrupción de Amazon Web Services (AWS) no representa únicamente un problema técnico trivial sino lo indefectiblemente dependientes que somos de un oligopolio de infraestructura invisible. Nos tranquiliza hablar de “la nube” porque la mayor parte del tiempo simplemente funciona y salvo que hagamos algo de esfuerzo nada nos remite a que se trata de una demencial estructura de computadoras conectadas a Internet en el galpón de otro.

Una red enchufada a otra red

Internet, en su concepción original, fue diseñada con una desconfianza inherente al control centralizado. ARPANET, su antecesora militar, se construyó para ser resiliente, con múltiples puntos de falla que permitiesen a las comunicaciones “enrutarse alrededor del daño”. Su arquitectura se basaba en la “generatividad”: la capacidad de un sistema para producir cambios imprevistos a través de contribuciones no filtradas de una audiencia amplia y variada, como explica Jonathan Zittrain en The Future of the Internet and How to Stop It (2008). Los creadores de la red abrazaron el “principio de la postergación” y la confianza: no anticipar ni resolver todos los problemas posibles desde el principio, sino confiar en que la comunidad de usuarios los abordaría más adelante. Era un ecosistema diseñado para la sorpresa, no para el control.

Aunque los protocolos fundacionales de la web conservan formalmente sus características descentralizadas, en la práctica, la funcionalidad diaria de internet se apoya en un puñado de empresas y ese ideal anárquico y creativo parece un eco de tiempos remotos. La infraestructura crítica de Internet se concentró al punto de que apenas un tercio de la web no está alojado en servidores de los grandes jugadores: en el mercado del cloud computing AWS controla cerca de un tercio, mientras que Microsoft (con Azure) y Google se reparten casi todo el resto (los hiperescaladores). Nuestro cielo digital tiene apenas tres grandes nubes y luego el resto.

Tres grandes nubes

Esta concentración ya encendió alarmas regulatorias. En el Reino Unido, la Autoridad de Competencia y Mercados (CMA) concluyó en una investigación que el mercado “no está funcionando bien” y analiza designar a Amazon y Microsoft con un “estatus de mercado estratégico” para forzar cambios que impulsen la competencia. Como señala una experta, el evento demuestra la necesidad de un mercado “más abierto e interoperable”, uno donde “ningún proveedor pueda paralizar gran parte de nuestro mundo digital”.

Claro que, de manera mucho menos altruista que la máxima hacker de “resolver tu propio problema” (scratch your own itch), AWS nació a principio de los años 2000 de las entrañas de Amazon, no como un gran plan para dominar la infraestructura mundial, sino como una solución a sus propios y gigantescos problemas logísticos. Para poder manejar la escala de su tienda online, Amazon tuvo que desarrollar soluciones de computación distribuida que realmente no existían a la medida de lo que necesitaban. En el proceso, se dieron cuenta de que la herramienta que habían construido para uso interno era un producto en sí mismo, potencialmente más valioso que la venta de libros o el producto físico que fuera. Y empezaron a alquilarla.

En diez años ya tenían el 30% del incipiente mercado cloud, más que Microsoft, IBM y Google combinados, y sus márgenes de ganancia permitieron subsidiar la expansión del imperio Amazon en su totalidad.

La curva de AWS

El crecimiento de AWS no fue casual. Conviene no romantizar demasiado lo que durante mucho tiempo significó poner en marcha una idea en internet. Se requería hardware caro y conocimientos técnicos complejos. Servicios como los que ofrecen Amazon —y sus competidores— convirtieron esa infraestructura en opciones accesibles, permitiendo pasar de la idea al prototipo y de ahí al producto, con la capacidad de escalar a medida que crece el número de usuarios. Al ofrecer conveniencia y escala sin esfuerzo logró que una parte muy importante de hacer cosas en Internet se volviera casi secundaria entre las preocupaciones.

Esta comodidad en lo inmediato, y lo robusto de su producto, derivaron lentamente en que una gran parte de la infraestructura que en la práctica hace a Internet estuviera concentrada en muy pocos proveedores, haciéndonos olvidar que la capacidad de resiliencia de la red está dada por su posibilidad teórica de estar descentralizada.

Esta centralización no es solo de infraestructura; se replica en el acceso a la información. Para una enorme proporción de los usuarios, Internet es Google, sin exagerar. Esta dependencia de los motores de búsqueda como principal punto de acceso les otorga una influencia considerable como “porteros” (gatekeepers), capaces de priorizar de facto cierta información sobre otra. Esto último es verdaderamente útil pero no por eso debemos dejar de señalarlo.

Del mismo modo que no discamos números de memoria sino que lo hacemos desde la agenda de contactos, muchas veces accedemos a cualquier sitio web mediante una búsqueda.

Una internet mejor

Ahora todo el mundo habla de la web descentralizada —o “Web3”, si es sobre un escenario predicando un internet mejor— como si la web no tuviera en su origen esas mismas ideas. En realidad, se habla de esto desde hace un par de décadas. Pero no queda claro cuál sería el camino para desandar esta centralización. Mudar toda la operación de una empresa de AWS a otro proveedor no es una opción trivial. Es una tarea que nadie querría tener en su lista de pendientes, un vendor lock-in (encierro de proveedor) cimentado tanto en la complejidad técnica como en un costo prohibitivo.

Exactamente tres años antes del apagón de AWS, David Heinemeier Hansson (CTO de Basecamp y creador de Ruby) publicó sus argumentos para “irse de la nube”. La decisión recibió inmensa cobertura y fue celebrada aunque con algo de escepticismo. Solo una empresa con un ejército de ingenieros podría darse el gusto de abandonar la infraestructura de la nube ajena. Pero otra manera de verlo es que si una empresa con intrincados servicios montados en el servidor de otro puede irse de la nube, quizá otros podrían seguirle.

Encierro en la nube

Los argumentos principales de DHH se centraron principalmente en el costo y la complejidad. Alquilar computadoras no siempre es negocio por los márgenes que se pagan para asegurar el servicio durante picos de uso que en realidad nunca experimentan. Casi un 30% de lo que gana Amazon es por esta aseguración. Por otro lado, la menor complejidad operativa nunca se cumplió: operar un servicio importante en la nube nunca es verdaderamente tan simple. Finalmente, DHH menciona la preocupación por el futuro de internet y la tragedia de que esta “maravilla descentralizada” esté ahora operando en gran medida en máquinas propiedad de unas pocas grandes corporaciones, con la posible consecuencia de exactamente lo que pasó hace unos días.

“El marketing de la nube convenció a una generación de programadores de que lo más aterrador del mundo era conectar su propio servidor a Internet. Todo para que pudieran venderse y revenderse las mismas dependencias centralizadas con enormes márgenes”, tuiteó DHH hace unos días.

Este encierro tiene consecuencias más allá de lo comercial. La infraestructura que sustenta no solo al discurso democrático, los medios y las comunicaciones seguras, sino también a empresas logísticas e infraestructura pública, no debería depender de dos o tres empresas. Cuando un proveedor de la escala de AWS se apaga, no solo se caen los videojuegos y las redes sociales; también se vuelven inaccesibles servicios esenciales. Al elegir la comodidad a expensas de la libertad, escapando de la complejidad de la autogestión, el “internet abierto” pasó a apoyarse sobre una base cerrada, que otorga a proveedores como Amazon, Google y Microsoft un poder unilateral sobre el acceso a la información y una gran variedad de servicios críticos.

La nube no existe

La solución a largo plazo no es simplemente exigir más redundancia o contratar dos servicios de nube en lugar de uno. Eso es tratar el síntoma, no la enfermedad. La verdadera resiliencia exige un cambio fundamental en cómo concebimos nuestra infraestructura digital.

Quizá la decisión de depositar tantas funciones críticas de nuestras soluciones digitales en un puñado de proveedores no deba ser una cuestión meramente técnica sino una sujeta a consideraciones más profundas. La nube no existe, es la computadora de alguien más. Y todo esto, que transcurre sobre el mismo plano terrenal, tiene consecuencias bien concretas.

Desde 2022, Amazon despidió a más de 27.000 empleados, incluyendo ingenieros senior con décadas de experiencia. La sospecha es que la lentitud para resolver la crisis —casi una hora y media para identificar que el problema era de DNS, un culpable tan frecuente que tiene su propio haiku: “No es el DNS / imposible que sea DNS / pero era DNS”— se debe a una fuga de conocimiento institucional. Como sugirió un experto, se puede contratar gente muy inteligente que entienda la teoría, pero no se puede contratar a la persona que recuerda que cuando el DNS se pone caprichoso, hay que revisar aquel sistema aparentemente inconexo en un rincón que ya causó problemas en el pasado. Ese “conocimiento tribal”, esa memoria muscular de una organización, se fue con los despidos.

Internet debía seguir funcionando aunque cayeran bombas… pero se cayó el DNS.

Otras lecturas: