¿Qué causó el fallo de Amazon AWS y cómo se podría prevenir que afectase a mi sistema?
El lunes 20 por la mañana, muchos usuarios descubrieron que algunas plataformas web, servicios online y aplicaciones simplemente dejaban de responder. Páginas como la tienda de Amazon, Prime Video, Alexa, Canva, o incluso juegos como Fortnite presentaban errores o latencia excesiva. La causa no era un fallo del proveedor local de internet, sino un problema interno en la infraestructura de nube de Amazon Web Services (AWS).
AWS confirmó que los primeros indicios del fallo comenzaron a las 9:11 (hora peninsular española) dentro de la región US-EAST-1, una de sus zonas más críticas y usadas a nivel global. Para las 9:51 ya se detectaban tasas altas de errores y latencia en esa región. A las 10:26 Amazon identificó que el origen del problema estaba vinculado a DynamoDB, su servicio de base de datos NoSQL completamente gestionado.
En concreto, el fallo parece estar asociado a la resolución DNS del punto final de la API de DynamoDB en dicha región. En otras palabras, cuando los servicios intentaban localizar o comunicarse con la API de DynamoDB, esa resolución (la traducción entre nombres de dominio y direcciones de red) fallaba o no respondía correctamente.
AWS fue aplicando mitigaciones a partir de las 11:22, y alrededor de mediodía informaba que 66 servicios afectados ya estaban mayormente recuperados.
¿Por qué es esencial distribuir servicios en varias ubicaciones (zonas/regiones)?
El incidente de AWS muestra de forma clara un principio fundamental en arquitectura de nube: no confiar todos los servicios al mismo proveedor en un único servidor. Aquí algunas razones por las que es recomendable tener redundancia geográfica:
Solucionar fallos por región: cuando un problema afecta una región (como ocurrió en la zona US-EAST-1), si tienes arquitectura distribuida en otras regiones o zonas, el impacto puede limitarse a una porción del tráfico. Los usuarios en otras regiones podrían seguir funcionando sin interrupciones.
Alta disponibilidad y tolerancia a fallos: replicar datos y servicios en múltiples ubicaciones permite conmutaciones por error (failover) automáticas o manuales. Si un datacenter o zona cae, el sistema puede desviar el tráfico a otra región que esté operativa.
Latencia y proximidad: además del tema de resiliencia, tener servicios cerca de los usuarios reduce tiempos de respuesta (latencia), mejorando el rendimiento general.
Prevenir cuellos de botella: incluso si el fallo inicial es en un componente como DNS o una API específica en una región, un diseño distribuido puede evitar que ese error se propague globalmente, aislando fallos y salvaguardando partes del sistema.
Recuperación ante errores acumulados: si muchas peticiones se acumulan en cola por un fallo, una región alternativa puede ayudar a alivianar esa carga o absorber parte de esa demanda mientras resuelven el problema principal.
En el modelo idóneo, una aplicación crítica debe estar desplegada con replicación en al menos dos regiones independientes (zonas de disponibilidad dentro de regiones, o regiones distintas), o dos proveedores diferentes de modo que un fallo en una no deje completamente fuera de servicio al conjunto.
