La mañana del lunes, 20 de octubre, millones de personas en todo el mundo se toparon con la misma pantalla en sus móviles y ordenadores: servicios que no cargaban, asistente de voz que no respondía, juegos que no iniciaban y apps que fallaban. El motivo fue una incidencia de gran alcance en Amazon Web Services (AWS), la nube de Amazon sobre la que funcionan desde Alexa, Prime Video, Snapchat o Fortnite hasta herramientas de trabajo como Airtable, Canva o Zoom, pasando por plataformas de inteligencia artificial como ChatGPT y Perplexity.
El panel de estado de AWS situó el epicentro en US-EAST-1 (N. Virginia), su región más concurrida, con un “aumento de tasas de error y latencias” en múltiples servicios. En España, portales de monitorización de fallos empezaron a detectar problemas en torno a las 08:40 (hora peninsular), y las redes sociales se llenaron de testimonios: Alexa no cumplía rutinas ni alarmas, videojuegos muy populares se quedaban colgados, y webs y apps devolvían errores de conexión. La causa exacta no se había confirmado durante las primeras horas, pero sí el alcance: impacto global con intensidad variable según región y servicio.
“Perplexity está caído ahora mismo. La causa raíz es un problema de AWS. Estamos trabajando para resolverlo”, publicó en X el director ejecutivo de la compañía, Aravind Srinivas, resumiendo lo que muchos equipos técnicos estaban viviendo en paralelo.
¿Por qué una caída de AWS afecta a tantas cosas a la vez?
La computación en la nube permite alquilar por Internet la potencia de cómputo, el almacenamiento y las bases de datos que antes estaban en los racks de una empresa. Es flexible, escalable y, normalmente, más eficiente. Pero esa misma ventaja genera concentración: si un gran proveedor como AWS sufre una incidencia relevante en una región clave, el efecto dominó se siente en miles de servicios que dependen de ella para iniciar sesión, procesar datos, servir imágenes o responder a una petición.
US-EAST-1, en concreto, es una región histórica y muy demandada por la variedad de servicios que ofrece y por su coste. Muchas empresas concentran allí parte de su plano de control (autenticación, colas de mensajería, catálogos, DNS internos), de modo que una degradación en esos componentes no solo afecta a las aplicaciones alojadas en N. Virginia: “ripplea” hacia otras regiones y se traduce en fallos intermitentes en Europa, Asia u otro punto del mapa.
En lenguaje llano: medio Internet comparte “autopista”. Si se forma un gran atasco en uno de sus nudos, se resiente el tráfico de carriles y salidas que, a priori, estaban lejos del problema.
Esto ya ha pasado otras veces (y probablemente volverá a pasar)
No es la primera vez que US-EAST-1 salta a los titulares. En 2020, 2021 y 2023 se produjeron incidentes con horas de disrupción y efectos generalizados. Cada nuevo episodio reabre un debate incómodo: ¿dependemos demasiado de unos pocos hiperescalares? Quienes defienden que “no pasa nada porque nos afecta a todos” olvidan que no todos los servicios tienen el mismo umbral de tolerancia a una caída. Para un videojuego puede ser una molestia; para un comercio electrónico o una entidad financiera, minutos de interrupción son pérdidas y reputación en juego.
Lo que vieron los usuarios… y lo que vieron las empresas
Para el gran público, los síntomas fueron claros: páginas que no cargaban, códigos de error (5xx), imposibilidad de subir o descargar contenido, o asistentes que no respondían. En el lado empresarial, los equipos de TI observaron picos de latencia en APIs, errores intermitentes de autenticación, colas que se acumulaban y funciones que hubo que desactivar temporalmente para evitar males mayores.
En Europa, el cuadro fue desigual. Hubo servicios que aguantaron, otros que degradaron sus funciones y otros que cayeron del todo. La diferencia la marcó, en gran parte, cómo estaban diseñadas esas plataformas: multi-AZ (múltiples zonas en una región), multi-región real, o monorregión con el “todo” en N. Virginia.
Lecciones para todos: de la casa al Data Center
1) Como usuarios, la mejor reacción es la paciencia. Reinstalar apps o borrar datos no arregla una avería del proveedor. Comprobar la página de estado del servicio y la de AWS ayuda a distinguir si el problema es local (nuestro equipo o red) o general. Muchas plataformas se recuperan por tramos a medida que el proveedor mitiga el incidente.
2) Como empresas, la caída vuelve a subrayar la importancia de dimensionar los sistemas en función de lo que realmente podemos permitirnos perder cuando hay un fallo. Es el idioma de dos siglas que conviene tener pegadas a la pantalla: RTO (tiempo objetivo de recuperación) y RPO (punto objetivo de recuperación). Dicho en sencillo: ¿cuánto tiempo puede estar fuera de servicio nuestra aplicación sin que sea catastrófico, y cuántos datos podemos perder como máximo si recuperamos desde una copia? No es lo mismo aceptar 30 minutos de corte que 30 segundos; y no es lo mismo asumir un RPO de 5 minutos (algo de dato perdido) que de 0 (nada).
David Carrero, cofundador de Stackscale – Grupo Aire (empresa española de infraestructura cloud), lo resume así:
“Tenemos que dimensionar nuestras infraestructuras en función del RTO y el RPO que podemos soportar. Si no podemos permitirnos una caída de minutos u horas, debemos diseñar dos sistemas que, en caso de que uno falle, el otro no dependa para nada del primero. Eso es una arquitectura de misión crítica y una alta disponibilidad real”.
En la práctica, “dos sistemas que no dependan el uno del otro” significa multi-región (o multi-proveedor) de verdad, con datos y control replicados y pruebas periódicas de conmutación por error. No basta con duplicar servidores dentro de la misma zona si los servicios internos que todos comparten son el cuello de botella cuando hay un incidente regional.
¿Qué pueden hacer las empresas para sufrir menos en la próxima caída?
- Diseño multi-AZ y multi-región donde el negocio lo justifique. Distribuir planos de control y bases de datos en más de una región evita que un fallo localizado tire todo el sistema.
- Colas y reintentos inteligentes. Hacer que las operaciones se reintenten con backoff y sean idempotentes (no pasen cosas raras si se repiten) evita cascadas de errores.
- Backups con objetivos claros (RTO/RPO). Si el RPO es 0, no sirve una copia de ayer; si el RTO es minutos, hay que ensayar la recuperación.
- “Gamedays” y simulacros. No basta con tener el plan: hay que probarlo en frío y en caliente. Las conmutaciones que nunca se ensayan fallan cuando más se necesitan.
- Observabilidad y comunicación. Métricas, alarmas bien calibradas y mensajes claros a clientes y equipos reducen la angustia en mitad del temporal.
¿Y si no quiero depender tanto de un único gigante?
Aquí la conversación suele dividirse. Unos dicen: “la nube de un hiperescala me da años de ingeniería en bandeja”. Otros responden: “tanta dependencia no trae nada bueno cuando hay caídas”. La realidad está en el equilibrio: aprovechar lo que ofrece un gran proveedor, pero diseñar pensando en el fallo. Eso pasa por no tener el “todo” en una sola región, por automatizar la conmutación y por presupuestar la resiliencia en el coste del proyecto. No es gratis, pero tampoco lo es parar el negocio.
En entornos realmente críticos, hay organizaciones que optan por infraestructura privada en centros de datos especializados, o por soluciones híbridas donde conviven nube pública y infra privada. En escenarios extremos, se utilizan almacenamientos síncronos activo-activo entre dos centros de datos (RTO=0 / RPO=0), o doble proveedor para que, si uno falla, el otro siga sin depender de él.
Como apunta David Carrero (Stackscale):
“Las palancas existen —HA real, DR multi-sede, almacenamiento síncrono—. Lo importante es alinearlas con el RTO/RPO del negocio. Si el objetivo es cero (RTO=0, RPO=0), el diseño y el coste tienen que estar a esa altura”.
Un recordatorio útil para el día a día
La caída de AWS dejó una estampa que cualquiera puede entender: no encendían las luces de casa con la voz, la serie no cargaba, el juego online no conectaba, la app de trabajo se colgaba. Al margen del impacto técnico, lo que se nos quedó a muchos es una idea sencilla: dependemos de la tecnología más de lo que pensamos. Y eso implica cuidar nuestras conexiones digitales —y exigir que quienes las construyen lo hagan con resiliencia en mente.
No se trata de demonizar a los grandes proveedores —que, por otro lado, mantienen niveles de servicio altísimos a lo largo del año—, sino de asumir que las incidencias forman parte del juego y que la mejor defensa sigue siendo un buen diseño.
Preguntas frecuentes
¿Qué es US-EAST-1 y por qué su caída afecta a servicios en todo el mundo?
US-EAST-1 (N. Virginia) es una de las regiones más grandes y veteranas de AWS. Muchas plataformas concentran allí cargas críticas y planos de control. Cuando hay una incidencia en esa región, se producen errores y latencias que pueden propagarse y degradar servicios en otras partes del mundo.
¿Qué servicios se vieron afectados durante la caída de AWS?
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 cada arquitectura y región.
¿Cómo puede mi empresa reducir el impacto de futuras caídas?
Adoptando multi-AZ y, cuando proceda, multi-región, separando control y datos, usando colas con reintentos e idempotencia, ensayando conmutaciones (gamedays) y fijando RTO/RPO realistas. Si no se puede tolerar interrupción ni pérdida de datos, valorar infraestructura de misión crítica con HA real y, llegado el caso, almacenamiento síncrono activo-activo (RTO=0 / RPO=0).
¿Qué significan RTO y RPO y por qué importan?
RTO (Recovery Time Objective) es el tiempo máximo que puedes estar caído antes de que el daño sea inaceptable. RPO (Recovery Point Objective) es la cantidad de datos que estás dispuesto a perder al recuperar. Si tu RTO/RPO es 0, necesitas dos sistemas independientes (o multi-región) para que, si uno falla, el otro siga sin depender del primero. Como dice David Carrero (Stackscale): “el diseño debe estar a la altura del RTO/RPO que el negocio se puede permitir”.
