Cuando se habla de comprobar si AWS va fino o si está teniendo un tropiezo, no basta con mirar un semáforo verde o rojo: hay que cruzar el panel de salud, señales en tiempo real y revisiones concretas de tus recursos. Con ese enfoque combinado sabrás si el problema es general, regional o de tu propia infraestructura, y podrás actuar sin dar palos de ciego.
En esta guía te dejo todo bien hilado para verificar el estado de AWS con cabeza: desde el AWS Health Dashboard y su integración con EventBridge, hasta cómo ver el estado de renovación en ACM, interpretar los checks de EC2 y reaccionar con métricas y alarmas de CloudWatch. También encontrarás qué pasos dar si la consola se niega a cargar, cómo consultar la página pública de estado y por qué terceros como Downdetector son útiles para contexto, pero no para automatizar.
AWS Health Dashboard: el punto de partida
El panel de salud de AWS muestra interrupciones, eventos activos y mantenimientos planificados que puedan influir en tus servicios y recursos. Es parte de tu cuenta, no requiere configuración y proporciona visibilidad contextual sobre lo que está pasando. Si no accedes a una instancia o a una consola concreta, es el primer sitio al que mirar.
Un detalle que se olvida a menudo: AWS es regional. Selecciona la región correcta en el selector del panel de Health, porque si consultas la región equivocada puede que no veas el incidente que te afecta. Esta precisión evita diagnósticos erróneos cuando el problema se limita a una zona geográfica.
Desde 2023, al abrir un evento público en el panel de Health, la URL del navegador incluye un enlace profundo al evento. Eso permite compartir exactamente la incidencia que estás viendo o reabrirla y llegar a la misma vista con la ventana emergente cargada, lo que facilita el trabajo en equipo durante un incidente.
Si la consola de administración no abre o devuelve errores de navegador (por ejemplo, 404), no te lances a lo loco. Comprueba primero si hay un evento activo relevante en el Health Dashboard, y después aplica medidas locales como limpiar caché y cookies, probar con otro navegador y confirmar con el equipo de TI que la red no bloquea dominios de Amazon (amazon.com y subdominios como aws.amazon.com).
Ingesta fiable de eventos: mejor EventBridge que RSS
Existen feeds RSS con eventos de salud, pero su formato puede cambiar con el tiempo y romper tus integraciones. Hacer scraping o depender del RSS para pipelines críticos es, como poco, arriesgado.
Lo robusto es integrar AWS Health con Amazon EventBridge. Así recibes eventos con un esquema estable, en tiempo real y listos para enrutar hacia Lambda, colas, notificaciones o dashboards internos, creando tu circuito de incidentes sin piezas frágiles.
Con EventBridge ganas trazabilidad y resiliencia: puedes etiquetar, enriquecer, correlacionar y automatizar respuestas en función del servicio, la región o el impacto. Y si mañana cambian detalles de presentación del feed público, tu integración seguirá indemne.
ACM: revisar la renovación de certificados sin sustos
Con AWS Certificate Manager puedes verificar si tus certificados se renuevan correctamente de forma gestionada. Un certificado es elegible para renovación automática cuando está asociado a servicios de AWS (por ejemplo, ELB o CloudFront) o si fue exportado desde su emisión o última renovación. Esta elegibilidad es el pilar para olvidarte del cron de renovaciones manuales.
Cuando arranca el ciclo de renovación, ACM muestra un campo de estado en los detalles del certificado. Desde consola, API o CLI puedes consultar el RenewalStatus para saber en qué punto estás. También verás estados relevantes relacionados en el panel de Health si hay problemas que requieran tu atención.
Si prefieres comandos, la CLI te lo pone fácil: la operación describe-certificate devuelve el detalle, incluido el estado de renovación. Por ejemplo:
Ejemplo: aws acm describe-certificate --certificate-arn arn:aws:acm:REGION:ACCOUNT:certificate/CERTIFICATE_ID
En la respuesta JSON, fíjate en el campo RenewalStatus. Si ese campo no aparece aún, ACM no ha iniciado la renovación gestionada. Conviene anticipar ventanas: ACM intenta renovar automáticamente unos 60 días antes de la expiración y, si algo se tuerce (validación del dominio, por ejemplo), recibirás avisos en Health con antelación: 45, 30, 15, 7, 3 y 1 día.
Cuando la consola no carga: pasos rápidos y eficaces
Los errores tipo 404 o fallos de conexión al acceder a la consola de AWS suelen tener solución. Empieza revisando el Health Dashboard en la región donde están tus recursos para descartar un evento en curso que afecte a ese servicio o consola.
Si no hay incidentes abiertos, aplica medidas locales: borra la caché y las cookies del navegador, intenta entrar con otro navegador y valida con el administrador de sistemas que la red corporativa no bloquea amazon.com ni subdominios como aws.amazon.com.
El problema podría limitarse a un recurso concreto. Por ejemplo, una instancia EC2 puede estar en mantenimiento planificado, y el panel de Health te mostrará la ventana e impacto de ese evento. Ir a la raíz te ahorra tiempo.
Además, si tu bloqueo es de acceso a la cuenta, siempre viene bien tener a mano artículos de ayuda: crear y activar una nueva cuenta, cómo iniciar sesión en la consola o cómo solicitar asistencia. Tener esas guías localizadas reduce tiempos de espera en momentos de tensión.
EC2 al detalle: checks de estado y qué hacer cuando fallan
Amazon EC2 realiza verificaciones automáticas por instancia para detectar problemas de plataforma o de software que afecten a tus aplicaciones. Estos checks se ejecutan cada minuto y marcan OK o deterioro (impaired) según su resultado. No se pueden desactivar y son tu alarma temprana.
Cada tipo de verificación está respaldado por métricas en CloudWatch. Si un check falla, la métrica asociada sube y es el momento de disparar alarmas. Con esto puedes automatizar avisos y acciones para minimizar el tiempo de indisponibilidad.
Verificaciones del sistema (plataforma subyacente)
Estas comprobaciones supervisan la infraestructura donde corre tu instancia. Cuando fallan, suele ser un asunto de la plataforma que requiere intervención de AWS o medidas para mover la instancia a otro host.
En instancias respaldadas por EBS, una acción efectiva es detener e iniciar la instancia para recolocarla en un host nuevo. Si tu instancia usa almacén de instancias (Linux), puedes optar por terminar y reemplazar, sabiendo que los volúmenes efímeros se pierden al detener.
La métrica que refleja este fallo es StatusCheckFailed_System. Es perfecta para alarmas que activen runbooks, recuperación automática o la apertura de un caso de soporte si la situación persiste.
Hay una particularidad con Bare Metal: un reinicio desde el sistema operativo puede provocar, de forma momentánea, un error en el check del sistema. Cuando la instancia vuelva en condiciones, el estado regresará a OK sin intervención adicional.
Verificaciones de la instancia (conectividad y software)
Estas revisiones analizan la salud del SO y la red de la propia instancia. EC2 valida conectividad enviando solicitudes ARP a la NIC para comprobar que responde. Un fallo aquí suele implicar ajustes en tu lado.
Si la comprobación cae, toca actuar: reiniciar la instancia, revisar firewall/iptables, chequear logs del sistema y asegurarte de que la red responde. Cuando la causa es software o configuración, no basta con esperar.
La métrica a vigilar es StatusCheckFailed_Instance. Úsala para disparar alarmas que ejecuten procedimientos de diagnóstico (recoger logs, reinicios controlados o rollbacks si detectas que no remonta).
De nuevo, en Bare Metal puede aparecer un error temporal al reiniciar desde el SO. Cuando la instancia completa el arranque, lo normal es que los checks vuelvan a OK, así que no cunda el pánico.
Verificaciones de EBS adjunto (E/S en volúmenes)
Estas comprobaciones validan si los volúmenes EBS adjuntos son accesibles y pueden completar operaciones de entrada/salida. La métrica binaria StatusCheckFailed_AttachedEBS indica deterioro cuando uno o varios volúmenes fallan.
Un error en este frente puede deberse a problemas de cómputo subyacentes o a incidencias en EBS. Puedes esperar mitigación por parte de AWS o tomar medidas: reemplazar volúmenes, detener e iniciar la instancia para moverla a otro host o revisar el dimensionamiento de IOPS si ves cuellos de botella.
Si tu carga no hace E/S pero aparece deterioro, un ciclo de detener e iniciar puede resolver problemas del host que impacten en la accesibilidad de los volúmenes. Complementa con métricas nativas de EBS en CloudWatch para detectar patrones de rendimiento pobre.
En grupos Auto Scaling, configura la política para retirar instancias con fallos persistentes en el check de EBS adjunto. Mantendrás la flota sana sin intervención manual y evitarás degradaciones prolongadas.
Alarmas y automatización: CloudWatch + Auto Scaling
Con todas las métricas de estado, CloudWatch se convierte en tu sistema nervioso. Define umbrales, crea alarmas y orquesta acciones: notificaciones, Lambda, recuperación o sustitución de instancias. Es la base para respuestas automáticas y consistentes.
Si necesitas continuidad de negocio, piensa en automatizar y reemplazar: Auto Scaling puede retirar instancias deterioradas y lanzar nuevas, mientras tus alarmas activan los canales de aviso adecuados (correo, Slack, PagerDuty o el que uses).
La visión completa llega al correlacionar fuentes: métricas y logs de CloudWatch, trazas, y eventos de AWS Health vía EventBridge. Con ese mosaico, distinguirás si el problema es de tu app, de la instancia, del volumen o de la plataforma, y reaccionarás con precisión.
Fuentes oficiales y de contexto para saber si AWS falla
Cuando circulan rumores de caída —como la caída global de AWS que provocó fallos masivos—, lo ideal es priorizar las fuentes oficiales. Consulta la página pública status.aws.amazon.com para ver el estado por servicio y región, y usa el AWS Health Dashboard si tienes sesión iniciada para información específica de tu cuenta.
Las fuentes de terceros aportan contexto social y señales adicionales. Downdetector refleja picos de reportes de usuarios y The Stack Status resume el estado de varios proveedores. Son útiles para intuir alcance, aunque no sustituyen a los canales oficiales.
Eso sí, distingue entre visibilidad y automatización. Para ingestión programática de eventos, mejor EventBridge que feeds RSS o scraping, porque los formatos externos pueden cambiar y dejarte vendido en pleno incidente.
Cómo se manifiestan las grandes caídas y qué puedes esperar
Las incidencias de gran calado suelen concentrarse en regiones muy utilizadas (como la costa este de EE. UU.), y el impacto se percibe en cadenas: almacenamiento, cómputo, bases de datos o DNS. No es raro ver servicios como S3, EC2, RDS, Route 53 o Kinesis figurando entre los tocados en picos de error.
En esas ventanas, empresas de streaming, herramientas de colaboración, comercio electrónico o apps móviles pueden experimentar latencia, errores de autenticación y fallos intermitentes. El patrón es irregular: a algunos usuarios les funciona, a otros no, según rutas, puntos de presencia y regiones activas.
Los canales oficiales suelen publicar actualizaciones periódicas: identificación preliminar de la causa (por ejemplo, problemas de resolución DNS en una API), despliegue de mitigaciones y recomendaciones de reintentos. A medida que la recuperación progresa, los errores bajan y se normaliza el tráfico.
En determinados países o sectores, verás titulares sobre servicios concretos afectados. Plataformas como Netflix, Disney+, Slack, bancos o apps muy populares pueden verse salpicadas cuando la región en la que dependen sufre, e incluso negocios en LATAM (como casos de iFood, Mercado Livre o PicPay en incidentes del pasado) han sentido el temblor.
Impacto económico y reputacional de una caída
Más allá del lado técnico, una interrupción de la nube tiene coste real: pérdidas por minuto, soporte saturado, clientes frustrados y presión mediática. El efecto red se amplifica por la centralización de ciertos pilares de Internet.
Las organizaciones que operan servicios críticos lo saben de sobra: si los fallos son repetidos, la confianza se erosiona y la recuperación de la imagen de marca cuesta más que la propia reparación técnica.
Estas crisis ponen sobre la mesa una lección obvia pero incómoda: dependemos mucho de infraestructuras compartidas. Diseñar con resiliencia y con supuestos de fallo realistas ya no es opcional.
Estrategias para ser más resiliente ante el próximo incidente
Si tu negocio no puede pararse, hay tácticas que reducen el riesgo operativo. Considera una arquitectura multi-región para repartir carga entre zonas diferentes de AWS y evitar un único punto de fallo geográfico.
Cuando el caso de uso lo justifique, evalúa la multi-nube. Distribuir funcionalidades básicas en otro proveedor (Azure, GCP) te da una red de seguridad, aunque implica más complejidad y costes de coordinación.
En la capa de entrega, un CDN bien configurado ayuda a capear temporales. Servicios como CloudFront o alternativas como Cloudflare permiten servir contenido estático incluso si tu origen va a trompicones, dando un respiro a usuarios y sistemas.
Nada de esto cuaja sin organización: define un plan de respuesta a incidentes con roles, canales, escalado y comunicación externa. En momentos calientes, la claridad ahorra minutos que valen oro.
Buenas prácticas para verificar el estado de AWS sin perderse
Centraliza la observabilidad: usa el AWS Health Dashboard para el contexto de plataforma y CloudWatch para métricas operativas. Ese doble enfoque evita quedarse ciego en alguna capa.
Con certificados, automatiza. Monitoriza el RenewalStatus en ACM y reacciona a las alertas escalonadas del panel de Health para no llegar al día de caducidad con el pie cambiado.
Configura alarmas sobre las métricas clave de EC2. StatusCheckFailed_System, StatusCheckFailed_Instance y StatusCheckFailed_AttachedEBS son imprescindibles, asociadas a acciones de recuperación, reinicio, conmutación por error o reemplazo vía Auto Scaling, según tu SLA.
Y si la consola se resiste, recuerda el checklist: verifica eventos en Health en la región correcta, limpia caché y cookies, cambia de navegador y confirma con TI que no se bloquean los dominios de AWS. Esas sencillas comprobaciones resuelven más de lo que parece.
Recursos relacionados y ayuda de cuenta
Para ampliar y afianzar tu operativa, revisa la documentación de los servicios involucrados. AWS Health y EventBridge para el enrutado de eventos, ACM para renovaciones y la referencia de CloudWatch/EC2 para métricas y acciones, forman un kit potente.
- AWS Health Dashboard: visibilidad de eventos públicos y específicos de cuenta, sin necesidad de configuración adicional.
- Amazon EventBridge: ingestión fiable de eventos de salud con reglas flexibles para enrutar a múltiples destinos.
- AWS Certificate Manager (ACM): seguimiento del estado de renovación y avisos escalonados antes de caducidad.
- Amazon EC2 + CloudWatch: checks por minuto, métricas de estado y alarmas que ejecutan respuestas automáticas.
Si tienes dudas de acceso o gestión de la cuenta, apóyate en los artículos de soporte más habituales: cómo crear y activar una cuenta nueva, cómo iniciar sesión en la consola y cómo solicitar ayuda sobre tu cuenta y recursos. Tenerlos localizados acelera trámites cuando algo no encaja.
Mirar un único panel nunca cuenta toda la historia: verificar el estado de AWS exige unir el contexto del Health Dashboard, la ingestión fiable con EventBridge, las señales de ACM y los checks de EC2. Con alarmas bien pensadas y playbooks claros, el diagnóstico llega antes, las respuestas son más certeras y la operación se vuelve mucho más tranquila incluso cuando sube el tráfico o hay sobresaltos regionales.
