La infraestructura de Amazon Web Services (AWS) sufrió una incidencia de alto impacto hace 3 días centrada en la región US-East-1 (Norte de Virginia), el corazón de muchos servicios críticos. Aunque el foco estuvo en una región, el efecto dominó se notó en otras, con degradaciones y cortes en cadena. No hablamos de “la nube” como algo etéreo: detrás hay máquinas reales y dependencias muy fuertes; cuando esa pieza central falla, medio internet se resiente.
Desde el minuto uno AWS fue publicando actualizaciones detalladas en su panel de estado, pero la recuperación no fue inmediata. El propio seguimiento de la incidencia evidenció que no había un tiempo garantizado de resolución, solo comunicación continua de avances, algo habitual en eventos complejos de este tipo.
Servicios afectados: del SaaS a los videojuegos
El impacto se extendió a plataformas que dependen de AWS de forma directa o a través de su edge, con incidencias en Vercel (edge functions), Supabase (proyectos alojados en la región afectada) y múltiples webs y apps populares. En el radar de afectación aparecieron nombres de gran tráfico como Steam, Canva, Amazon, Coinbase, Reddit, Disney+, entre otros, dibujando un mapa de caída global en términos de alcance, aunque con origen regional.
Además, usuarios reportaron cortes y problemas de conexión en videojuegos online, y aquí las olas también llegaron al ocio: hubo quejas sobre interrupciones en títulos masivos. De hecho, muchos jugadores señalaron que incluso juegos como Clash of Clans y Fortnite se vieron afectados por la inestabilidad general. Estos reportes encajan con lo observado en servicios de monitorización pública y redes sociales durante el pico de la incidencia.
El talón de Aquiles: centralización y dependencia de US-East-1
US-East-1 no es “una región más”: alberga servicios base y metadatos que otras regiones consultan, de ahí que una caída allí pueda “arrastrar” comportamientos anómalos fuera de su perímetro. Aunque otras regiones siguieran respondiendo, el efecto cascada (timeouts, reintentos, saturaciones) es real y fue una de las claves para entender por qué un fallo localizado generó un impacto tan amplio.
Este episodio reabre el debate sobre la excesiva centralización en un puñado de nubes y regiones: cuando todo apunta a un mismo punto crítico, el riesgo sistémico aumenta.
SLA, dinero y responsabilidades: lo que sí (y lo que no) cubre la nube
Los SLA (acuerdos de nivel de servicio) prometen disponibilidades del estilo 99,9%–99,99% y, si no se cumplen, créditos en la factura. Pero ojo: eso no elimina la necesidad de arquitecturas robustas. En enterprise, además, los contratos son ad hoc y varían por servicio y por cliente, así que no existe un “SLA universal” aplicable a todos. Cuando un incidente se alarga, las compensaciones económicas pueden ser sustanciales… pero el negocio parado no se recupera con créditos.
Aquí hay responsabilidad compartida: AWS ofrece herramientas para alta disponibilidad, multi-AZ y failover; las empresas deben diseñar para fallos. El problema viene cuando la misma región es tu punto único de verdad.
Paneles de estado y termómetro social
Mientras el AWS Health/Status informaba de avances y trabajos en curso, los gráficos de servicios de terceros y el ruido en redes dibujaron la otra cara: picos abruptos de reportes, cadenas de errores y latencias imposibles. Esa combinación, panel oficial + telemetría comunitaria explica por qué algunos servicios parecían “medio vivos” y otros directamente cayeron durante tramos prolongados.
En paralelo, proveedores alternativos aprovecharon para reivindicarse (como Hetzner), y la conversación derivó hacia multinube, diversidad de regiones y desconcentración como pilares estratégicos tras incidentes de este calibre.
