Monitorear la seguridad de una aplicación en AWS exige tres piezas que trabajan en cadena: logs, métricas y alertas accionables. Si configuras bien una alarma en CloudWatch, recibes un aviso en correo, Slack u otra herramienta cuando algo se sale de lo esperado, y puedes reaccionar antes de que el incidente escale.

¿Por qué las alertas deben ser accionables?

Una alerta sirve cuando puedes hacer algo con ella. Si te llega un mensaje al correo, a Slack o a una app como Opsani y no sabes qué paso seguir, esa alerta sobra. La idea es que cada notificación apunte a un comportamiento inesperado y te dé la información mínima para actuar.

Cuando el incidente es grave, afecta usuarios o termina en un outcome inesperado, entra en juego el post-mortem, una ceremonia donde el equipo se reúne para identificar la causa raíz del fallo y definir cambios en procesos o código.

¿Qué es un post-mortem en seguridad? Es una reunión donde el equipo analiza qué pasó en un incidente, encuentra la causa raíz y define acciones para que no se repita. No busca culpables, busca aprendizaje.

¿Cómo se crea una alarma en CloudWatch paso a paso?

En la consola de AWS, abre CloudWatch, entra a Alarms, luego a All alarms y pulsa Create alarm. Desde ahí seleccionas la métrica que quieres vigilar. En el ejemplo se usa API Gateway, Across all APIs, sobre la métrica Count, que mide el número de requests recibidos en un periodo de tiempo [01:46].

La configuración del umbral queda así:

• Periodo de evaluación: promedio en los últimos 5 minutos.
• Tipo de threshold: estático.
• Condición: si el conteo es mayor a 10.000 requests, dispara la alerta.
• Data points: se dejan por defecto.

Una alarma en CloudWatch puede estar en tres estados: In alarm, OK o Insufficient data, este último cuando no hay datos suficientes para evaluar.

¿Cómo conectar la alarma con notificaciones por correo?

Para recibir el aviso fuera de la consola, creas un SNS topic desde la misma alarma. SNS es el Simple Notification Service de AWS, el servicio que envía notificaciones a distintos canales [03:20].

El flujo es directo:

1. Crea un nuevo SNS topic dentro de la alarma.
2. Define el tipo de notificación como email y agrega tu correo.
3. Confirma la suscripción desde el mensaje que llega a tu bandeja.
4. Asigna nombre y descripción a la alarma, por ejemplo MaxApiGatewayHits con la descripción "Están llegando más de 10.000 requests al API Gateway".

Además del correo, una alarma puede triggerear una función Lambda, una acción de autoescalamiento, terminar una instancia EC2 o ejecutar un System Manager. Eso convierte la alerta en una respuesta automática.

¿Cómo simular una alarma sin esperar tráfico real?

No necesitas esperar a que lleguen 10.000 requests para validar que tu configuración funciona. CloudWatch tiene un comando que fuerza el estado de la alarma desde CloudShell, la consola integrada de AWS [05:10].

El comando es:

bash aws cloudwatch set-alarm-state
--alarm-name MaxApiGatewayHits
--state-value ALARM
--state-reason "Testing"

Al ejecutarlo, la alarma pasa a estado In alarm y SNS dispara el correo. En la bandeja te llega un mensaje tipo Alarm MaxApiGatewayHits con la región (en el ejemplo, Ohio), la descripción, la razón del disparo y un enlace directo a la alarma en consola.

¿Qué hace el comando set-alarm-state? Cambia manualmente el estado de una alarma de CloudWatch a ALARM, OK o INSUFFICIENT_DATA para probar que tus notificaciones funcionan sin generar tráfico real.

¿Qué métricas y servicios entran en juego al monitorear?

El ejercicio gira alrededor de varios componentes de AWS que conviene tener claros:

• CloudWatch: servicio central de métricas, logs y alarmas.
• API Gateway: expone APIs y entrega métricas como Count de requests.
• SNS (Simple Notification Service): envía notificaciones por email, SMS u otros canales.
• CloudShell: consola integrada en AWS para ejecutar comandos sin configurar tu terminal local.
• Lambda, EC2, System Manager: posibles destinos de acciones automáticas cuando se dispara una alarma.

Esta misma lógica de métrica, umbral y notificación se traslada a herramientas como New Relic o Datadog, así que el aprendizaje no se queda atado a AWS.

¿Para qué sirve un SNS topic? Es el canal que recibe el evento de la alarma y lo distribuye a los suscriptores: correos, números de teléfono, funciones Lambda u otros servicios.

¿Cómo encajan los post-mortems en este flujo?

Las alarmas detectan, los post-mortems explican y previenen. Cuando una alerta termina en incidente grave, el equipo se reúne, revisa logs, métricas y la traza del fallo, y documenta qué cambios hacen falta. La meta es siempre que el mismo error no vuelva a ocurrir, sin convertir la sesión en una caza de culpables.

Con esta cadena (logs, métricas, alertas accionables y post-mortems) tienes visibilidad en tiempo real de lo que pasa en tu sistema y un mecanismo claro para mejorar después de cada incidente. ¿Qué métrica vas a vigilar primero en tu propia API? Cuéntalo en los comentarios.