Cómo comprobar si AWS está caído: estado, causas y alcance real

Home » Python » Cómo comprobar si AWS está caído: estado, causas y alcance real

Cuando un servicio de Amazon Web Services deja de responder, medio internet lo nota al instante y la pregunta salta sola: ¿está AWS caído o es cosa de mi app? En las últimas horas se ha vivido una interrupción de gran alcance que ha afectado a redes sociales, bancos, juegos online, comercios electrónicos y administraciones públicas, poniendo en evidencia lo dependientes que somos de la nube de Amazon.

A continuación encontrarás una guía clara para comprobar el estado de AWS en tiempo real, un repaso detallado de lo que ha pasado, qué servicios se han visto afectados, por qué un problema de DNS en DynamoDB puede derivar en un efecto dominó, y qué dicen empresas, expertos y autoridades. Todo explicado en español de España, sin rodeos y con contexto para entender el alcance real.

Cómo comprobar si AWS está caído ahora mismo

La forma más directa y fiable es consultar los paneles oficiales. El panel público de AWS Health y la página de estado de AWS muestran incidentes activos, mitigaciones y servicios impactados por región. Desde septiembre de 2023 hay un cambio importante en la navegación: si haces clic en cualquier evento público, la URL del navegador se completa con un enlace directo a ese evento, y al abrirlo accederás a la vista de lista de eventos con la ventana emergente del incidente seleccionada para ir al grano.

Además del panel oficial, puedes cruzar señales con herramientas de terceros como los rastreadores de caídas. Plataformas como Downdetector agregan avisos de usuarios en tiempo real, útiles para detectar picos de fallos en servicios concretos. Eso sí, recuerda que son reportes comunitarios y pueden incluir falsos positivos; toma estos datos como complemento, no como veredicto definitivo.

Si gestionas sistemas, conviene que monitorices las regiones que más usas. La región US-EAST-1 (Norte de Virginia) es una de las más críticas porque aloja servicios troncales y muchísimas cargas de trabajo. Una incidencia allí puede sentirse en todo el mundo por su peso en la arquitectura global.

Por último, revisa el alcance del problema en tus propias dependencias: si tu app depende de DynamoDB, Lambda, CloudWatch, Route 53 o CloudFront, cualquier anomalía en estos componentes puede explicar latencias y errores. Y si necesitas información histórica del incidente, la vista de lista de AWS Health te facilitará seguir la línea temporal de comunicaciones y mitigaciones.

Qué ha ocurrido en la última caída de AWS

En la mañana del lunes, miles de usuarios en múltiples países comenzaron a reportar fallos al usar servicios de internet. Downdetector registró más de 4 millones de avisos en todo el mundo y más de 500 compañías afectadas, con problemas intermitentes que se extendieron durante horas. En Estados Unidos, el foco estuvo en Virginia del Norte, epicentro de la región US-EAST-1.

Las comunicaciones de AWS fueron escalando a lo largo de la mañana con hitos muy concretos. Primero se investigaron tasas elevadas de errores y latencias en múltiples servicios, más tarde se identificó una posible causa en las API de DynamoDB para US-EAST-1, después llegaron las primeras mitigaciones y señales de recuperación, y por último la confirmación de que el problema de DNS se había mitigado por completo.

• 08:11 (hora del Reino Unido): AWS indica que investiga tasas de error elevadas y latencias en varios servicios.
• 10:01: se identifica una posible causa raíz en las API de DynamoDB en US-EAST-1.
• 10:22: se aplican mitigaciones iniciales y aparecen señales tempranas de recuperación; algunos fallos pueden persistir.
• 10:27: se observan señales significativas de recuperación; la mayoría de solicitudes debería funcionar mientras se procesa el atraso.
• 12:35: el problema subyacente de DNS se declara completamente mitigado; la mayoría de servicios vuelve a operar con normalidad.

A pesar de la mitigación del núcleo del incidente, AWS avisó de errores persistentes al lanzar nuevas instancias EC2 y de procesos atrasados en servicios como CloudTrail y Lambda, normales tras una interrupción de este tipo cuando hay que digerir una montaña de eventos acumulados.

Servicios que se han visto afectados

El impacto ha sido transversal. Entre los servicios y plataformas con problemas se han contado redes sociales, juegos, banca, e-commerce y herramientas de trabajo. Esta es una muestra representativa de lo que han reportado usuarios y empresas:

• Redes y mensajería: Snapchat, Signal y también dificultades puntuales en Reddit.
• Trabajo y colaboración: Slack y Zoom con incidencias intermitentes.
• Ecosistema Amazon: Amazon.com, Alexa y dispositivos Ring con fallos de respuesta.
• Videojuegos y ocio: Roblox, Fortnite, Clash Royale, Clash of Clans, Wordle, Pokémon Go, Rocket League y Peloton con cortes o retrasos.
• Educación y creatividad: Duolingo y Canva con interrupciones.
• Banca y sector público (Reino Unido): Halifax, Lloyds Bank, Bank of Scotland, HMRC y secciones de Gov.uk, además de operadores y servicios como Sky, BT, EE, Vodafone y Virgin Media.
• Pagos y finanzas: Mercado Pago, Venmo con incidencias reportadas por usuarios, Coinbase y la app de inversiones Robinhood con afectación.
• Medios internacionales: webs de The Wall Street Journal y The New York Times con problemas de acceso.
• Perplejidad y asistentes: la plataforma de IA Perplexity reconoció caída por problemas de AWS.

En España también se notaron efectos. BBVA e ING registraron incidencias, y Movistar y Orange experimentaron problemas en determinados momentos. Además, Ticketmaster comunicó errores temporales en la compra de entradas, con Live Nation señalando que estaban monitorizando para restablecer la venta lo antes posible.

Conviene aclarar que, aunque hubo ruido sobre problemas de pagos con tarjeta, Redsys indicó que su caída fue puntual y ajena a la incidencia de AWS, limitada a un fallo parcial de su infraestructura de comunicaciones. Es decir, no todo lo que falló ese día estaba relacionado con la nube de Amazon.

Causas técnicas: DNS y el papel de DynamoDB

El eje del incidente estuvo en el Sistema de Nombres de Dominio. El DNS es la “guía telefónica” de internet: traduce nombres legibles (como un dominio) en direcciones IP que los navegadores y servicios pueden usar. Si el DNS falla, es como perder el mapa: los clientes no encuentran a dónde ir, por muy sano que esté el servicio detrás.

Durante el incidente, las API de DynamoDB en US-EAST-1 mostraron tasas elevadas de error y se identificó un problema de DNS como causa subyacente. La combinación de un servicio tan utilizado, con una región crítica, provocó un efecto cascada que acabó afectando a decenas de servicios. En una de las perspectivas disponibles se llegó a apuntar que hasta 113 componentes de AWS que dependían de DynamoDB se vieron salpicados.

Una vez aplicada la mitigación de DNS, la plataforma empezó a recuperar operaciones. Eso no impide que queden colas por procesar (backlogs), que se arrastren latencias y que algunas solicitudes sigan fallando temporalmente mientras se normaliza la carga. Es lo esperable tras un corte a gran escala.

Además, AWS comunicó que, pese a la recuperación general, las peticiones para lanzar nuevas instancias EC2 seguían arrojando tasas de error mayores a las habituales. Con el paso de las horas, estos flecos operativos fueron reduciéndose a medida que los equipos despejaban el atasco.

Una infraestructura que sostiene un tercio de internet

Para entender el alcance de un evento así hay que dimensionar a AWS. Millones de sitios y aplicaciones dependen diariamente de su infraestructura (computación, almacenamiento, bases de datos, redes, IA…). Análisis de BuiltWith sitúan a más de 76 millones de webs sobre AWS, y otras cifras apuntan a 76,8 millones en recuentos más recientes, con alrededor de 200.000 sitios en España.

El músculo de negocio de Amazon también habla por sí solo: AWS generó 107.600 millones de dólares en ingresos en el último año, consolidándose como líder del mercado por delante de Microsoft Azure y Google Cloud. Esa hegemonía implica que un tropiezo puntual, aunque esté acotado geográficamente, se note en medio mundo.

Periodistas tecnológicos han señalado que la relativa frecuencia de estos eventos revela la fragilidad del ecosistema. Cuando una pieza central falla, las repercusiones son amplias porque “tenemos más huevos en menos cestas”. Y como apuntó un profesor de la Universidad de Notre Dame, la recuperación puede provocar “fallos en cascada” durante la tarde a medida que se restablecen subsistemas, un comportamiento parecido al de un gran apagón eléctrico.

Este episodio también ha traído recuerdos recientes de otros fallos masivos, como el de 2024 con un proveedor de seguridad empresarial que, tras una actualización, acabó colgando equipos Windows en hospitales y aeropuertos. Diferentes causas, mismo patrón: vínculos críticos que, al fallar, interrumpen funciones clave en cadena.

Respuestas de empresas y administraciones

La cascada de comunicados fue extensa. Mercado Libre y Mercado Pago reconocieron inestabilidad provocada por un problema generalizado en AWS y aseguraron que trabajaban para restablecer el servicio. En el Reino Unido, HMRC indicó que sus usuarios tenían dificultades para acceder a servicios online por la incidencia global y recomendó paciencia hasta su resolución.

Desde la banca británica, Lloyds Bank lamentó las molestias y señaló que sus servicios volvían gradualmente a estar en línea. Halifax mostró mensajes de error explicando que no podían procesar solicitudes por problemas técnicos. Conforme avanzó el día, las entidades fueron confirmando el regreso a la normalidad.

En el terreno de los medios y el entretenimiento, Live Nation avisó de interrupciones que afectaban a Ticketmaster, impidiendo temporalmente la compra de entradas, mientras que publicaciones como The Wall Street Journal y The New York Times sufrieron problemas de acceso.

El ecosistema Amazon no quedó al margen: clientes reportaron fallos al completar compras en Amazon.com con mensajes del tipo “algo salió mal”, y altibajos en dispositivos Alexa. Aunque la mitigación de DNS llegó al mediodía, la recuperación plena tardó algo más por el volumen de solicitudes pendientes.

Expertos, responsabilidades y resiliencia

¿De quién es la culpa cuando falla la nube? La respuesta es matizada. Parte recae en el proveedor cuando el origen es interno, pero los expertos recuerdan que los clientes deben diseñar sus sistemas para tolerar fallos: utilizar redundancias, desplegar en varias zonas y regiones, y tener planes de continuidad y copias de seguridad para servicios críticos.

Voces como la del profesor Ken Birman (Universidad de Cornell) subrayan que muchas compañías no incorporan suficientes salvaguardas en sus aplicaciones. También se destaca el papel de la diversidad tecnológica: la resiliencia mejora cuando no se depende en exclusiva de un único proveedor, aunque a la escala que maneja AWS las alternativas reales se reducen a un puñado (Azure y Google Cloud, principalmente).

Desde el ángulo jurídico y de negocio, la búsqueda de responsabilidades puede acabar en los tribunales. Tras otra gran interrupción en el pasado, una gran aerolínea estadounidense reclamó más de 500 millones de dólares por pérdidas derivadas. La complejidad de estas infraestructuras hace que aislar la causa raíz y cuantificar daños sea una tarea difícil y prolongada.

Analistas y académicos consultados coinciden: la interdependencia es enorme y los “pequeños” errores humanos o de configuración pueden tener un impacto sistémico. Desarrollar resiliencia, garantizar diversidad y practicar planes de contingencia no es opcional para mantener la confianza y la continuidad de negocio.

España: cronología, impacto local y aclaraciones

En horario peninsular, la detección del fallo se situó alrededor de las 9:00. AWS informó de aumentos de latencias y errores en servicios de la costa este de Estados Unidos que impactaban a clientes globales, apoyándose en “múltiples alternativas en paralelo” para acelerar la recuperación.

Conforme pasaron las horas, el volumen de incidencias notificadas fue bajando casi a la mitad y, en torno a cuatro horas después de los primeros avisos, la compañía dio por mitigado el problema de DNS. Aun así, muchas plataformas siguieron recuperándose de manera escalonada por la carga acumulada.

Mientras tanto, en el debate público se atribuyeron a AWS algunas caídas que no tenían relación. Fue el caso de los pagos con tarjeta en la red Redsys, que aclaró que su incidente fue un problema puntual y parcial de su propia infraestructura de comunicaciones, sin vínculo con la avería de Amazon.

El balance final deja una lección clara: aunque un evento esté acotado geográficamente, su impacto puede ser global si afecta a servicios troncales y a una región tan relevante como US-EAST-1. Para el usuario final, se traduce en apps que no abren, pagos que no pasan y webs que no cargan.

Qué es AWS y por qué un fallo se nota tanto

Amazon Web Services es la división de nube de Amazon, un vasto entramado de centros de datos y servicios administrados que las empresas alquilan en vez de construir por su cuenta. En su catálogo conviven S3, EC2, SQS, RDS, DynamoDB, IAM, CloudFormation, AWS CDK, Route 53, CloudFront, Lambda, VPC, CloudWatch y Glacier, entre muchos otros.

Este modelo permite a compañías grandes y pequeñas lanzar productos globales con menos inversión inicial, delegando en AWS la compra de hardware, la conectividad, la replicación entre regiones y la operación 24/7. La contrapartida es la exposición a incidencias compartidas: cuando algo crítico falla en el proveedor, lo sufren miles de clientes a la vez.

Es tan común trabajar con estas herramientas que abundan sitios dedicados a noticias, artículos y utilidades sobre AWS, cubriendo desde buenas prácticas de seguridad hasta despliegues con CDK o la configuración avanzada de Route 53. Algunas de estas comunidades distinguen a sus miembros (Members), reforzando el intercambio de conocimiento entre profesionales.

Preguntas rápidas para detectar el alcance cuando “todo falla”

Si notas que varias apps distintas dan errores similares a la vez, piensa en una incidencia de plataforma. Comprueba AWS Health y el estado oficial y compara con un rastreador comunitario para ver si hay picos de reportes. Si usas servicios en US-EAST-1, pon el foco ahí.

Cuando el panel oficial confirme mitigación, recuerda que la recuperación no es instantánea: los backlogs tardan en vaciarse, los DNS necesitan propagarse y las nuevas instancias pueden devolver errores un rato hasta que todo se estabilice.

Si eres responsable técnico, pon en tu plan de continuidad una lista clara de dependencias y conmutaciones. Replicar datos y servicios críticos en varias zonas o regiones y documentar “runbooks” ahorra sustos cuando el reloj corre en tu contra.

Tampoco descartes problemas locales tuyos. Un fallo de red del ISP, una mala configuración de DNS o un despliegue reciente en tu propia aplicación pueden tener síntomas parecidos a una caída global. La confirmación cruzada evita conclusiones precipitadas.

Por último, si necesitas compartir un incidente concreto con tu equipo, aprovecha la función de enlace profundo: desde septiembre de 2023, al seleccionar un evento público de AWS Health, la URL del navegador ya incorpora el enlace directo y al abrirlo verás la lista con la ventana emergente de ese evento. Más fácil para poner a todos en la misma página.

Lo que dicen los números y las voces del sector

En el pico de la interrupción, Downdetector superó los 6,5 millones de denuncias a nivel global y señaló a más de 1.000 empresas afectadas en distintas franjas horarias. Aunque no es una fuente oficial, da una idea del ruido que provoca un evento de este calibre.

Expertos consultados insisten en que, aunque el problema de base se solucione, persisten “errores significativos” de recuperación en algunos servicios mientras el sistema digiere el atasco. La analogía del apagón es acertada: la luz puede volver, pero el restablecimiento integral lleva tiempo.

También se han planteado interrogantes sobre la responsabilidad compartida. Algunos señalan que muchas empresas confían demasiado en un único proveedor sin desplegar protecciones suficientes. Otras replican que, a la escala de AWS, la diversificación total es complicada. Entre ambas posiciones, la clave es elevar la madurez operativa y la arquitectura de resiliencia.

En el frente jurídico, no es descabellado que aparezcan reclamaciones por pérdidas cuando una gran parte de la actividad se ve frenada. Pero atribuir la causa precisa y su impacto económico raramente es simple, porque los sistemas están altamente integrados y la cadena de efectos no siempre es lineal.

Como comunidad técnica y de negocio, la conclusión operativa es inequívoca: hay que diseñar para el fallo. La pregunta no es si volverá a ocurrir algo, sino cuándo y con qué impacto. Prepararse marca la diferencia entre un susto y una crisis seria.

El episodio deja claro que comprobar si AWS está caído exige mirar fuentes oficiales y cruzar señales, entender que un fallo de DNS en una región crítica como US-EAST-1 puede sacudir medio internet, y aceptar que la recuperación conlleva colas, límites temporales y ajustes progresivos. La nube de Amazon sostiene buena parte de la red global, y aunque la arquitectura de internet resiste y se recupera, su interdependencia implica que los pequeños desajustes pueden tener efectos enormes. Conviene tenerlo presente y, sobre todo, prepararse en serio para el próximo sobresalto.