AWS registra tercera falla en tres meses en US-West-2 y derriba Apple Pay, Reddit y PlayStation por 64 minutos
En la mañana del 24 de julio, AWS sufrió 64 minutos de interrupción en la región de Oregón, la tercera falla en tres meses, afectando a Apple Pay, DoorDash, Reddit, PlayStation Network y otros servicios.
Qué cayó a las 3h55 en la costa oeste de EE. UU.
A las 3h55 PDT del 24 de julio, Amazon Web Services registró fallas de conectividad de red en la región US-West-2, en Oregón. En menos de veinte minutos, los informes de usuarios de Apple Pay, DoorDash, Reddit, Hulu y PlayStation Network aumentaron globalmente. AWS llegó a listar siete servicios afectados, entre ellos CloudFront, Global Accelerator y Elastic Container Service, lo que indicó una falla en múltiples capas de la red de Oregón, no en un producto aislado.
A las 4h59 PDT, la empresa declaró que todas las rutas de red estaban restauradas. Duración total: 64 minutos. AWS confirmó que no se perdió ningún dato de cliente y no divulgó la causa técnica específica del evento.
El patrón: octubre de 2025, mayo de 2026, julio de 2026
En octubre de 2025, la región US-East-1 quedó inestable durante horas por una condición de carrera en el sistema DNS de DynamoDB: dos procesos automatizados de gestión que se ejecutaban en zonas de disponibilidad diferentes entraron en conflicto. AWS publicó un informe posterior al incidente detallado unas semanas después. En mayo de 2026, una falla de hardware en los sistemas de refrigeración en un centro de datos de Virginia del Norte derribó instancias EC2 con un impacto de 7 a 14 horas. Nuevo informe publicado.
El evento de julio en Oregón fue descrito solo como "problema de conectividad". AWS no publicó un análisis posterior al incidente hasta el cierre de este artículo. El patrón histórico indica una ventana de dos a cuatro semanas para que este documento aparezca.
Según un análisis de Axis Intelligence sobre el historial de interrupciones de AWS de 2025 a 2026, la línea entre los principales eventos es que la automatización se comporta de maneras no previstas por los ingenieros, concentrándose en regiones que manejan un tráfico desproporcionado del resto de internet. US-West-2 es una de las regiones más densas de AWS en cargas de trabajo empresariales y plataformas de consumo norteamericanas.
Qué expone el evento de julio para el enterprise
Para CIOs que operan US-West-2 como región primaria sin failover configurado, 64 minutos representan más que una indisponibilidad operativa. Apple Pay, DoorDash y PlayStation Network quedaron expuestas al mismo evento por tener una dependencia centralizada en la misma región, cada una con SLAs internos exigentes.
El impacto es especialmente relevante en cargas de trabajo ágiles. Un modelo de lenguaje encadenando llamadas de API en bucle necesita intentos robustos y circuit breakers configurados; sin ellos, una interrupción de 64 minutos genera una cadena de tareas abandonadas sin recuperación automática. El costo real del downtime no es el de la hora parada, es el del proceso que no fue retomado.
EE. UU. e India: la misma lección, contextos diferentes
En Estados Unidos, la tercera falla en tres meses alimenta el argumento que los integradores cloud presentan a los CIOs desde hace meses: multi-cloud y multi-región no son opciones de arquitectura paranoia, son requisitos para contratos con SLAs por encima del 99,99% de disponibilidad. Cada análisis posterior al incidente de AWS publicado en los últimos tres episodios reveló el mismo patrón: subsistemas automatizados que pasaron las pruebas fallaron en producción bajo condiciones de carga real.
En India, TCS, Infosys y Wipro gestionan servicios cloud para clientes globales que ejecutan cargas de trabajo en US-West-2. Cada interrupción documentada entra en los informes de disponibilidad que sustentan contratos de outsourcing de infraestructura. La tercera ocurrencia en tres meses refuerza la posición de clientes que renegocian contratos de infraestructura gestionada: la exigencia de arquitectura multi-cloud deja de ser una cláusula de conformidad y pasa a ser condición para firmar.
Sin un RCA publicado, la cuestión permanece abierta: ¿el problema de Oregón fue puntual o es síntoma de una escala de automatización que superó la capacidad de validación segura de AWS?