La detección empieza con un plan, no con una herramienta. Para cada carga de trabajo te preguntas: ¿qué podría salir mal, cómo se vería en los logs o en las métricas, y quién necesita enterarse? Una aplicación web pública se preocupa por picos de errores 4xx y 5xx, inicios de sesión fallidos y orígenes de tráfico inusuales. Una plataforma de datos se preocupa por quién lee qué buckets y si cambian los ajustes de cifrado. Poner estas respuestas por escrito se convierte en una lista de requisitos de monitoreo: qué fuentes de logs activar, qué métricas vigilar y qué alertas enviar a quién.
Amazon CloudWatch es el servicio central de métricas y alarmas. Los servicios de AWS publican métricas automáticamente, como CPUUtilization para EC2 o HTTPCode_ELB_5XX_Count para un balanceador de carga, y puedes publicar métricas personalizadas desde las aplicaciones. Una alarma de CloudWatch vigila una métrica (o una expresión matemática sobre varias) frente a un umbral durante varios períodos y cambia al estado ALARM, que puede notificar a un tema de Amazon SNS, disparar Auto Scaling o ejecutar una acción de EC2. Las composite alarms combinan varias alarmas para reducir el ruido, de modo que la persona de guardia solo recibe un aviso cuando, por ejemplo, los errores y la latencia están altos a la vez.
Los health checks te dicen si algo es alcanzable y funciona desde afuera. Los health checks de Route 53 prueban un endpoint por HTTP, HTTPS o TCP desde ubicaciones de todo el mundo y también pueden seguir una alarma de CloudWatch. Controlan la conmutación por error de DNS, y Shield Advanced puede usarlos para la detección de DDoS basada en la salud de la aplicación, lo que hace la detección de ataques más rápida y precisa. Los health checks de los balanceadores hacen un trabajo parecido dentro de una región, sacando de servicio a los destinos que no responden.
Para el examen, relaciona el requisito con la capa correcta. Salud y rendimiento de recursos: métricas y alarmas de CloudWatch. Alcanzabilidad desde internet: health checks de Route 53. Actividad de la API: CloudTrail. Amenazas: GuardDuty. Hallazgos agregados: Security Hub. Una buena estrategia de monitoreo usa varios de estos juntos y envía cada señal a alguien que pueda actuar, en lugar de acumular datos que nadie lee.
Términos clave
- CloudWatch alarm
- Regla que vigila una métrica frente a un umbral en el tiempo y cambia al estado ALARM, lo que puede disparar notificaciones o acciones.
- Composite alarm
- Alarma cuyo estado depende de una combinación lógica de otras alarmas, usada para reducir alertas ruidosas.
- Health check de Route 53
- Prueba desde ubicaciones de AWS que verifica si un endpoint responde, o sigue una alarma de CloudWatch, y puede controlar la conmutación por error de DNS.
- Requisito de monitoreo
- Declaración escrita de qué se debe observar en una carga de trabajo, de dónde vienen los datos y a quién se alerta.
El equipo de una API de pagos enumera sus riesgos: credential stuffing, una base de datos que falla y cambios accidentales de políticas. Agrega una alarma de CloudWatch sobre la métrica de solicitudes bloqueadas por WAF, un health check de Route 53 en el endpoint público que también usa Shield Advanced y una regla de EventBridge para cambios de políticas IAM, todo enviado al tema de SNS del equipo.
Comprueba lo que sabes
¿Qué aporta un health check de Route 53 que una alarma de CPU de CloudWatch no aporta?
Prueba si el endpoint realmente responde desde afuera, así que detecta fallas como un listener roto o una ruta de red caída aunque la CPU se vea normal.
¿Por qué usar una composite alarm?
Para alertar solo cuando varias condiciones se cumplen a la vez, lo que reduce las falsas alarmas y el cansancio por alertas.