Ayer vivimos un momento marcado, no en la historia, pero sí en el año. Todos los medios genéricos y profesionales daban la bienvenida a la semana con la supuesta caída global de Amazon Web Services, cientos de servicios caídos, desde bancos hasta videojuegos, una catástrofe, el armagedón digital, gente corriendo en círculos en fuego como el GIF de Bob Esponja. Muchos ingenieros se llevaban las manos a la cabeza y se tiraban de unos pelos que probablemente no tuvieran desde hacía décadas mientras otros se alzaban predicando que la nube pública era el demonio. ¿Y qué hacía yo? os preguntaréis con voz de narrador. Reportar al equipo de sistemas, revisar la consola de salud de AWS para comprobar las actualizaciones y tomar un café. Más tranquilidad de la que os imagináis. Y es que, en nuestro caso, el negocio no se vio afectado. Y no porque tenemos lo más top y somos los amos, sino porque la caída global no fue global.

El incidente del 20 de Octubre del 2025#

A las 12:11 hora del Pacífico, AWS detectó fallos con DynamoDB en la región de Virginia del Norte y a partir de ahí fue todo una reacción en cadena. En concreto, la resolución DNS interna del servicio era erronea. Hasta las 15:53 no se dio la incidencia por resuelta pero, a diferencia de otros casos, aquí ese servicio es más crítico de lo que parece.

DynamoDB es una base de datos No-SQL y sin servidor, es decir un Platform as a Service. Como tal, ciertas responsabilidades recaen en Amazon, como el sistema operativo, la infraestructura y el acceso a los datos. Otros puntos, como el versionado, las réplicas y la resiliencia, recaen en el cliente.

Ahora bien, uno de los principales clientes de Amazon es el propio Amazon, y no solo me refiero en la web de compras, también AWS. DynamoDB almacena los permisos IAM, la información de los Health Checks de ELB, las etiquetas de EC2… esto amplía la seriedad. Peor lo ponen si algunos servicios globales también usan el DynamoDB… de Virginia.

La afectación real#

Según Amazon (y la experiencia propia), solo fallaban cosas muy concretas. Por ejemplo, las instancias EC2 seguían funcionando con total normalidad, pero visualizar sus IPs (se almacenan internamente en una DynamoDB) fallaba. Esto implica cositas, crear una instancia implica añadir datos a una tabla en el backend, por lo que generará error. Podemos preocuparnos más si miramos EKS, el servicio de Kubernetes de AWS, pues monitoriza los balanceadores para asegurar el funcionamiento y crea nuevas instancias, prácticamente el servicio implosiona. RDS y ECS también crean máquinas para funcionar, así que podían dejar de operar solo si aplicaban un cambio de infraestructura. IAM solo fallaba si los endpoints usaban Virginia, Organizations si intentabas actualizar una política… Un caos todo.

Por qué se dice que es global#

El usuario de a pie vive feliz sin saber nada de AWS ni de arquitectura en la nube (qué envidia). Cuando algo falla, no puede ver más allá que el fallo y lo que dicen los medios. Medios que generalmente son llevados por periodistas, no informáticos. Pensemos con lógica. Si veo que no va Fortnite, no va mi banco en España, no va Netflix en USA… pues tiene pinta de ser global, sí. Pero si no lo fue, ¿por qué parecía? La respuesta es simple:

Virginia del Norte es el cerebro de todo AWS. Los servicios globales tienen su procesamiento ahí (entonces no son tan globales) aunque luego tengan algunas cosas en otros lugares. También es la región por defecto para la creación de recursos, la más barata y la más potente para algunos servicios de la antigua capa gratuita.

Conclusiones#

Es habitual que muchas empresas desplieguen sus recursos ahí, por falta de planificación, ahorro de costes o miles de razones. Lo que no es normal, y no es por desprestigiar a los equipos técnicos, es que grandes empresas pongan los huevos en la misma cesta. Más preocupante me parece en las empresas que, por seguridad nacional, regulación o soberanía del dato, deberían mantener todo su proceso en Europa, como es el caso de la banca.

A diferencia de los centros de datos propios, la redundancia de regiones en las nubes públicas es algo relativamente sencillo de lograr. Aun así, no van a cambiar. Fallos así ocurren cada mucho tiempo, y estos caos suele quedar en el olvido al poco al ver los cambios que hay que hacer en las arquitecturas ya existentes, aunque en algunos casos pueda replantear las futuras.

Por parte de Amazon espero que lo consideren como un tirón de orejas. Poco sentido tienen las regiones y zonas de disponibilidad si sus servicios globales recaen en uno solo. Es una de las cosas que más me extrañaron cuando empecé a estudiar esta nube. Espero que a futuro permitan al menos elegir al usuario su región “maestra” para que no le ocurra a todo el mundo.

Para todos aquellos que aborrecen la nube. Entiendo el punto, pero no lo comparto. Los pros y los contras da para un post aparte, pero no olvidemos que cosas peores han pasado en las nubes privadas más grandes, como la caída de Facebook, donde ni los propios empleados podían acceder a los servidores para repararlos.