Por qué la caída de AWS vuelve a demostrar que la observabilidad de todo el stack es indispensable

Los días 19 y 20 de octubre de 2025, el panorama digital —altamente dependiente de Amazon Web Services (AWS)— sufrió una grave interrupción debido a una falla en la región North Virginia (us-east-1) de AWS. El incidente comenzó alrededor de las 23:49 (hora del Pacífico) del 19 de octubre y se prolongó por más de 15 horas, afectando a más de 140 servicios de AWS. 

En este artículo analizaremos qué ocurrió, el impacto que tuvo y lo que podemos aprender del incidente. 

El efecto dominó

Una única falla en el sistema DNS dentro del extremo de la API de DynamoDB en la región us-east-1 desencadenó un fallo en cascada que afectó a numerosos servicios. A continuación, encontrarás el informe del incidente de AWS donde se detalla la interrupción:

Muchos servicios internos de AWS dependen de DynamoDB para almacenar datos esenciales, por lo que la falla inicial del DNS desencadenó una cascada de interrupciones secundarias:

1. Problemas en el lanzamiento de EC2: aunque el problema de DNS se resolvió alrededor de las 2:24 a. m. (hora del Pacífico) del 20 de octubre, surgió un nuevo inconveniente en el subsistema interno de EC2, encargado de iniciar las instancias. La dependencia que tiene este sistema en DynamoDB provocó errores al intentar iniciar nuevas instancias, que a menudo derivaban en mensajes de “Insufficient Capacity” (capacidad insuficiente).
2. Problemas de conectividad de red: mientras se trabajaba en el problema de EC2, AWS descubrió que las verificaciones del estado de los equilibradores de carga de red estaban fallando. Esto provocó amplios problemas de conectividad de red en varios servicios, incluidos DynamoDB, SQS y Amazon Connect.
3. Esfuerzos de mitigación y retrasos: para frenar las fallas en cascada, AWS limitó temporalmente ciertas operaciones, como el lanzamiento de nuevas instancias de EC2, la consulta de SQS mediante las asignaciones de fuentes de eventos de Lambda y las invocaciones asíncronas de Lambda. Si bien esto ayudó a estabilizar los servicios principales, generó retrasos en sistemas como AWS Config, Redshift y Amazon Connect, que requirieron varias horas para completarse por completo, incluso después de la recuperación del servicio.

Este efecto dominó ilustra cómo las interdependencias críticas dentro del ecosistema de AWS pueden amplificar el impacto de una sola falla Más información en el Dashboard de salud de AWS e Informe de servicios.

El impacto empresarial y por qué la observabilidad es fundamental 

El impacto de la interrupción fue de gran alcance y afectó a servicios propios de AWS, como Alexa y Amazon.com, sino también a grandes clientes como Snapchat, Venmo de PayPal y Reddit, además de herramientas esenciales como Docker y Zoom. Para los clientes de AWS y las organizaciones como las citadas que dependen en gran medida de las plataformas y servicios en la nube, las interrupciones de varias horas que afectan a diversos servicios de AWS pueden tener un impacto empresarial considerable.

El informe Pronóstico de observabilidad 2025 destaca el enorme impacto financiero de las interrupciones. Una interrupción en una aplicación, una plataforma o incluso en una oferta global de SaaS puede costarles a las organizaciones una mediana de 2,2 millones de dólares por hora, o aproximadamente 33 333 dólares por minuto. Aunque todavía es pronto para determinar cifras exactas sobre esta última interrupción, con una duración de más de 15 horas, es razonable suponer que las pérdidas fueron considerables. 

El informe también revela que las organizaciones que utilizan observabilidad de todo el stack (FSO) pueden reducir significativamente los costos de interrupción a 1 millón de dólares por hora, gracias a una mayor resiliencia y a la mitigación de riesgos.

El impacto empresarial no se mide solo en términos económicos. Las interrupciones de AWS, especialmente aquellas que implicaron acciones de limitación, impusieron una carga considerable sobre los equipos de ingeniería. Los ingenieros de guardia, el personal de DevOps y los SRE dedicaron cerca del 33 % de su tiempo total a resolver los problemas e incidentes derivados, atendiendo directamente las interrupciones del servicio.

Es justamente aquí donde la observabilidad redefine el paradigma:

• Detección más rápida: las organizaciones que implementan herramientas de observabilidad, como la de New Relic, para su observabilidad de todo el stack (FSO) logran una detección más rápida de interrupciones críticas. En promedio, su tiempo medio de detección (MTTD) es de 28 minutos, en comparación con los 35 minutos de aquellas que no cuentan con soluciones de FSO.
• Respuestas impulsadas por IA y RCA automatizado: dada la complejidad inherente de los sistemas distribuidos modernos, los operadores humanos suelen verse sobrepasados, lo que convierte a la inteligencia artificial (IA) en un recurso indispensable. Esta realidad se refleja entre los ejecutivos y líderes de TI, quienes identifican la resolución de problemas asistida por IA (38 %) y el análisis automatizado de la causa raíz (RCA) (33 %) como capacidades fundamentales. Estos enfoques impulsados por IA se consideran esenciales para acelerar la resolución de incidentes y mitigar de forma significativa el impacto de eventos de gran magnitud, como el efecto en cascada de AWS.
• Rastreo de extremo a extremo: el rastreo distribuido es una herramienta crucial para prevenir y resolver interrupciones, ya que permite seguir las solicitudes de transacciones a medida que se mueven entre los distintos servicios de back-end interconectados. La visibilidad de extremo a extremo es vital. Cuando surge un problema en un servicio de back-end, como una falla en la base de datos, el rastreo distribuido ayuda a los ingenieros a identificar con precisión qué servicios están degradando la experiencia del cliente, ya sea por cargas lentas de página o por errores. A su vez, los ingenieros de back-end pueden ver claramente cómo los problemas de infraestructura afectan directamente a sus clientes.
• Correlación de alertas: las herramientas de observabilidad como New Relic optimizan la gestión de incidentes al agrupar de manera inteligente las alertas relacionadas. Esto ayuda a filtrar las alertas irrelevantes y acelera la identificación de la causa raíz al revelar patrones de correlación asociados a escenarios específicos de incidentes. Esta funcionalidad resulta esencial para gestionar la complejidad de las fallas que involucran varios componentes.

Validación de la recuperación

Aunque las herramientas de observabilidad ayudan con el MTTD, también es importante identificar el tiempo medio de detección (MTTD); esto implica un monitoreo activo para confirmar si todo volvió a la normalidad. 

Aunque los dashboards de salud de AWS pueden marcar los tickets abiertos como “resueltos”, los servicios suelen seguir enfrentando retrasos. Estos retrasos suelen deberse a elementos como las colas de SQS, los procesos en segundo plano que activan funciones de Lambda o a otras dependencias de terceros. La observabilidad, por lo tanto, aporta la evidencia empírica esencial para confirmar que la calidad del servicio realmente ha vuelto a la normalidad.

• Tiempo activo y fiabilidad confirmados: la observabilidad confirma que la aplicación cumple su objetivo empresarial principal de mantener la disponibilidad y fiabilidad del sistema.
• Monitoreo sintético: el monitoreo sintético permite a los equipos ejecutar verificaciones continuas para garantizar que los extremos de la aplicación respondan correctamente después de la recuperación.
• Medición del éxito de la resolución: las prácticas de observabilidad, como el monitoreo de las métricas DORA y de las señales doradas (latencia, uso, errores y saturación), son útiles para confirmar mejoras en el MTTD y el MTTR tras los esfuerzos de recuperación y los cambios de procedimiento.
• Seguimiento de cambios: esta capacidad es fundamental porque admite funciones avanzadas de automatización, como acciones de corrección asistidas por IA, por ejemplo, reversiones o actualizaciones de configuración.

Es una interrupción de AWS… ¿Qué podemos hacer?

Bajo el modelo de responsabilidad compartida, AWS es responsable de resolver y restablecer la funcionalidad del servicio para los clientes que utilizan sus servicios. Pero ¿qué podemos hacer nosotros, como clientes, para prepararnos proactivamente ante la próxima interrupción y mitigar el riesgo? 

Nuestra participación va más allá de simplemente monitorear los paneles de AWS Health. Cuando se trata de gestionar interrupciones del servicio, no basta con contar con una estrategia de recuperación ante desastres (DR), con una configuración multirregión o, incluso, con sistemas avanzados de conmutación por falla entre regiones. 

El primer paso, y el más importante, es obtener una visibilidad clara de qué servicios se ven realmente afectados durante un incidente. Esta comprensión fundamental debe alcanzarse antes de poder ejecutar de manera eficaz cualquier plan de recuperación. En los entornos modernos de la nube, las arquitecturas suelen construirse utilizando los servicios de AWS como bloques de lego interconectados. Esta complejidad se amplifica en los microservicios y los sistemas distribuidos, donde los servicios de AWS se utilizan repetidamente a lo largo de la arquitectura, creando una red de dependencias que puede ser difícil de desentrañar durante una interrupción. Sin visibilidad en tiempo real, identificar la causa raíz y el alcance total del impacto se convierte en un desafío importante.

Las herramientas de observabilidad desempeñan un papel clave para lograr visibilidad en tiempo real:

• Identificación de los servicios afectados en tu stack: el servicio de AWS afectado podría impactar todo tu sistema o plataforma, o solo un componente menor. La observabilidad ofrece la claridad necesaria para identificar qué servicios se han visto afectados, garantizando así que puedas resolver los problemas de manera eficiente.
• Monitoreo de las señales doradas: monitorea las señales doradas dentro del entorno de conmutación por falla para garantizar su estabilidad y rendimiento, validando así el funcionamiento previsto de la estrategia de recuperación ante desastres (DR).
• Cuantificación de la pérdida de ingresos: la observabilidad también abarca los resultados comerciales. La aplicación Pathpoint de New Relic permite a los clientes visualizar el recorrido del usuario y cuantificar el impacto financiero de las métricas del negocio, mostrando la pérdida potencial de ingresos por cada minuto de inactividad.
• Alertas y dashboards: aprovecha tu vista unificada de alertas para identificar rápidamente todos los servicios afectados por una falla de AWS, informar de inmediato a los equipos dependientes para establecer una comprensión completa de la situación y consultar el dashboard centralizado para ver rápidamente la salud y las métricas de la aplicación o plataforma.

Cómo New Relic detectó la interrupción

En New Relic, utilizamos AWS para nuestras propias cargas de trabajo. La interrupción de AWS del 20 de octubre tuvo un impacto mínimo en nuestras funcionalidades principales, ya que la mayor parte de nuestra plataforma opera fuera de la región us-east-1. La ingesta de datos, el almacenamiento, las consultas, las alertas y la interfaz de New Relic continuaron funcionando con normalidad.

Sin embargo, algunas de nuestras cargas de trabajo se vieron afectadas. Entre ellas, Synthetics, AWS Cloud Monitoring, Infinite Tracing, la simbolización móvil y los eventos relacionados con el consumo en New Relic (como NrConsumption y NRMTDConsumption). Synthetics, Cloud Monitoring e Infinite Tracing están diseñados para ejecutarse en varias regiones, por lo que solo se vieron parcialmente afectadas. En cambio, la simbolización móvil y los eventos de consumo dependen específicamente de la región us-east-1.

Como monitoreamos activamente la plataforma de New Relic con New Relic, detectamos el problema en cuanto comenzó. A las 11:57 (hora del Pacífico), se activaron alertas para un servicio que utilizaba DynamoDB en la región us-east-1, lo que nos permitió identificar de inmediato los errores entrantes.

Al recibir las alertas, monitoreamos activamente los incidentes desencadenados para evaluar el impacto de la interrupción. A pesar del efecto menor que tuvo en la plataforma de New Relic, continuamos con la supervisión para garantizar que nuestros clientes pudieran resolver cualquier problema asociado.

Conclusión

Durante una interrupción de AWS, aún no se cuenta con la información necesaria para decir con confianza: “¡vamos a implementar las correcciones!”. Tampoco es el momento adecuado para replantear la estrategia de recuperación ante desastres (DR) ni para evaluar la arquitectura en sí, especialmente si ya se está trabajando con una configuración multirregión, dado que esta interrupción afectó específicamente a la región us-east-1. 

En lugar de ello, el foco debe estar en aprovechar herramientas de observabilidad como New Relic para interpretar los datos de telemetría (MELTX) e identificar rápidamente los servicios afectados. Estas herramientas ofrecen visibilidad de todo el stack en toda la arquitectura: desde las aplicaciones front-end y el APM hasta las bases de datos y la infraestructura. Esto incluye no solo las máquinas virtuales, contenedores o clústeres de Kubernetes, sino también información detallada sobre el entorno de AWS y la salud del proveedor de nube. 

Este tipo de interrupciones pueden provocar disrupciones empresariales significativas. Como ingenieros, nuestra prioridad es entender qué está fallando, qué partes se ven afectadas y en qué medida. En momentos críticos como estos, contar con una estrategia integral de observabilidad es esencial para mantener una visión clara del entorno y minimizar el impacto.