La mañana del lunes, 20 de octubre, millones de personas descubrieron que cosas tan habituales como pedirle a Alexa que encienda las luces, compartir un archivo en Canva o echar una partida a Fortnite no funcionaban como siempre. El motivo: una incidencia de gran alcance en Amazon Web Services (AWS), la nube de Amazon que da soporte a buena parte de los servicios que usamos a diario.
El panel de estado del proveedor señaló el epicentro en US-EAST-1 (N. Virginia) con “aumento de tasas de error y latencias en múltiples servicios”. En España, portales de monitorización empezaron a registrar fallos alrededor de las 08:40 (hora peninsular). La lista de plataformas afectadas fue larga: además de Amazon, Alexa y Prime Video, hubo problemas en Snapchat, Fortnite, Epic Games Store, Epic Online Services, ChatGPT, Perplexity, Airtable, Canva, Duolingo, Zoom, la app de McDonald’s, Roblox o Clash Royale. En redes sociales, usuarios y responsables de producto confirmaron la degradación:
“Perplexity está caído ahora mismo. La causa raíz es un problema de AWS. Estamos trabajando para resolverlo”, publicó en X Aravind Srinivas, director ejecutivo de la compañía.
La causa exacta no se había aclarado durante las primeras horas, pero sí el alcance global y la naturaleza intermitente de los fallos: algunos servicios funcionaban por ratos, otros cargaban a medias y otros no respondían.
Por qué una avería “en Virginia” deja tiritando a medio Internet
La nube funciona como una gran red de centros de datos repartidos por el mundo y organizados en regiones. US-EAST-1 (N. Virginia) es histórica, muy grande y con un catálogo amplio de servicios. Muchas empresas alojan allí piezas críticas de sus sistemas —desde procesos de autenticación hasta colas de mensajería o DNS internos— por costes, latencia o simple inercia.
Si una región así se degrada, el impacto no se queda dentro de sus fronteras. Se produce un efecto dominó: los fallos en planos de control compartidos acaban rippleando hacia otras regiones y degradando funciones en Europa, Asia o donde toque. Por eso ayer hubo servicios europeos que seguían activos pero fallaban en el inicio de sesión, no cargaban imágenes o sufrían picos de latencia.
En términos cotidianos: muchas apps “comparten autopista” para tareas esenciales. Si hay un gran atasco en un nudo de esa autopista, se resiente el tráfico incluso en salidas que, sobre el mapa, parecen lejos del problema.
Qué vieron los usuarios… y qué observaron las empresas
Para el usuario de a pie, los síntomas fueron claros y molestos:
- Páginas que no cargaban o devolvían errores 5xx.
- Asistentes de voz que no respondían y rutinas (incluidas alarmas) que no se ejecutaban.
- Apps de trabajo que no guardaban cambios o no permitían subir archivos.
- Juegos online que no conectaban con los servidores.
Para los equipos de TI, el cuadro fue más técnico: latencias fuera de rango en APIs, errores intermitentes de autenticación, colas de mensajes acumulándose, piezas que hubo que desactivar temporalmente para evitar cascadas de fallos y paneles de estado echando humo.
La foto en Europa fue desigual: hubo servicios que aguantaron, otros que degradaron y otros que cayeron por completo. La diferencia, casi siempre, estuvo en cómo estaban diseñadas esas plataformas: si tenían múltiples zonas dentro de una región (multi-AZ), si estaban desplegadas en más de una región (multi-región) o si, por el contrario, dependían de un único punto de fallo en US-EAST-1.
Esto ya ha pasado… y volverá a pasar
US-EAST-1 ha protagonizado incidencias sonadas en 2020, 2021 y 2023. Cada episodio reabre el debate sobre nuestra dependencia de unos pocos hiperescalares (los grandes proveedores de nube). Hay quien quita hierro: “si cae uno de los grandes, nos caemos todos y no pasa nada”. La realidad es que no todos los servicios soportan igual una interrupción: para un juego puede ser una molestia; para un comercio electrónico, una banca o un operador logístico, minutos de caída son pérdidas y reputación en juego.
RTO y RPO: dos siglas que deberían guiarnos
En momentos así, conviene hablar claro de riesgos y objetivos de continuidad. Dos siglas mandan: RTO (Recovery Time Objective) y RPO (Recovery Point Objective).
- RTO es el tiempo máximo que una aplicación puede estar caída antes de que el daño sea inaceptable.
- RPO es la cantidad de datos que estamos dispuestos a perder como máximo al recuperar (el “punto” al que volveríamos).
David Carrero, cofundador de Stackscale – Grupo Aire (empresa española de infraestructura cloud), lo explica en términos sencillos:
“Hay que dimensionar la arquitectura según el RTO y el RPO que de verdad podemos soportar. Si no podemos tolerar ni minutos ni pérdida de datos, la respuesta no es cruzar los dedos: necesitamos dos sistemas capaces de seguir funcionando sin depender uno del otro. Eso es alta disponibilidad real y arquitectura de misión crítica”.
Traducido a diseño: multi-región de verdad, datos y control replicados, y pruebas periódicas de conmutación por error (failover). Tener copias dentro de la misma zona no basta si el servicio común del que dependen todas las piezas es el que falla.
Qué pueden hacer las empresas para sufrir menos la próxima caída
- Separar zonas y regiones. Multi-AZ (varias zonas por región) es el mínimo en producción; multi-región donde el negocio lo exija. Separar planos de control y datos evita que un único incidente deje todo fuera de juego.
- Automatizar la resiliencia. Operaciones idempotentes, colas con reintentos y backoff, timeouts bien definidos y circuit breakers evitan tormentas perfectas.
- Backups con objetivos claros. Si tu RPO es 0, una copia de ayer no te sirve; si tu RTO es minutos, tienes que ensayar la recuperación.
- Hacer “gamedays”. Probar cada cierto tiempo el failover y la degradación controlada. Lo que nunca se ensaya suele fallar cuando más hace falta.
- Observar y comunicar. Telemetría útil (no ruido), alertas bien calibradas y mensajes claros a clientes y equipos durante la incidencia.
Segundo apunte de David Carrero:
“No hay alta disponibilidad sin pruebas. La HA de PowerPoint no vale. O automatizamos y probamos a romper sin miedo —con datos protegidos— o estaremos descubriendo cómo falla todo el peor día posible”.
¿Y si no quiero depender tanto de un solo proveedor?
No hay respuesta única. Los grandes proveedores ofrecen escala, herramientas y capacidad que serían inalcanzables para una empresa media. Al mismo tiempo, concentrar todo en un único actor incrementa el riesgo cuando falla. El punto de equilibrio está en aprovechar lo mejor de cada mundo y diseñar pensando en el fallo:
- Multi-región dentro del mismo proveedor para mover carga cuando un área se degrada.
- Arquitecturas híbridas con una parte en nube pública y otra en infraestructura privada (por ejemplo, en centros de datos especializados).
- Multi-cloud para ciertos servicios, si el negocio lo justifica, sabiendo que la complejidad y el coste suben.
- En escenarios extremos, almacenamiento síncrono activo-activo entre dos centros de datos (RTO=0 / RPO=0) o doble proveedor para que, si falla uno, el otro siga sin depender de él.
Tercer apunte de Carrero:
“La continuidad se presupuesta. Si el objetivo del negocio es cero interrupción y cero pérdida de datos, el diseño y el presupuesto deben estar a esa altura. No hay magia: hay ingeniería y prioridades”.
Consejos prácticos (hoy) para usuarios y empresas
Para usuarios
- Verifica la página de estado del servicio y, si procede, la de AWS.
- Evita desinstalar o borrar datos: si el problema es del proveedor, no lo arreglarás desde tu equipo.
- Reintenta más tarde: la recuperación suele ser gradual.
Para empresas
- Evita cambios apresurados durante la incidencia; aplica solo mitigaciones con runbook probado.
- Si tienes multi-región preparada, conmuta carga de forma controlada.
- Comunica a usuarios y clientes qué se sabe, qué se ha desactivado temporalmente y cuándo habrá nuevas actualizaciones.
- Al volver a la normalidad, haz post-mortem: qué funcionó, qué no, cuánto te desviaste de RTO/RPO y qué vas a cambiar.
Un recordatorio para todos
La caída de AWS dejó escenas muy reconocibles: alarmas que no sonaron, luces que no obedecieron a la voz, series que no cargaron, documentos que no se subieron y juegos que no conectaron. Más allá del detalle técnico, es una llamada de atención sobre cuánto dependemos de la tecnología y sobre la responsabilidad de diseñarla para que falle lo menos posible… y se recupere bien cuando falla.
No se trata de demonizar a nadie: los grandes proveedores mantienen niveles de servicio altísimos el 99,9 % del tiempo. Pero las incidencias existen —y existirán—. La diferencia entre un susto y un desastre la marca la preparación.
Preguntas frecuentes
¿Qué es US-EAST-1 y por qué se habla tanto de esa región?
US-EAST-1 (N. Virginia) es una de las regiones más grandes y veteranas de AWS. Aloja muchos servicios críticos y planos de control que usan miles de plataformas. Por eso, una degradación allí puede propagarse e impactar a servicios de otras regiones con errores y latencias.
¿Qué servicios se vieron afectados durante la caída?
Hubo impacto total o parcial en Alexa, Prime Video, Snapchat, Fortnite, Epic Games Store, Epic Online Services, ChatGPT, Perplexity, Airtable, Canva, Duolingo, Zoom, la app de McDonald’s, Roblox, Clash Royale, entre otros. La intensidad dependió de la arquitectura de cada plataforma y de su dependencia de US-EAST-1.
¿Cómo puede mi empresa prepararse para futuras caídas de un gran proveedor cloud?
Adopta multi-AZ y, si el negocio lo exige, multi-región real; separa control y datos; usa colas e idempotencia para reintentos; fija RTO/RPO realistas y ensáyalos en gamedays. Si no toleras interrupción ni pérdida, diseña con HA real y, llegado el caso, almacenamiento síncrono activo-activo entre dos centros de datos.
¿Qué significan RTO y RPO y por qué son clave en una caída como esta?
RTO es el tiempo máximo admisible de inactividad; RPO es la cantidad de datos que puedes perder como máximo al recuperar. Si tu RTO/RPO es cero, necesitas dos sistemas independientes o multi-región para que, si uno falla, el otro siga sin depender del primero. Como insiste David Carrero (Stackscale), “el diseño debe estar a la altura de esos objetivos”.
