Los recientes problemas de AWS en la región de Virginia del Norte, ocurridos entre el 19 y el 20 de octubre, han puesto de manifiesto la complejidad de las automatizaciones internas y las implicaciones de los fallos en un sistema tan masivo. Un fallo en la automatización que gestiona el DNS de DynamoDB fue la raíz del problema. Al aplicar un plan vacío para el endpoint regional, dejó de resolver direcciones esenciales, provocando una reacción en cadena que afectó a numerosos servicios y aplicaciones críticas como IAM, EC2, Lambda y otros.

El proceso de recuperación fue laborioso y requirió la intervención manual para restaurar el estado correcto del DNS, lo que llevó a un restablecimiento gradual de los servicios afectados. Durante el incidente, se reportaron aumentos significativos de errores en las APIs de DynamoDB, impidiendo que tanto clientes como los sistemas internos de AWS establecieran nuevas conexiones.

La situación se complicó aún más con el colapso de la infraestructura de administración de flotas físicas, que quedó congestionada al intentar reestablecer múltiples arrendamientos con los servidores. Por su parte, el Network Load Balancer experimentó picos de errores de conexión debido a un mal manejo en sus chequeos de salud.

Las causas del incidente se han atribuido a un «race condition» en el DNS, donde la concurrencia de dos procesos de aplicación de planes DNS resultó en la eliminación accidental de registros efectivos, dejando el endpoint sin direcciones IP asignadas. Este tipo de fallo resalta la complejidad interconectada de los servicios de nube, donde una dependencia mal manejada puede generar impactos en cascada que afectan a toda una región.

A raíz de lo sucedido, AWS ha decidido deshabilitar la automatización DNS de DynamoDB de forma global para corregir el problema del «race condition» y establecer protecciones adicionales para prevenir la aparición de planes erróneos en el futuro. También se implementarán controles más rigurosos en el Network Load Balancer para manejar mejor los fallos de salud y evitar conmutaciones agresivas.

Este evento ha dejado lecciones importantes para los equipos de plataforma. La resiliencia en la arquitectura debe ser una prioridad, incorporando diseños que permitan operar en múltiples regiones y reduciendo dependencias entre los subsistemas. La correcta gestión del DNS, así como el dimensionamiento de los chequeos de salud, son cruciales para mitigar futuros incidentes.

En el contexto más amplio, la pregunta sobre si la región de Virginia del Norte se ha convertido en un «canario» para AWS resuena. Dada su historia de problemas, se hace evidente que no se puede depender exclusivamente de esta región para el manejo de datos críticos. Las empresas que operan en la nube deben estar preparadas para evaluar sus dependencias y adoptar estrategias más robustas para asegurar la continuidad del servicio en un entorno cada vez más complejo.