Cómo comprobar si AWS está caído: guía práctica y señales fiables

Inicio » Software » Cómo comprobar si AWS está caído: guía práctica y señales fiables

Cuando un servicio que usas a diario empieza a fallar y sospechas de una caída en la nube de Amazon, lo normal es preguntarse si se trata de un problema general o de algo puntual en tu aplicación. En este artículo te contamos cómo comprobar si una web funciona en pocos minutos si AWS está teniendo una interrupción real, cómo distinguir un fallo global de uno local en tus instancias y qué ocurrió en la última gran incidencia que sacudió la región US-EAST-1. Aportamos contexto, señales y medidas concretas para actuar con cabeza, con un tono cercano y sin rodeos, destacando las fuentes oficiales más fiables y las comprobaciones técnicas clave.

Más allá de la anécdota, entender el ecosistema de AWS ayuda a leer mejor los síntomas: desde EC2, S3 o DynamoDB hasta IAM, CloudWatch o CloudFront, todo está conectado. Cuando una pieza se tuerce, la repercusión puede ser enorme. Te guiamos paso a paso por lo esencial que debes mirar, incluyendo cómo funcionan los eventos públicos de AWS Health, qué te dicen las comprobaciones de estado de EC2 y qué pistas ofreció el último incidente sonado. Así podrás reaccionar con rapidez y basarte en datos de paneles oficiales, métricas y alarmas.

Cómo saber al instante si AWS está caído

La fuente más directa para verificar un problema global es el panel de salud público de AWS. Desde finales de 2023, al abrir un evento público reciente, el navegador completa la URL con un enlace permanente a ese incidente. Esto es muy útil porque, al compartir o guardar ese enlace, vuelves exactamente a la vista de lista de eventos con la ventana emergente del suceso ya abierta, lo que facilita confirmar el estado en curso y revisar el histórico. En la práctica, si ves un evento activo, con descripción y evolución, ya tienes una prueba sólida de que no eres tú: hay un problema reconocido por AWS.

Cuando entres en esos eventos públicos, fíjate en dos aspectos: la región afectada y el tipo de servicios mencionados. A veces el problema es regional, por ejemplo sólo US-EAST-1, y otras afecta a componentes globales que dependen de esa región, como actualizaciones de IAM o tablas globales de DynamoDB. Encontrarás notificaciones que indican si se han identificado causas, si se aplican mitigaciones o si se recomienda a los clientes reintentar solicitudes que fallan, señal de que la recuperación está en marcha pero puede tardar.

Además de los paneles oficiales, las señales de la comunidad ayudan a tomar el pulso. Sitios de reporte de caídas y redes sociales suelen detectar picos de errores muy rápido. En algunos casos verás menciones a plataformas masivas, como la caída de GitHub, servicios de mensajería, juegos, streaming o periódicos digitales reportando fallos simultáneos. No es prueba definitiva, pero cuando coincide con un evento en AWS Health, el diagnóstico es claro. Incluso portales especializados con secciones o áreas de Members destacaron en su momento información y seguimiento minuto a minuto, lo que refuerza la visibilidad sobre el alcance real de la incidencia.

Una pista adicional llega de tu propia observación: puede que una aplicación te funcione y otra no, o que un compañero tenga problemas con Alexa y a ti te vaya bien Prime Video. Esto sucede porque las peticiones se enrutan a infraestructuras diferentes o a zonas no afectadas. Esa inconsistencia es típica en incidentes complejos y no invalida que exista un problema en AWS; al contrario, suele indicar que el alcance es amplio pero no uniforme, y que la recuperación es progresiva por zonas o servicios.

Descarta fallos propios: comprobaciones de estado en EC2

Antes de culpar a la nube, conviene mirar tus instancias. EC2 ejecuta comprobaciones automáticas cada minuto para detectar problemas de hardware y software que puedan impedir a una instancia ejecutar aplicaciones. Estos chequeos devuelven un estado global: si todas las verificaciones pasan, verás OK; si alguna falla, la instancia figura como impaired. Estas comprobaciones, que no pueden deshabilitarse ni eliminarse, complementan el estado previsto de la instancia, como pending, running o stopping, y ayudan a diferenciar una caída general de un fallo local que te toca arreglar. Es decir, son tu primera línea de diagnóstico interno.

Cuando falla una verificación, AWS incrementa la métrica de CloudWatch correspondiente, de modo que puedes configurar alarmas y automatizaciones. Por ejemplo, si una instancia queda deteriorada por un problema subyacente, es posible habilitar la recuperación automática para que el sistema actúe sin intervención manual. También puedes crear alarmas específicas que te avisen cuando fallen los chequeos en una instancia concreta, algo muy útil para acotar el impacto mientras evalúas si el panel de salud público indica un incidente mayor o sólo estás ante un contratiempo propio.

Tipos de comprobaciones de estado

EC2 contempla varios tipos de chequeos. Las comprobaciones del sistema monitorizan la infraestructura de AWS que hospeda tu instancia y detectan problemas que requieren intervención de AWS: si fallan, se incrementa la métrica StatusCheckFailed_System. Para instancias respaldadas por EBS, puedes intentar detener e iniciar la instancia para provocar su migración a otro host, lo que en muchos escenarios resuelve el síntoma. Para instancias basadas en almacén de instancias compatibles en Linux, la alternativa sería terminar y reemplazar, teniendo en cuenta que esos volúmenes son efímeros y al detenerse se pierden los datos.

Las comprobaciones de la instancia, por su parte, vigilan la conectividad de red y el software del propio sistema. EC2 valida el estado enviando una solicitud ARP a la interfaz de red, lo que le permite detectar fallos que debes resolver tú, como un reinicio, cambios de configuración o un servicio que no responde. Si este tipo de chequeo falla, verás aumentar StatusCheckFailed_Instance y será el momento de actuar sobre tu sistema. En instancias Bare Metal, un reinicio desde el sistema operativo puede provocar temporalmente un fallo de estado, pero al volver a estar disponible debería pasar a aprobado, así que no te alarmes si detectas ese comportamiento durante operaciones de mantenimiento.

Existe además una verificación para volúmenes EBS adjuntos, que comprueba la accesibilidad y que se completan operaciones de E/S. La métrica StatusCheckFailed_AttachedEBS señala problemas si uno o varios volúmenes no pueden completar esas operaciones. Es útil para aumentar la resiliencia: con una alarma de CloudWatch puedes disparar una conmutación por error a otra instancia o a otra zona si detectas un impacto prolongado, o monitorizar el rendimiento de cada volumen con métricas de EBS y reemplazar el afectado. Si tu carga no está haciendo E/S y la comprobación indica deterioro, detener e iniciar la instancia para moverla a un host nuevo puede solucionar el origen, porque a veces lo que falla es el host subyacente y no tu volumen en sí.

Si trabajas con Auto Scaling, también puedes configurar el grupo para que detecte errores de la comprobación de EBS adjunto y reemplace la instancia afectada por una nueva. Algo parecido aplica cuando fallan las del sistema o de instancia: una política de reemplazo puede contener el impacto. Todo esto complementa las alarmas de CloudWatch por uso de CPU, red o disco, de manera que, con el conjunto de métricas y alarmas, tengas una imagen más completa del estado real de tus cargas y sepas si estás ante un problema de plataforma o ante un fallo local que se corrige con tus propias manos.

Qué pasó en la gran caída reciente de US-EAST-1

Una interrupción destacada tuvo lugar entre las 23:49 PDT del 19 de octubre y las 15:01 PDT del 20 de octubre, con la hora de Chile marcando 03:49 al inicio y 19:01 al cierre aproximado. En las primeras fases se observaron tasas elevadas de error y latencias en múltiples servicios de la región US-EAST-1, con impacto directo en Amazon.com y en operaciones de soporte. Para estabilizar el plano de control, se llegaron a aplicar mitigaciones como limitar temporalmente lanzamientos de EC2, lo que evidencia hasta qué punto la presión sobre el control plane puede obligar a tomar medidas excepcionales cuando la degradación se generaliza.

El diagnóstico temprano apuntó a un problema de resolución de DNS en puntos finales regionales de Amazon DynamoDB. Poco después de la medianoche, a las 00:26 AM PDT del día 20, se identificó que la causa del evento se encontraba en esa resolución DNS, impidiendo que componentes dependientes resolvieran direcciones para sus tablas o consultas. Hay una metáfora que lo explica bien: es como si el sistema de direcciones de una ciudad se apagara; los servicios saben adónde quieren ir, pero no encuentran la ruta. En esos momentos, la recomendación para clientes fue reintentar las solicitudes que fallaban, mientras se trabajaba por vías paralelas para acelerar la recuperación, con la advertencia de que servicios y funciones globales que dependen de US-EAST-1, como actualizaciones de IAM o tablas globales de DynamoDB, también podrían verse afectados y que incluso crear o actualizar casos de soporte podría no estar disponible, por lo que conviene mantener la calma y los reintentos.

Más tarde se describió una degradación en un subsistema interno de la red de EC2 vinculado a la monitorización de la salud de los Network Load Balancers. La analogía de los semáforos descoordinados viene al pelo: cada servicio seguía encendido, pero el sistema que los mantenía sincronizados no mandaba señales de control de forma correcta. Eso provoca bloqueos, duplicidad de rutas y pérdidas intermitentes en la infraestructura. A media mañana, en torno a las 08:43 AM PDT, se señaló ese subsistema como origen de varios de los síntomas observados en cadena, lo que, sumado a la raíz en DNS para DynamoDB, dibujó un cuadro complejo con causas entrelazadas que afectaban a cómputo, bases de datos y monitorización, y que terminó por manifestarse como una caída visible para millones de usuarios que dependen de esa región crítica.

¿Qué consecuencias se vieron fuera de los paneles? Hubo servicios muy populares con problemas: Amazon Alexa, plataformas de aprendizaje como Duolingo, redes como Snapchat, videojuegos como Fortnite o Roblox, medios como The New York Times, servicios de streaming como Apple TV, utilidades como Life360, páginas de comercio electrónico de Amazon y compañías de restauración y retail de primer nivel. Se reportaron afectaciones en compañías europeas, incluidas telecomunicaciones como BT o Vodafone, y bancos del Reino Unido como Lloyds o Halifax. Varios usuarios detectaron comportamientos erráticos en herramientas de IA en la web, con momentos en que una persona accedía sin problema y otra no, mostrando la cara más confusa de estas incidencias: contrastes fuertes que responden a diferencias en rutas, caches y zonas parcialmente degradadas.

En España, aunque no se confirmó una caída total exclusiva, sí se observaron efectos derivados. Según distintos testimonios, las Islas Canarias se llevaron una parte importante del impacto, con comercios, restaurantes y gasolineras operando solo en efectivo por la caída de datáfonos, cajeros automáticos y Bizum. También se vivieron ventanas con comportamiento irregular, lo que explica por qué algunos decían que todo les funcionaba y otros sufrían errores sin descanso. Es exactamente el patrón que se ve cuando el núcleo de la infraestructura muestra picos de latencia, nombres que no resuelven o balanceadores que no terminan de repartir carga de forma estable.

Si miramos la cronología comunicada en horario europeo, hubo reportes a partir de las 09:11 de la mañana en Madrid, con confirmaciones de incremento de errores cuarenta minutos más tarde. Alrededor de las 11:01 se indicó que la posible causa raíz estaba en la resolución de DNS en la API de DynamoDB en US-EAST-1 y antes de mediodía, hacia las 11:22, se aplicaron las primeras mitigaciones con signos de recuperación en algunos servicios. Pasado el mediodía, en torno a las 12:03, se informó de una mejora sostenida, aunque con colas de peticiones aún acumuladas, un clásico en cualquier recuperación: la normalización avanza, pero esas colas tardan en vaciarse. Durante todo ese periodo, se insistió en que los clientes reintentaran peticiones fallidas, una táctica que, combinada con backoff exponencial en las aplicaciones, ayuda a no saturar más mientras se despeja la congestión interna.

Varias voces del sector pusieron el foco en la dependencia de unas pocas plataformas; un ejemplo fue la gran caída de Microsoft 365. Expertos de seguridad apuntaron que, sea por error humano, fallo técnico o ciberataque, el problema de fondo es la excesiva concentración de infraestructura que sostiene servicios en línea. También recordaron casos recientes de interrupciones masivas en otros proveedores que provocaron caos global, reforzando la idea de que una cadena digital con eslabones clave concentrados puede generar efectos dominó si uno falla. Todo ello nos devuelve a un meme bien conocido entre ingenieros que ilustra la fragilidad de Internet cuando gran parte del tráfico descansa en unos pocos pilares: si uno se tambalea, medio ecosistema se resiente en cascada.

Qué hacer durante y después: señales, prácticas y arquitectura

Durante una caída, céntrate en lo esencial. Confirma el evento en el panel de salud público, guarda el enlace del incidente para seguir la evolución y aplica reintentos controlados en tus clientes. Si tus métricas de EC2 muestran fallos locales, actúa: reinicia cuando aplique, detén e inicia para forzar migración en respaldadas por EBS o deja que la recuperación automática haga su trabajo si la has habilitado. Si ves que sólo fallan tus comprobaciones de instancia o EBS adjunto mientras el panel no refleja un evento general, la pelota está en tu tejado; en cambio, si el panel indica problemas en tu región, baja el ritmo de despliegues y evita cambios de infraestructura hasta que el plano de control recupere estabilidad.

Para el medio plazo, toma apuntes. Incidentes como el de US-EAST-1 muestran que conviene diseñar con redundancia regional y planes de contingencia. Cuando sea viable, considera arquitecturas multi región para componentes críticos, o al menos failover entre zonas de disponibilidad con replicación adecuada. Evalúa dependencias con servicios de nombres, balanceadores y bases de datos, y cómo reaccionan tus clientes ante DNS que no responde o latencias prolongadas. Revisa también alarmas y dashboards: una buena cobertura con CloudWatch, incluyendo las métricas StatusCheckFailed_System, StatusCheckFailed_Instance y StatusCheckFailed_AttachedEBS, te ahorra minutos valiosos a la hora de separar lo global de lo local y empezar a ejecutar acciones automáticas de contención.

Recuerda que AWS aglutina una enorme variedad de servicios que amplifican el impacto cuando algo se tuerce. En el día a día conviven cómputo, almacenamiento, colas, bases de datos, identidad, redes, CDN y más. A modo de referencia, piensa en piezas como: S3, EC2, SQS, RDS, DynamoDB, IAM, CloudFormation, AWS CDK, Route 53, CloudFront, Lambda, VPC, CloudWatch, Glacier y otros muchos. Esa interdependencia explica por qué los fallos de DNS en un punto final de DynamoDB pueden traducirse en fallos en cadena. Por eso, a nada que puedas, introduce patrones de resiliencia, reintentos con backoff, timeouts correctos y caminos alternativos que reduzcan tu tiempo de indisponibilidad percibida por el usuario.

Un apunte práctico sobre comunicación: si la página de estado indica degradación pero recuperación en progreso, evita anuncios definitivos de normalidad hasta que tus métricas confirmen estabilidad. Aunque el proveedor avance, es habitual que queden colas por procesar o efectos colaterales. También notarás que no todos los clientes o regiones lado usuario se recuperan a la vez. Mantén mensajes claros con recomendaciones sencillas, como reintentar, y comparte el enlace del evento público para que cualquiera pueda consultar la situación de primera mano y no depender de especulaciones en redes sociales.

Para cerrar el círculo, vuelve a tus comprobaciones de EC2 cuando todo pase. Revisa logs de fallos de estado, si hubo reinicios o migraciones de host y si las alarmas saltaron cuando debían. En instancias Bare Metal, recuerda que un reinicio desde el sistema operativo puede marcar temporalmente fallo en la verificación; si eso enturbió tus paneles, documenta el comportamiento para no asustarte en la próxima ventana de mantenimiento. Documentar lo ocurrido y lo que funcionó te prepara mejor para la siguiente incidencia, porque, aunque molestas, forman parte de la vida en la nube y la diferencia está en cómo respondes y aprendes.

Mirando el cuadro completo, hoy ya sabes dónde comprobar si hay una caída real en AWS, cómo usar los eventos públicos con enlaces directos para seguir incidentes, qué te cuentan las comprobaciones de estado de EC2 sobre tus instancias y por qué un fallo de DNS en DynamoDB o una degradación en la salud de los Network Load Balancers puede impactar a medio mundo. Con estas piezas, y apoyándote en métricas y alarmas, estarás mejor preparado para distinguir un corte global de un problema local y reaccionar con rapidez, reduciendo el tiempo en que tus usuarios sienten que Internet se ha roto.

Artículo relacionado:

Verificar el estado de un servidor web: guía práctica y herramientas