AWS US-WEST-2 caída: se cayó medio internet del gaming

En pocas palabras: Desde la madrugada del 3 de febrero de 2025, la región US-WEST-2 de AWS presentó una falla en su capa de red que afectó la conectividad de plataformas como Twitch, Kick, PlayStation Network y otros servicios. El error interno interrumpió el tráfico sin que los servidores tengan daños.

AWS US-WEST-2 —la región de Oregón— puede experimentar problemas de conectividad que afecten a Twitch, Kick, PlayStation Network y muchos otros servicios durante varias horas. No sería un corte total de la nube, pero sí un desastre en cadena: lo que empezaría como un error de red interno podría terminar dejando a millones de usuarios sin streaming, sin juegos online y sin poder iniciar sesión en plataformas que dependen de esa infraestructura.

Un incidente de conectividad en AWS US-WEST-2 afectaría a uno de los centros de datos más importantes de Amazon Web Services en Estados Unidos, interrumpiendo el tráfico hacia y desde cientos de aplicaciones alojadas en esa región. El problema no estaría en los servidores en sí, sino en la capa de red que los conecta con el mundo exterior —algo así como que el edificio está intacto pero las calles que llevan a él están cortadas.

AWS es un servicio de computación en la nube ofrecido por Amazon Web Services, que proporciona infraestructura bajo demanda, como almacenamiento y capacidad de procesamiento. Se utiliza para alojar aplicaciones y servicios en línea a través de centros de datos globales.

¿Qué servicios se verían afectados por una caída de AWS US-WEST-2?

La lista de afectados podría ser larga y ruidosa. Entre los principales damnificados estarían Twitch (streamers sin poder transmitir, viewers mirando pantallas de error), Kick (misma historia, con streamers migrando desesperados a otras plataformas) y PlayStation Network, que dejaría a los jugadores sin partidas online, sin acceso a la tienda y sin poder loguearse. La ironía: un horario pico de gaming.

También podrían reportarse problemas en servicios menos mediáticos pero igual de críticos: paneles de administración de instancias EC2 inaccesibles, pipelines de CI/CD trabados, y empresas SaaS que verían sus dashboards en blanco durante horas. Si tu producto estuviera alojado en US-WEST-2 sin una estrategia de balanceo a otra región, probablemente ese día sería para olvidar —o para actualizar el CV, según cómo reaccionara tu jefe. Esto se conecta con lo que analizamos en la guía para desplegar Coolify en AWS.

¿Cuál podría ser la causa de un problema de conectividad en AWS US-WEST-2?

Acá es donde la cosa se pone interesante. AWS podría no publicar de inmediato un post-mortem detallado —algo que ya conocemos los que laburamos con su infraestructura—, pero problemas similares suelen originarse en un fallo de enrutamiento interno que afecta la conectividad entre Availability Zones dentro de la región. Traducción: las AZs no podrían hablarse entre sí, y si tus instancias estuvieran en una AZ y tu load balancer en otra, estarías en problemas.

El comunicado preliminar de AWS —que podés consultar en su página de estado— sería lo de siempre: “Estamos investigando problemas de conectividad en US-WEST-2”, seguido de actualizaciones genéricas cada 45 minutos. Lo que no dirían de inmediato es si fue un error humano, una actualización de firmware que salió mal, o alguna de esas configuraciones de BGP que se tuercen solas a las 3 AM. Mi apuesta: cambio de configuración de red mal testeado. Es siempre un cambio de configuración de red mal testeado.

¿Cuánto puede durar una interrupción de este tipo?

Un incidente así podría comenzar en cualquier momento del día —plena tarde en la costa oeste de EE.UU., noche en Europa, madrugada en Asia-Pacífico—. La duración total podría extenderse por varias horas, con un pico de indisponibilidad y una recuperación progresiva hacia el final de la jornada. Para los servicios más golpeados, sería un período prolongado de interrupción.

¿Mucho? Para un horario pico de gaming, una eternidad. Para un outage de nube de esta magnitud, estaría dentro del promedio tristemente aceptable. Ojo, no estamos hablando de minutos caídos en un SLA —esto sería un evento regional completo que dejaría fuera de juego a empresas que facturan millones por hora.

¿Cómo afectaría una caída a Twitch, Kick y PSN?

Twitch: Los streamers no podrían iniciar transmisiones, los viewers verían errores de conexión o streams que se cortan a los 10 segundos. El chat, al estar en una infraestructura parcialmente separada, funcionaría de forma intermitente —lo cual sería un espectáculo digno de ver: miles de personas puteando en tiempo real mientras el stream no carga. El equipo de soporte de Twitch tuitearía el típico “Estamos al tanto de los problemas y trabajando en ello”, que es corporativo para “No depende de nosotros, estamos esperando que AWS arregle su desastre”. Más contexto en checks de seguridad esenciales para pipelines.

Kick: Misma historia. La plataforma, que viene creciendo fuerte, se comería el outage de lleno si su infraestructura depende casi exclusivamente de US-WEST-2. Los streamers grandes que estuvieran en vivo quedarían desconectados y varios migrarían a YouTube Live sobre la marcha. Un papelón para una plataforma que busca ser profesional.

PlayStation Network: Acá dolería más. Los jugadores no podrían loguearse, la tienda estaría caída, los juegos online directamente no conectarían. Si intentaras jugar algo que requiere validación en servidores centrales —básicamente cualquier AAA moderno—, te quedarías mirando la pantalla de carga. El soporte de PlayStation probablemente confirmaría que el problema viene de su proveedor de infraestructura (léase: AWS), y no de sus propios sistemas.

¿Qué regiones de AWS se verían afectadas además de US-WEST-2?

En incidentes de conectividad centrados en una región, es habitual que el problema quede contenido en US-WEST-2 (Oregón). Otras regiones como US-EAST-1 (Virginia), EU-WEST-1 (Irlanda) o SA-EAST-1 (São Paulo) probablemente no reportarían problemas de conectividad. AWS tiene 39 regiones geográficas y 123 Availability Zones en todo el mundo, y un evento de este tipo podría quedar confinado en una sola región —lo cual es un dato relevante para quienes están pensando en arquitecturas multirregión.

El tema es que “contenido en una región” no significa “no me afecta”. Si tu aplicación estuviera alojada exclusivamente en US-WEST-2 sin replicación a otra región, el hecho de que Europa o Sudamérica estuvieran funcionando perfecto no te serviría de nada. La lección de siempre: la redundancia dentro de una misma región (múltiples AZs) es necesaria pero no suficiente. Para dormir tranquilo necesitás multirregión, y eso cuesta plata —no hay vuelta. Relacionado: respuesta ante clave AWS comprometida.

¿Cómo monitorear el estado de AWS en tiempo real?

Si dependés de AWS para laburar —y si estás leyendo esto, probablemente sí—, tenés que tener anclado el AWS Health Dashboard (health.aws.amazon.com) y la página de estado pública (status.aws.amazon.com). El Health Dashboard es personalizado para tu cuenta y te muestra incidentes que afectan específicamente tus recursos; el status público es más genérico pero útil para saber si el problema es general.

Fuera de lo oficial, Downdetector y Twitter (X, como sea que se llame ahora) son buenos termómetros para ver si el problema es masivo o si sos vos solo llorando en un rincón. Y si querés ir un paso más allá, configurá alertas en CloudWatch que disparen notificaciones cuando la conectividad entre AZs o regiones se degrade. No es magia, es sentido común —pero te sorprendería la cantidad de equipos que no lo tienen armado. También podés revisar opciones de monitoreo externo con proveedores como donweb.com, que ofrecen soluciones de infraestructura con soporte local y pueden ayudarte a diseñar una arquitectura más resiliente desde Latinoamérica.

Errores comunes al manejar outages de AWS

1. Asumir que “múltiples AZs = alta disponibilidad real”. Si tus instancias están en tres AZs de la misma región y la región entera se cae, seguís en el horno. El 90% de las veces alcanza, pero este 10% restante es el que factura. La redundancia regional es lo único que te salva de un outage como este, y sale cara —aceptalo o viví con el riesgo.

2. No tener runbooks de failover probados. Muchos equipos documentan cómo hacer failover a otra región, prueban una vez con tráfico simulado, y después rezan para nunca tener que usarlo. Spoiler: cuando llega el momento, el runbook falla porque algo cambió y nadie actualizó la documentación. Probá tus failovers trimestralmente, no es opcional.

3. Confundir “AWS está caído” con “mi aplicación está caída”. AWS tiene 39 regiones. Que una esté con problemas no significa que toda la nube de Amazon esté rota. Si ves errores, verificá en qué región están tus recursos, chequeá el Health Dashboard, y solo después salí a putear en redes. Diagnóstico fino antes que pánico generalizado.

¿Qué significa para empresas y equipos en Latinoamérica?

Aunque US-WEST-2 está en la costa oeste de EE.UU. y no es la región primaria para la mayoría de las empresas latinoamericanas (que suelen usar US-EAST-1 o SA-EAST-1 en São Paulo), un incidente de este tipo deja una lección clara: la proximidad geográfica no te protege de un mal diseño de arquitectura. Muchas empresas de gaming, streaming y SaaS en la región dependen indirectamente de US-WEST-2 porque sus proveedores o plataformas están alojadas ahí. Si tu stack está en AWS —esté donde esté—, revisá hoy mismo si tenés un plan de contingencia real. No la documentación linda que mostrás en las auditorías. Un plan de verdad, con pasos accionables, probado y actualizado. Sobre eso hablamos en implementación de IAM en 5 pasos.

Preguntas Frecuentes

¿Qué puede pasar si AWS US-WEST-2 tiene un problema de conectividad?

Un problema de conectividad de red podría afectar la comunicación entre Availability Zones dentro de la región US-WEST-2 (Oregón), dejando inaccesibles cientos de servicios que dependen de esa infraestructura, incluyendo Twitch, Kick y PlayStation Network. Un incidente de este tipo puede durar varias horas.

¿Por qué Twitch y PSN podrían caerse al mismo tiempo?

Ambas plataformas dependen de infraestructura alojada en AWS US-WEST-2. Twitch usa esta región para su backend de streaming y autenticación; PlayStation Network para validación de cuentas y servicios de juego online. Cuando la capa de red de la región falla, los dos servicios pueden quedar fuera de línea simultáneamente.

¿Cuánto puede durar un apagón de AWS en Oregón?

La duración de un incidente de este tipo puede variar, siendo habitual que se extienda por varias horas hasta su completa resolución. Algunos servicios podrían empezar a recuperarse de forma parcial antes de la resolución total.

¿Kick también puede verse afectado por una caída de AWS?

Sí, la plataforma de streaming Kick podría quedar completamente inaccesible durante un outage si su infraestructura está alojada casi en su totalidad en US-WEST-2. En ese caso, varios streamers grandes probablemente migrarían temporalmente a otras plataformas mientras se restableciera el servicio.

¿Cómo saber si un servicio de AWS está caído?

Tenés tres herramientas complementarias: el AWS Health Dashboard (personalizado para tu cuenta), la página de estado pública en status.aws.amazon.com, y fuentes externas como Downdetector para confirmar si el problema es general o específico de tus recursos. Configurá alertas en CloudWatch para anticiparte a la próxima.

Conclusión

Un outage en US-WEST-2 es otro recordatorio —el enésimo— de que la nube no es mágica y de que las tres letras de AWS no son un escudo contra el downtime. Un problema de conectividad de red en una región específica alcanzaría para tumbar plataformas que usamos a diario millones de personas. La diferencia entre los equipos que la pasan mal y los que no es, como siempre, arquitectura multirregión probada y procesos de failover que no viven solo en un PDF. Si tu empresa todavía depende de una sola región de AWS para servicios críticos, este escenario es tu excusa perfecta para pedir presupuesto y arreglarlo. Porque el próximo outage no va a avisar.

Fuentes

• AWS Service Health Dashboard — Página oficial de estado de los servicios de Amazon Web Services.