Falla de varios servicios de AWS en la región us-east-1

• Se reportaron fallas en diversos servicios de AWS en la región us-east-1
• A causa de esta incidencia, empresas que usan infraestructura en la nube sufrieron interrupciones del servicio
• Se reportaron problemas de disponibilidad en servicios clave como API Gateway y Lambda
• Los ingenieros señalaron la necesidad de preparar rutas alternativas y revisar planes de respuesta de emergencia
• AWS Health Dashboard proporcionó información en tiempo real y actualizaciones sobre la falla

---

Resumen de la interrupción en la región AWS us-east-1

• El 21 de octubre de 2025, el AWS Health Dashboard informó una caída en varios servicios pertenecientes a la región us-east-1
• Servicios clave como API Gateway, Lambda y S3 se vieron afectados, por lo que muchos clientes experimentaron interrupciones del servicio
• Desde el momento en que comenzó la caída, AWS identificó el problema e inició de inmediato el análisis de causa raíz y las tareas de recuperación
• En empresas SaaS, startups y compañías de TI que dependen de esa región se reportaron retrasos y caídas de servicio
• Ingenieros y gerentes de TI destacaron la necesidad de construir rutas de contingencia de emergencia y de una estrategia de regionalización para los servicios críticos

Impacto y respuesta

• La región us-east-1 es una de las regiones con mayor tráfico en la infraestructura de nube global, por lo que el impacto de una falla allí puede ser muy grande
• En la práctica, varias organizaciones informaron problemas como interrupción en la prestación del servicio, retraso en las respuestas de API y fallas en el procesamiento de datos al mismo tiempo
• AWS informó la situación en tiempo real a través de Health Dashboard y proporcionó documentación de soporte y actualizaciones
• Los equipos de TI de las empresas clientes realizaron monitoreo de la situación de la falla, rutas de contingencia temporales y avisos a los usuarios para minimizar el impacto

Implicaciones para la ingeniería

• Se planteó nuevamente la necesidad de reafirmar la importancia de los sistemas de monitoreo y de los mecanismos de alerta de fallas
• Se destacó el valor del diseño de una arquitectura resiliente con despliegue multi-región, acciones automatizadas ante fallas y estrategias de respaldo
• AWS Health Dashboard se utilizó como herramienta de apoyo para obtener información rápida y apoyar la toma de decisiones durante incidentes

Conclusión

• Los proveedores de servicios de nube a gran escala necesitan prepararse necesariamente para la posibilidad de fallas de servicio
• Una vez que ocurre una incidencia, vuelve a destacarse la importancia de una recuperación rápida, una comunicación transparente y capacidades eficientes de respuesta de infraestructura

[GN⁺]

Comentario de Hacker News

• Hoy fue un día realmente interesante. Estuve en el puente de respuesta a incidentes desde las 3 de la madrugada. El sistema ya se recuperó en su mayor parte, pero todavía hay un equipo en back office que sigue batallando con falta de recursos. Nuestro mayor error fue que, a pesar de haber diseñado el sistema para funcionar en múltiples regiones, no pudimos ejecutar el proceso de failover. La razón fue que seguridad nos migró a Identity Center y lo dejó desplegado solo en us-east-1, dejando a toda la empresa completamente bloqueada del plano de control de AWS. Cuando sacamos las credenciales root de la bóveda, el sistema ya estaba casi totalmente recuperado. Esta experiencia me volvió a recordar que un sistema es tan fuerte como su eslabón más débil.

  • Me recordó bastante al caos que hubo cuando el centro de datos de Google en París se inundó y luego hubo un incendio hace unos años. No teníamos recursos de cómputo allí directamente, pero estábamos ejecutando cómputo en un data center de AWS EU, y el resolvedor DNS para servicios de Google estaba alojado en París, así que el tráfico se dirigía primero hacia allá. La solución temporal fue bastante curiosa. Esa vez descubrimos por primera vez que podíamos editar el archivo /etc/hosts desplegado en Kubernetes de forma global con mucha facilidad, y que era necesario hacerlo con urgencia. En condiciones normales no usaría /etc/hosts para ese tipo de cosas, pero como parche temporal fue exactamente el nivel de abstracción correcto.
  • Me viene a la mente un caso similar de Facebook, donde un error en una actualización de BGP dejó totalmente imposible el acceso al vault. Cuando la ruta de autenticación es circular, si DNS se rompe no puedes hacer nada.
  • Al final llega el momento en que alguien tiene que tomar el token de hardware y tomar un avión a otro centro de datos para reiniciar el equipo crítico que hace que los sistemas globales vuelvan a funcionar.
  • Cuando se mencionó que Identity Center está solo en us-east-1, pregunté si se podía poner en varias regiones. La última vez que lo revisé, solo podía estar disponible en una región y, para moverlo, primero había que eliminarlo.
  • Demasiadas barreras de seguridad terminan dejando todo inmóvil. Me pregunto si seguridad asumirá responsabilidad por esto. Esto probablemente hará que todos los proyectos avancen más lento en adelante. Siento que el equipo de seguridad ha estado acelerando demasiado. ¿Quién está vigilando al vigilante?

• Parece que todavía siguen ocurriendo fallas importantes. La situación está peor que hace 4 horas. Soy ingeniero de datos y Redshift y Airflow (servicios administrados de AWS) están totalmente desordenados.

  • La caída se está alargando bastante, y me pregunto cuántos nueves se habrán ido. Si calculas 365 días * 24 horas * 0.0001 te da aprox 8 horas, así que ya se perdió la disponibilidad de 99.99 %.
  • No entiendo por qué tantas empresas siguen apostando por us-east-1. Por frecuencia de fallas, sigue siendo abrumadoramente la peor. Nuestra compañía en el pasado decidió evitar us-east-1 y usar solo otras regiones. Claro, si un servicio se define como “global”, muchas veces significa us-east-1 en la práctica y eso a veces no ayuda.
  • Las operaciones de control plane de create-function de Lambda todavía fallan con InternalError. Otros servicios (Lambda, SNS, SQS, EFS, EBS, CloudFront) ya se recuperaron. Estoy estudiando una maestría en disponibilidad en la nube, así que estoy documentando la línea de tiempo y el impacto mientras pruebo en varias cuentas de laboratorio de AWS. Publicación de análisis
  • En Down Detector sigue viéndose que la caída de AWS sigue siendo grave. Amazon dice que “el servicio está en recuperación”, pero en la práctica ni siquiera en Amazon.com funciona la búsqueda de productos. AWS Health Page
  • Según Down Detector, a las 12:52 AM PT (3:53 AM ET) hubo 5,755 reportes de incidentes de AWS, a las 4:22 AM PT (7:22 AM ET) bajó a 1,190 y a las 9:32 AM PT (12:32 PM ET) subió de nuevo a 9,230. Puede que aumentaran por el reinicio de la costa oeste, pero da la sensación de que AWS aún no controla con claridad la situación.

• Esta caída también me afectó directamente en mi día. Fui a Whole Foods en Hudson Yards, Nueva York, a comprar una barra de chocolate, pero no se aplicó el descuento de Prime. Así que no la compré y ahora mi nivel de chocolate está bajísimo.

  • Esta mañana tampoco funcionó “Alexa, enciende la cafetera”. Me dejó desconcertado.
  • Al almorzar intenté armar comida del hot bar y pasar por self-checkout, pero estuve dándole vueltas a por qué no escaneaba el código de barras de Whole Foods. Solo después de unos 20 segundos entendí que era por la caída.
  • Buen caso para compartir, gracias. Pero ahora me pregunto qué habrá pasado con la gente que estaba en una tienda Amazon Go durante la caída de AWS.

• Hoy tengo una reunión con el responsable de mi cuenta de AWS. Voy a explicar que nos alejaremos de “All in on AWS” y distribuiremos la carga entre varias plataformas. La principal razón es que la innovación de los servicios core se está desacelerando y también estamos muy atrasados en IA en comparación con competidores. El equipo de AWS siempre argumenta que no hay que distribuir cargas por la extrema estabilidad de AWS. Tengo expectativa para la reunión de hoy.

  • En AWS, Cloudflare, Google Cloud, Akismet y tantos otros, todos terminan teniendo una caída en algún momento. Cada vez que pasa, uno piensa en irse a hosting propio. Al final, terminas operando de nuevo. Como el resultado termina siendo similar, prefiero no complicarme demasiado con eso.
  • En el último reporte de resultados, cuando criticaron a Andy Jassy porque se decía que AWS iba quedándose atrás en innovación, él sostuvo que era por la estabilidad, la confiabilidad y la durabilidad. Pero esta situación no deja que ese argumento pase.
  • Exceptuando us-east-1, el resto de las regiones está funcionando bastante estable. Nuestra empresa también tiene la mayoría de su carga en eu-west-1 y está andando bien sin incidentes significativos.
  • AWS está en decadencia a largo plazo. Hoy en día da la sensación de que solo mantiene los servicios existentes. Sus ingenieros más innovadores están siendo aplastados por la burocracia interna y la presión por rendimiento, y eso también los hace quedar atrás en IA.
  • El discurso de que AWS siempre fue increíblemente estable no fue verdadero desde el principio. Antes configuré monitoreo multi-cloud con varias nubes y servidores dedicados, y podía ver claramente quién fallaba primero. En ese análisis, AWS no siempre fue primero. Coincidía bastante con los datos de netcraft.com.
  • Hoy la Premier League también operará de forma limitada el VAR y el sistema de offside automático por la caída de AWS. Realmente vivimos en una época extraña enlace de BBC
  • Me hizo sentir que incluso en la nube hay un toque de lado positivo en la caída.

• Si tomas us-east-1 como región principal, cuando ocurre la caída no hay nadie que se salve: nadie sufre solo. En otras regiones de EE. UU. no tienes ese “privilegio”.

  • Una de las ventajas inesperadas de migrar desde un data center propio a AWS fue que cuando cae una región completa, los clientes son más tolerantes. Como todos están afectados al mismo tiempo, la gente lo pasa más fácil.
  • A veces hay que pasar por una caída técnica al menos una vez.
  • Bueno, pongamos toda la infraestructura en US-East-1.
  • En el entorno corporativo se tarda bastante en entender qué es verdaderamente importante. En la práctica, es más importante tener una arquitectura donde puedas culpar a alguien que la disponibilidad pura. Si por error humano hay 5 minutos de caída al año, es responsabilidad del CTO; si AWS provoca 5 horas de caída, eso incomoda a todos y se acepta como “algo inevitable”. AWS, Crowdstrike y compañía, al final, importa menos la solidez, costo-beneficio o gestión de riesgo que el hecho de que todos compartan el dolor al mismo tiempo. Es incómodo, pero real. Para quienes disfrutamos que la tecnología funcione bien, eso enfurece.
  • ¡La región de Tokio está funcionando bien ahora! Solo todavía hay problemas en algunas funciones como iniciar sesión en la consola.

• Hubo un anuncio: “El resultado del análisis sugiere que el problema probablemente está relacionado con un problema de resolución DNS del endpoint de la API de DynamoDB en US-EAST-1. Estamos acelerando la recuperación con un enfoque paralelo”. Como era de esperarse, la causa siempre termina siendo DNS.

  • Me pregunto si esta caída sí fue un problema de resolución DNS o un problema de configuración interna/almacenamiento de datos del servidor DNS. Creo que es más lo segundo.
  • En un aviso posterior de la caída se indica que la causa fue una falla del network load balancer. DNS fue un síntoma del problema raíz. DNS pudo haber roto los health checks, pero en mi opinión la causa principal está en red.
  • BGP podría ser un caso de DNS enmascarado.
  • La causa siempre es us-east-1.
  • Si no es DNS, al final sí termina siendo DNS.

• Funcionó como estaba diseñado para la resiliencia. Pusimos orígenes estáticos multi-región en CloudFront y no se vieron afectados por esta caída. El plano de control también es una arquitectura multi-región nativa, así que, aunque depende de varios servicios, mantiene la disponibilidad. Cada región funciona de forma independiente y hay replicación de datos, y no importa si no se replica us-east-1. El servicio en sí mismo es multi-región y maneja failover en varias capas (DNS, enrutamiento, selección de destino). Aunque este enfoque no es perfecto y hay muchas posibles causas de fallo, esta vez funcionó bien y me dejó satisfecho. Lo que hice no es ingeniería de cohetes ni caro, pero sí es un enfoque un poco distinto a la norma. Siéntanse libres de preguntar cualquier cosa.

  • Evitar esta caída con orígenes estáticos multi-región en CloudFront debería ser algo básico para 2025, y aun así sigue siendo algo digno de elogio.
  • Me intriga si es active/active y cómo está armado el stack de datos; ese punto me parece especialmente difícil.
  • Me gustaría saber cómo implementaron la resiliencia para claves y certificados.

• Un problema grande fue la cascada causada por la sobrecarga o caída del sistema IAM/auth. Se menciona que DynamoDB fue la causa, pero me pregunto si IAM depende internamente de Dynamo. En sistemas tan masivos y complejos con dependencias tan enmarañadas, Auth/IAM puede terminar siendo un punto de entrada único global, por eso queremos minimizar dependencias. Pero escalabilidad y consistencia también importan, y por eso terminamos usando una DB comprobada. Al final, por esa complejidad, uno pensaría que hay que pasar por un proceso de bootstrap complejo cuando hay caída. Me interesa saber cómo lo manejan.

  • Hubo un incidente masivo hacia 2017 por una caída de DynamoDB. EC2 guardaba la lista de servidores en DynamoDB, y cuando DynamoDB cayó, EC2 también cayó. Como DynamoDB corría sobre EC2, ni siquiera era posible recuperar levantando nuevas instancias de EC2. Tuvimos que reponer instancias manualmente durante días. Desde entonces hemos tratado de separar al máximo las dependencias entre sistemas de primer nivel como S3, DynamoDB y EC2. Obviamente no es perfecto.
  • Muchos clientes de AWS, por estrategias de reintento incorrectas, al fallar un sistema terminan sobrecargando otro. La caída de DynamoDB se propagó y sobrecargó IAM.
  • Internamente, Amazon tiene una plataforma KV llamada Dynamo separada de DynamoDB, por lo que la causa también podría estar en el enrutamiento DNS o el despliegue de nodos. Este tipo de issue aparece una y otra vez en los post-mortems de fallas grandes.
  • Cuando trabajé en AWS, IAM no dependía de Dynamo. No sé si hoy eso cambió, pero no tengo certeza. Pienso que es más probable el impacto de un problema de red a gran escala. Si Auth/IAM no debe ser un punto de entrada global, el diseño apunta a minimizar dependencias. IAM tiene cache de solo lectura por región, y AWS SigV4 también está pensado para operar por región. (Documentación de referencia)
  • Es interesante que la causa del reciente incidente de GCP también fue un problema similar.

• AWS anunció a las 3:03 AM PT que estaba en recuperación. Sin embargo, la situación empeoró. A las 9:13 AM PT volvieron a decir que estaban analizando la causa. Se siente preocupante que AWS tampoco sepa exactamente cuál es la causa.

  • Este incidente también parece haber tenido el impacto de la semana de Diwali (la fiesta más grande de India), ya que muchos ingenieros indios estaban de vacaciones. De verdad fue mala suerte.