En los últimos días, el mundo digital ha vuelto a temblar. Una nueva incidencia en la infraestructura de Amazon Web Services (AWS) —el proveedor de servicios en la nube más utilizado del planeta— provocó una caída parcial que, aunque se originó en una región de Estados Unidos, terminó afectando servicios y aplicaciones en todo el mundo.
¿El origen del problema? Como dice el dicho entre los profesionales de la red, “it’s always DNS”.
En este caso, no era solo una broma: errores y latencias de red del sistema de resolución DNS fueron el primer efecto de una cadena que fue degradando servicios críticos dentro de la propia infraestructura de AWS. El mal funcionamiento inicial impactó en DynamoDB, y a partir de ahí se vieron afectados servicios “core” como IAM (Identity and Access Management), responsable de la autenticación y gestión de identidades, y otras API’s de control. Cuando IAM o las API’s de control caen, todo lo que depende de credenciales, permisos o elementos globales de configuración deja de funcionar: API internas, consolas de administración y servicios esenciales que sustentan cientos de miles de aplicaciones a nivel global.
El resultado fue una cascada de interrupciones que llegó mucho más allá del ámbito técnico. Plataformas de comercio electrónico, servicios de streaming, aplicaciones corporativas e incluso dispositivos domóticos quedaron inoperativos.
La dependencia de los grandes proveedores de la nube
Esta incidencia nos invita a reflexionar sobre una realidad a menudo ignorada: la concentración de poder tecnológico en pocas manos y la importancia de diseñar servicios cloud más resilientes e independientes. Hoy en día, gran parte de Internet —tanto a nivel de empresas como de usuarios finales— descansa sobre los servicios de AWS, Google Cloud o Microsoft Azure. Esta concentración facilita la escala y la innovación, pero también genera un riesgo sistémico: cuando uno de estos proveedores tiene un problema, el impacto se propaga de manera global e inmediata.
Muchas organizaciones han apostado por migrar a la nube para mejorar la disponibilidad y reducir la complejidad de su infraestructura. Sin embargo, esta transición a menudo se ha hecho sin valorar suficientemente la dependencia directa que se adquiere del proveedor. Cuando todo nuestro negocio depende de un único entorno, una simple falla externa puede detener procesos críticos sin que tengamos capacidad de actuar.
Esta caída ha sido un buen recordatorio de hasta qué punto hemos cedido el control a estos gigantes. Y no solo las empresas: incluso la domótica de nuestro hogar —con Alexa a la cabeza— depende de un servidor a miles de kilómetros. En algunos casos, los usuarios informaban que no podían detener el despertador, encender las luces o abrir las puertas inteligentes de sus casas. Una situación que, aunque anecdótica, ilustra hasta qué punto nuestra vida digital y cotidiana depende de una infraestructura gestionada por unos pocos actores globales.
La redundancia no es sinónimo de resiliencia
AWS dispone de una arquitectura altamente redundante: múltiples zonas de disponibilidad (AZ), regiones geográficamente distribuidas y una larga lista de mecanismos de tolerancia a errores. Aun así, esta incidencia ha demostrado que la redundancia por sí sola no garantiza la resiliencia.
El problema no va ser que fallessin els servidors o les regions, sinó que un component centralitzat, com IAM, es va convertir en el punt únic de fallada. Quan un servei essencial per a l’autenticació deixa de funcionar, la resta de la infraestructura pot quedar paralitzada, encara que les instàncies físiques o les bases de dades estiguin disponibles. És una lliçó clàssica en arquitectura distribuïda: no n’hi ha prou amb tenir còpies o rèpliques, cal dissenyar sistemes que puguin funcionar de manera autònoma o degradada quan els serveis centrals fallen.
Este episodio refuerza la importancia de pensar la resiliencia más allá de la infraestructura. Es decir, no solo duplicar recursos, sino también evitar dependencias excesivas de componentes únicos, especialmente en ámbitos como la identidad, la seguridad o la gestión de configuraciones globales.
Hacia un modelo de responsabilidad compartida más real
Otro aspecto que a menudo se pasa por alto es el concepto de responsabilidad compartida. Proveedores como AWS aseguran la disponibilidad de su infraestructura, pero la responsabilidad de asegurar la continuidad de los servicios propios recae en el cliente. En otras palabras: la nube puede fallar, y es tarea de cada empresa estar preparada para que eso no conlleve una parada total.
Esto implica repensar cómo se diseñan y despliegan las aplicaciones:
- Implementar estrategias multi-región o multi-nube allí donde tenga sentido.
- Garantizar que los sistemas críticos puedan funcionar, al menos parcialmente, sin dependencias externas inmediatas.
- Automatizar la detección y recuperación de errores.
- Y sobre todo, probar regularmente estos mecanismos —no solo confiar en que la redundancia hará su magia.
Un factor a menudo ignorado: el talento humano detrás de la infraestructura
Más allá de la tecnología, hay otro elemento que debe considerarse: las personas que mantienen la nube en funcionamiento.
En los últimos años, Amazon ha vivido una ola de cambios internos que no ha dejado indemne a su división de servicios en la nube. Desde 2022 hasta 2024, más de 27.000 empleados de la compañía se han visto afectados por despidos, y todavía hoy el proceso continúa. Aunque no se sabe con precisión qué parte corresponde a AWS, es evidente que esta reducción de plantilla ha impactado en equipos clave de desarrollo y operaciones.
Además, según informes internos filtrados, Amazon ha registrado entre un 69 % y un 81 % de profesionales que se marchan y que la empresa hubiera querido retener. Esta pérdida de talento se ha visto agravada por las tensiones internas asociadas al regreso al trabajo presencial, una política que muchos empleados —especialmente perfiles técnicos y de alto nivel— han percibido como una medida poco flexible y desconectada de la realidad del sector.
El resultado es un ecosistema donde la presión operativa aumenta mientras el conocimiento interno se diluye. En una infraestructura tan compleja e interdependiente como la de AWS, la pérdida de experiencia y cohesión puede acabar traduciéndose en mayor riesgo de incidencias, tiempos de respuesta más lentos y, en definitiva, un descenso de la resiliencia global del sistema.
Hasta qué punto esto ha afectado a la prevención o a la capacidad de reacción de este incidente concreto lo desconocemos, pero es un factor a tener en cuenta.
Una oportunidad para repensar nuestra arquitectura
Este tipo de incidentes son inevitables, pero también una oportunidad para aprender y mejorar. En nuestra empresa, nos recuerda la importancia de construir infraestructuras robustas, observables y con planes de recuperación reales, no teóricos.
Porque, al final, la nube no es un concepto abstracto: son servidores, protocolos y personas que trabajan para mantenerla en marcha. Y como todo sistema complejo, puede fallar. La diferencia entre un servicio que cae y un servicio que sobrevive está en lo inteligentemente que ha sido diseñado —y también en lo bien cuidado que está el talento que lo sustenta.
La reciente caída de AWS es un recordatorio de que la tecnología que sostiene nuestro día a día es tan poderosa como frágil. Nos obliga a replantearnos nuestra confianza en los grandes proveedores y a redoblar los esfuerzos para diseñar arquitecturas realmente resilientes.
Por mucho que la nube prometa disponibilidad infinita, la resiliencia sigue siendo una responsabilidad compartida —tanto técnica como humana.
Y, como siempre, cuando algo falla… bueno, ya lo sabemos: “it’s always DNS”.
