Cómo verificar el estado de AWS como un pro: Health, ACM y EC2

Home » Python » Cómo verificar el estado de AWS como un pro: Health, ACM y EC2

Cuando necesitas verificar el estado de AWS, no basta con mirar si un servicio “funciona o no”. La clave está en combinar el panel de salud, alertas en tiempo real y comprobaciones específicas de tus recursos para entender qué ocurre y cómo te afecta. Si trabajas con cargas críticas, anticiparte a incidencias o detectar degradaciones de rendimiento puede ahorrarte más de un susto.

En esta guía encontrarás todo lo necesario para controlar el estado de AWS de forma efectiva: desde AWS Health Dashboard y la integración con EventBridge, hasta la comprobación del estado de renovación de certificados en ACM y las verificaciones de salud de instancias EC2 (incluyendo métricas de CloudWatch y opciones de recuperación). Además, verás consejos prácticos si la consola no te carga o un servicio parece caído en tu región.

AWS Health Dashboard: tu punto de partida para el estado de servicios

El AWS Health Dashboard te muestra información sobre interrupciones de servicio, eventos en curso y mantenimiento planificado. Es un servicio integrado en tu cuenta, no requiere configuración y puedes acceder si estás autenticado. Resulta muy útil cuando no alcanzas un recurso concreto (por ejemplo, una instancia de EC2 que justo está en mantenimiento).

Recuerda un detalle importante: los servicios de AWS son regionales. Si consultas el panel de salud, asegúrate de seleccionar la región correcta desde el selector correspondiente; de lo contrario, puedes no ver eventos relevantes para tus recursos.

Desde septiembre de 2023, cuando abres un evento público de AWS Health, la URL del navegador se actualiza con un enlace profundo a ese evento. Al compartir ese enlace o volver a abrirlo, irás a la vista de lista de eventos con la ventana emergente del evento ya cargada, lo que facilita el seguimiento y la colaboración con tu equipo.

Si un día la consola no te carga o devuelve errores del tipo 404, conviene ir por partes. Lo primero es revisar el AWS Health Dashboard para comprobar si hay un evento activo que afecte al servicio que intentas usar. Después, puedes probar a limpiar la caché y las cookies del navegador, cambiar a otro navegador y confirmar con tu administrador de red que no haya bloqueos hacia dominios de Amazon (por ejemplo, aws.amazon.com).

Ingesta de eventos de salud: EventBridge frente a RSS

Aunque existe un feed RSS con eventos de salud, su formato puede cambiar con el tiempo, por lo que basar la ingesta programática en él no es lo más fiable. Scraping o consumo directo del RSS podría dejarte fuera de juego si se ajusta el esquema o el contenido.

La recomendación es clara: integra AWS Health con Amazon EventBridge. De esta manera recibirás eventos de forma consistente, con un formato estable y listo para enrutar a destinos como Lambda, colas, notificaciones o tableros internos. Este enfoque te permite automatizar respuestas, registrar incidentes y generar alarmas sin depender de formatos frágiles.

En otras palabras, si quieres robustez y trazabilidad, EventBridge es el camino correcto para monitorizar eventos de AWS Health. A partir de ahí, puedes enriquecer la información, asociarla a servicios, equipos o SLA internos y actuar en caliente cuando algo se tuerce.

ACM: cómo comprobar el estado de renovación de tus certificados

Con AWS Certificate Manager (ACM) puedes saber si tus certificados se están renovando correctamente. Un certificado es elegible para renovación automática si está asociado a otro servicio de AWS (como Elastic Load Balancing o CloudFront) o si se exportó desde su emisión o última renovación. Esta elegibilidad es básica para que ACM gestione las renovaciones sin que tengas que intervenir.

Cuando inicias un proceso de renovación, ACM muestra un campo llamado Renewal status en los detalles del certificado. Puedes consultar ese estado desde la consola, la API, la AWS CLI o incluso a través del AWS Health Dashboard. Si usas la consola, verás uno de varios valores posibles para este estado; de forma similar se reflejan en el panel de salud.

En entornos automatizados resulta muy útil tirar de la API de ACM. Con la acción DescribeCertificate obtienes el detalle de un certificado, incluido su estado de renovación. Para Java (u otros lenguajes) puedes basarte en los SDK de AWS y consultar periódicamente este campo para anticipar caducidades o detectar bloqueos de validación.

Si prefieres línea de comandos, la AWS CLI te devuelve el estado de renovación. Un ejemplo sencillo sería:

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 no aparece, significa que ACM todavía no ha empezado el proceso de renovación gestionada para ese certificado. Es un detalle que pasa desapercibido, pero que te indica claramente en qué punto estás del ciclo.

ACM intenta renovar automáticamente un certificado 60 días antes de su expiración. Si por algún motivo no puede hacerlo (por ejemplo, un problema con la validación del dominio), verás avisos en AWS Health Dashboard con antelación: 45, 30, 15, 7, 3 y 1 días antes de la caducidad. Estos eventos no requieren configuración extra y están disponibles para cualquier usuario autenticado en tu cuenta, de modo que el equipo puede reaccionar a tiempo.

Cuando la consola no abre o devuelve errores: pasos rápidos

Si te topas con un 404 o la consola no carga, empieza comprobando el AWS Health Dashboard y la región de tus recursos. Un evento público o un mantenimiento regional pueden explicar por qué no alcanzas cierta consola o servicio.

Si no hay eventos relevantes, limpia la caché y las cookies del navegador, prueba con otro navegador y, si estás en una red corporativa, pide a tu equipo de TI que verifique que no haya bloqueos a dominios de Amazon ni a subdominios críticos.

Procura también confirmar que el problema no sea de un recurso concreto en tu cuenta. Por ejemplo, una instancia EC2 puede estar pasando por mantenimiento o afectada por un evento; el panel de salud mostrará esa información y te orientará sobre la ventana y el impacto.

Verificación del estado de instancias EC2: checks y métricas

Amazon EC2 ejecuta comprobaciones automáticas en cada instancia en ejecución para detectar problemas de hardware e incidencias de software que puedan impedir a tus aplicaciones funcionar con normalidad. Estos checks se realizan cada minuto y devuelven un resultado que indica si todo está bien o si hay deterioro.

Cuando todas las verificaciones se superan, el estado global se marca como OK. Si una o varias fallan, el estado pasa a impaired (deteriorado). Estas comprobaciones están integradas en el servicio, no se pueden desactivar ni eliminar, y proporcionan señales tempranas de problemas que conviene atender.

Cada tipo de comprobación tiene asociada una métrica en Amazon CloudWatch. Al fallar un check, la métrica correspondiente aumenta. Esto te permite crear alarmas que salten al detectar errores de estado, ya sea en una instancia concreta o a escala de flota.

Más aún, puedes apoyarte en alarmas y acciones de CloudWatch para automatizar respuestas. Por ejemplo, configurar una alarma que te avise cuando fallen checks en una instancia específica, o habilitar la recuperación automática cuando el deterioro se deba a un problema subyacente en el host.

Si necesitas resiliencia avanzada, no te limites a las alarmas. Combina métricas de estado con Auto Scaling para sustituir instancias deterioradas y mantén tu capacidad saludable sin intervención manual, especialmente en picos de tráfico o workloads sensibles a la latencia.

Comprobaciones de estado del sistema

Estas verificaciones monitorizan la infraestructura de AWS subyacente donde corre tu instancia. Cuando fallan, suelen requerir intervención de AWS o acciones que muevan la instancia a otro host para corregir el problema.

En instancias respaldadas por EBS, una medida efectiva es detener e iniciar la instancia. Esta acción, en la mayoría de escenarios, reubica la instancia en un nuevo host y puede resolver el fallo de plataforma. Si trabajas con instancias respaldadas por almacén de instancias (solo Linux), puedes terminar y reemplazar la instancia, teniendo presente que los volúmenes del almacén de instancias son efímeros y los datos se pierden al detener.

Cuando falla una comprobación del sistema, aumenta la métrica StatusCheckFailed_System. Es la señal ideal para activar alarmas, iniciar procedimientos de contingencia o, en su caso, abrir un caso de soporte si persiste el impacto.

Hay un matiz con Bare Metal: si reinicias desde el sistema operativo, la comprobación de estado del sistema puede marcar error de forma temporal. En cuanto la instancia vuelve a estar disponible, el estado debería volver a aprobado sin que tengas que tocar nada extra.

Comprobaciones de estado de la instancia

Estas verificaciones analizan la conectividad de red y el software de la propia instancia. EC2 realiza la validación enviando solicitudes ARP a la interfaz de red (NIC) para confirmar que responde como es debido.

Cuando falla una comprobación de la instancia, suele requerir tu intervención directa: reiniciar la instancia, revisar la configuración de red (por ejemplo, reglas de iptables o un firewall que corta tráfico), analizar los logs del sistema o comprobar que el agente de red esté respondiendo.

Al producirse un fallo, se incrementa la métrica StatusCheckFailed_Instance. Esta métrica es perfecta para disparar alarmas y ejecutar runbooks de diagnóstico: desde recopilar logs hasta forzar un reinicio controlado si detectas que el servicio no remonta.

Igual que con el check del sistema, en Bare Metal un reinicio desde el SO puede provocar un estado de error temporal en la comprobación de la instancia. Cuando la instancia finaliza el ciclo de arranque, la verificación debería volver a OK sin mayor complicación.

Comprobaciones de estado de EBS adjunto

Estas comprobaciones revisan si los volúmenes de Amazon EBS adjuntos a la instancia son accesibles y completan E/S. La métrica que refleja fallos es StatusCheckFailed_AttachedEBS, de tipo binario, que indica impacto cuando uno o varios volúmenes no pueden realizar operaciones de E/S.

Un fallo aquí apunta a problemas subyacentes de computación o en la infraestructura de EBS. Puedes esperar a que AWS mitigue la incidencia o actuar: sustituir volúmenes afectados, detener e iniciar la instancia para moverla a nuevo host, o incluso repensar el reparto de IOPS si detectas cuellos de botella prolongados.

Para workloads resilientes, aprovecha esta métrica para crear alarmas en CloudWatch. Según tu arquitectura, puedes disparar conmutación por error a una instancia secundaria o a otra zona de disponibilidad al detectar impacto sostenido, reduciendo el tiempo fuera de servicio.

Si tu carga de trabajo no está haciendo E/S a ningún volumen adjunto, pero la comprobación indica deterioro, detener e iniciar la instancia puede resolver problemas del host que afectan a la accesibilidad del volumen. Complementa con las métricas de EBS en CloudWatch para detectar volúmenes que rindan por debajo de lo esperado y reemplázalos preventivamente si toca.

En flotas administradas por Auto Scaling, configura la política para detectar errores en el check de EBS adjunto y sustituir la instancia afectada. Así, mantienes la salud del grupo sin intervención manual y evitas degradaciones prolongadas.

Alarmas y automatización con CloudWatch y Auto Scaling

Con todas las métricas anteriores, CloudWatch se convierte en tu sistema nervioso. Define umbrales, crea alarmas y orquesta acciones: notificaciones, ejecución de funciones Lambda o recuperación de instancias cuando se cumplan ciertas condiciones.

Si necesitas continuidad de negocio, piensa en términos de automatización y reemplazo: Auto Scaling puede retirar instancias con checks deteriorados y lanzar nuevas, mientras que las alarmas coordinan las respuestas y te avisan por los canales adecuados (correo, Slack, PagerDuty, lo que uses).

La combinación de métricas de estado, logs, trazas y eventos de AWS Health vía EventBridge te da una visión holística. Así sabrás si el problema es de tu aplicación, de la instancia, del volumen de EBS o de la plataforma subyacente, y actuarás con precisión quirúrgica.

Buenas prácticas para verificar el estado de AWS con cabeza

Centraliza la observabilidad: usa AWS Health Dashboard para contexto de plataforma y CloudWatch para métricas operativas. Este doble enfoque evita perderte detalles importantes de cada capa.

Para certificados, no lo dejes al azar. Automatiza la revisión de RenewalStatus en ACM, y reacciona a las notificaciones del panel de salud a 45, 30, 15, 7, 3 y 1 días de caducidad. Si algo falla, tendrás margen de sobra.

En EC2, activa alarmas sobre StatusCheckFailed_System, StatusCheckFailed_Instance y StatusCheckFailed_AttachedEBS. Asócialas a acciones: recuperación, reinicio, conmutación por error o reemplazo vía Auto Scaling, según tu SLA.

Y si la consola se empeña en no cargar, recuerda la receta: verifica eventos en Health Dashboard en la región correcta, limpia caché/cookies, cambia de navegador y confirma con TI que no se bloquea el dominio de AWS.

Recursos e información relacionada

Para ampliar configuración y operativa, consulta la documentación de AWS Health y de EventBridge para el enrutado de eventos. En el ámbito de certificados, revisa la guía de ACM y los ejemplos de DescribeCertificate si vas a integrar verificaciones en pipelines o monitores internos.

• AWS Health Dashboard: visibilidad de eventos públicos y de cuenta, sin configuración extra.
• Amazon EventBridge: ingesta fiable de eventos de salud, con reglas y destinos flexibles.
• AWS Certificate Manager (ACM): estado de renovación y notificaciones previas a la caducidad.
• Amazon EC2 + CloudWatch: checks por minuto, métricas de estado y alarmas con acciones.

Si te preocupa el acceso a la cuenta, hay artículos de ayuda muy útiles: cómo crear y activar una cuenta nueva, cómo iniciar sesión en la consola o cómo pedir soporte. Tenlos a mano si gestionas varios entornos o rotas credenciales con frecuencia.

Verificar el estado de AWS no es mirar un único panel y ya. Se trata de unificar señales de AWS Health, eventos de EventBridge, estados de ACM y checks de EC2/componente por componente, con alarmas que actúan a tiempo y playbooks claros. Con esta combinación tendrás diagnóstico rápido, menos sorpresas y una operación más tranquila, incluso cuando el tráfico sube y las cosas se ponen interesantes.