Luis Eduardo Lunar Guevara

Posted on May 18

SOA-Lab1 — Observabilidad mínima: CloudWatch Logs + Alarmas + SNS

#aws #cloudskills #tutorial #cloudwatch

Región: us-east-1

Duración estimada: 35–55 minutos

Costo-riesgo: Bajo

Certificación: AWS Certified CloudOps Engineer - Associate (SOA-C03)

Dominio: Monitoring, Logging and Remediation

Tarea 1.1: Implement metrics, alarms, and filters by using AWS monitoring and logging services

Caso de uso

Digital Cafe Luna inicia sus actividades: un café pequeño, un sueño familiar y una oportunidad para salir adelante. Camilo, hijo de la Sra. Blanca, estudia tecnología y desde el primer día insistió en montar una pequeña aplicación en AWS para apoyar la facturación y llevar un control básico del inventario. Un lunes por la mañana, la Sra. Blanca nota retrasos en la caja, algunos errores en el sistema y suelta esa frase que cualquier equipo técnico ha escuchado alguna vez:

“El sistema está lento, ¿qué pasa?.”

Camilo revisa la instancia, pero no tiene suficiente visibilidad para entender. No sabe si fue la CPU, logs, errores de arranque, una carga puntual o simplemente una percepción del usuario.

La clave es simple: sin observabilidad, diagnosticar se vuelve adivinar.

En este laboratorio vamos a construir un baseline mínimo de observabilidad en AWS: logs centralizados, una alarma de CPU y una notificación por email. ¡No es una plataforma completa de monitoreo por Dios!, pero si un primer paso para operar con datos y no con suposiciones.

¿Qué vamos a construir?

En este laboratorio vas a crear:

Un SNS Topic con suscripción por email para recibir alertas.
Un CloudWatch Log Group con retención corta para centralizar logs.
Una instancia EC2 Amazon Linux accesible por SSH.
CloudWatch Agent en la instancia para enviar logs y métricas básicas.
Una alarma de CPU en CloudWatch que notifica al SNS Topic.
Una prueba controlada de carga para validar que la alarma realmente dispara.

Figura 1 — Flujo mínimo de observabilidad para Digital Cafe Luna: EC2 envía logs y métricas a CloudWatch, la alarma dispara SNS y Camilo recibe la notificación por email.

Convención de nombres

Usaremos el prefijo soa-lab1 para que puedas buscar, filtrar y eliminar recursos sin perder tiempo.

Recurso	Nombre
EC2 Instance	`soa-lab1-app`
Security Group	`soa-lab1-app-sg`
Key Pair	`kp-soa-lab1`
CloudWatch Log Group	`/soa/lab1/system`
SNS Topic	`soa-lab1-alerts-v2`
CloudWatch Alarm	`ALARM-soa-lab1-high-cpu`
IAM Role	`soa-lab1-ec2-cw-role`

Nota práctica: usar nombres consistentes no es un detalle menor. En labs ayuda al cleanup, en ambientes reales ayuda a operar, auditar y reducir confusión.

Requisitos previos

Antes de comenzar, asegúrate de tener:

Una cuenta AWS con permisos suficientes para crear recursos del laboratorio.
Región de trabajo: us-east-1 (N. Virginia).
Un correo activo para confirmar la suscripción de Amazon SNS.
Cliente SSH disponible: Terminal en Mac/Linux, PuTTY o similar en Windows.
Acceso a una VPC default en la región.
Tu IP pública disponible para permitir SSH solo desde tu origen.

Ojo: para este laboratorio no abras SSH a 0.0.0.0/0. Vamos a permitir el puerto 22 únicamente desde tu IP pública en formato /32.

Paso 1 — Preparar acceso por SSH

Antes de crear la instancia, vamos a dejar listo el acceso. La regla es simple: necesitamos poder entrar por SSH, pero sin abrir la instancia al mundo.

En este lab vamos a permitir SSH solo desde tu IP pública. Nada de 0.0.0.0/0.

1.1 Crear el Key Pair

En AWS Console:

Ve a EC2 → Key Pairs.
Selecciona Create key pair.
En Name, usa kp-soa-lab1.
En el tipo de llave:
- Si usas Mac/Linux, selecciona .pem.
- Si usas Windows con PuTTY, selecciona .ppk.
Crea el key pair y guarda el archivo en un lugar seguro.

Ojo: AWS solo te permite descargar la llave privada una vez. Si la pierdes, tendrás que crear otro key pair o usar otro método de acceso (mas adelante te enseñaré qué hacer cuando pierdes tu Key pair).

1.2 Crear el Security Group

Ahora crea el Security Group que permitirá SSH solo desde tu IP.

En AWS Console:

Ve a EC2 → Security Groups.
Selecciona Create security group.
En Name, usa soa-lab1-app-sg.
En Description, usa SOA Lab1 SSH restricted.
En VPC, selecciona la default VPC.
En Inbound rules, agrega SSH, puerto 22, source My IP.
En Outbound rules, deja la regla por defecto All traffic.
Crea el Security Group.

En este lab dejamos salida abierta para que la instancia pueda instalar paquetes y comunicarse con servicios de AWS. Lo importante aquí es cuidar el tráfico de entrada.

CLI opcional

Si prefieres hacerlo por CLI, puedes usar este bloque desde tu terminal.

Ojo: MYIP debe obtenerse desde tu máquina local, no desde CloudShell. Si lo ejecutas desde CloudShell, estarías permitiendo la IP pública de CloudShell, no la tuya.

# 0) Variables
REGION="us-east-1"
MYIP="$(curl -s https://checkip.amazonaws.com)/32"

# 1) Obtener la default VPC
VPC_ID="$(aws ec2 describe-vpcs --region "$REGION" \
  --filters Name=isDefault,Values=true \
  --query 'Vpcs[0].VpcId' \
  --output text)"

# 2) Crear Security Group
SG_ID="$(aws ec2 create-security-group --region "$REGION" \
  --group-name "soa-lab1-app-sg" \
  --description "SOA Lab1 SSH restricted" \
  --vpc-id "$VPC_ID" \
  --query 'GroupId' \
  --output text)"

# 3) Autorizar SSH solo desde tu IP pública
aws ec2 authorize-security-group-ingress --region "$REGION" \
  --group-id "$SG_ID" \
  --ip-permissions "IpProtocol=tcp,FromPort=22,ToPort=22,IpRanges=[{CidrIp=$MYIP,Description='SSH solo mi IP'}]"

# 4) Agregar tags
aws ec2 create-tags --region "$REGION" \
  --resources "$SG_ID" \
  --tags Key=Name,Value="soa-lab1-app-sg" Key=Lab,Value="soa-lab1"

# 5) Verificar reglas
aws ec2 describe-security-groups --region "$REGION" \
  --group-ids "$SG_ID" \
  --query "SecurityGroups[0].IpPermissions" \
  --output table

Checkpoint

Antes de seguir, valida:

Existe el key pair kp-soa-lab1.
Existe el Security Group soa-lab1-app-sg.
La regla inbound permite SSH 22 solo desde tu IP pública /32.
No existe una regla SSH abierta a 0.0.0.0/0.

Paso 2 — Lanzar la instancia EC2

Ahora vamos a crear la instancia que usaremos como servidor base de Digital Cafe Luna. No estamos buscando una arquitectura compleja todavía; solo necesitamos una EC2 pequeña, identificable por tags y accesible por SSH para instalar el CloudWatch Agent.

Crear la instancia desde la consola

En AWS Console:

Ve a EC2 → Instances → Launch instance.
En Name, usa soa-lab1-app.
En Application and OS Images, selecciona Amazon Linux 2023. También puedes usar Amazon Linux 2 si es lo que tienes disponible.
En Instance type, selecciona t3.nano. Si tu cuenta no permite t3.nano, usa t3.micro.
En Key pair, selecciona kp-soa-lab1.
En Network settings, selecciona Edit y configura:
- VPC: default VPC.
- Subnet: No preference.
- Auto-assign public IP: Enabled.
- Firewall: Select existing security group.
- Security group: soa-lab1-app-sg.
En Tags, agrega Lab=soa-lab1.
Lanza la instancia y espera hasta que esté en estado Running y con 2/2 checks passed.

CLI opcional para validar

Cuando la instancia esté corriendo, puedes validar con:

REGION="us-east-1"

aws ec2 describe-instances --region "$REGION" \
  --filters "Name=tag:Name,Values=soa-lab1-app" \
            "Name=instance-state-name,Values=running" \
  --query "Reservations[0].Instances[0].{InstanceId:InstanceId,PublicIp:PublicIpAddress,State:State.Name,Tags:Tags}" \
  --output table

Checkpoint

Antes de seguir, confirma:

La instancia soa-lab1-app está en estado Running.
Tiene Public IPv4 address.
Tiene el Security Group soa-lab1-app-sg.
Tiene los tags Name=soa-lab1-app y Lab=soa-lab1.

Paso 3 — Conectarte por SSH y validar la instancia

Antes de instalar agentes o configurar logs, vamos a validar lo básico: que puedes entrar a la instancia. Si SSH falla aquí, mejor corregirlo ahora y no después.

Obtener la IP pública

En AWS Console:

Ve a EC2 → Instances.
Selecciona la instancia soa-lab1-app.
Copia el valor de Public IPv4 address.

También puedes obtenerla por CLI:

REGION="us-east-1"

aws ec2 describe-instances --region "$REGION" \
  --filters "Name=tag:Name,Values=soa-lab1-app" \
            "Name=instance-state-name,Values=running" \
  --query "Reservations[0].Instances[0].PublicIpAddress" \
  --output text

En los siguientes comandos usaré el placeholder <PUBLIC_IP>. Reemplázalo por la IP real de tu instancia.

Conectarte por SSH

Si estás en Mac/Linux, probablemente el archivo quedó en ~/Downloads/kp-soa-lab1.pem. Ajusta la ruta si lo guardaste en otra carpeta.

Primero asegura los permisos de la llave:

chmod 400 ~/Downloads/kp-soa-lab1.pem

Luego entra a la instancia:

ssh -i ~/Downloads/kp-soa-lab1.pem ec2-user@<PUBLIC_IP>

Ejemplo:

ssh -i ~/Downloads/kp-soa-lab1.pem ec2-user@3.123.45.67

Cuando pregunte si confías en el host, responde yes.

Validaciones rápidas dentro de la instancia

Una vez dentro, ejecuta:

uname -a

Y valida salida a Internet:

curl -s https://checkip.amazonaws.com

Checkpoint

Antes de seguir, confirma:

Pudiste conectarte por SSH.
Ves el prompt de ec2-user.
uname -a responde correctamente.
La instancia tiene salida a Internet.

Paso 4 — Preparar CloudWatch Logs

Antes de instalar el agente en la instancia, vamos a crear el Log Group donde llegarán los logs. La idea es dejar el destino listo y configurar una retención corta desde el inicio.

Crear el Log Group desde la consola

En AWS Console:

Ve a CloudWatch.
En el menú izquierdo, entra a Logs → Log groups.
Selecciona Create log group.
En Name, usa /soa/lab1/system.
Crea el Log Group.
Entra al Log Group recién creado.
Busca Retention setting.
Selecciona Edit.
Cambia la retención a 3 days.
Guarda el cambio.

Ojo: si dejas la retención en “Never expire”, los logs no se eliminan automáticamente. Para un laboratorio pequeño puede parecer poco relevante, pero es una mala costumbre operativa.

CLI opcional

Si prefieres hacerlo por CLI:

REGION="us-east-1"

aws logs create-log-group --region "$REGION" \
  --log-group-name "/soa/lab1/system" 2>/dev/null || true

aws logs put-retention-policy --region "$REGION" \
  --log-group-name "/soa/lab1/system" \
  --retention-in-days 3

Checkpoint

Antes de seguir, valida:

Existe el Log Group /soa/lab1/system.
La retención está configurada en 3 days.

Paso 5 — Instalar y configurar CloudWatch Agent

Ahora vamos a instalar y configurar CloudWatch Agent en la instancia EC2. Este agente enviará logs y métricas básicas hacia CloudWatch. Sin este paso, tendríamos una instancia corriendo, pero con poca visibilidad operativa.

No estamos montando una solución completa de observabilidad. Solo queremos una base mínima y funcional: logs centralizados y algunas métricas adicionales desde la instancia.

5.1 Crear el IAM Role para la instancia

Primero necesitamos que la EC2 tenga permisos para publicar logs y métricas en CloudWatch.

En AWS Console:

Ve a IAM → Roles.
Selecciona Create role.
En Trusted entity type, selecciona AWS service.
En Use case, selecciona EC2.
En permisos, agrega la política administrada CloudWatchAgentServerPolicy.
Asigna este nombre al role: soa-lab1-ec2-cw-role.
Crea el role.

Ahora asócialo a la instancia:

Ve a EC2 → Instances.
Selecciona soa-lab1-app.
Ve a Actions → Security → Modify IAM role.
Selecciona soa-lab1-ec2-cw-role.
Guarda el cambio.

En los detalles de la instancia, confirma que el campo IAM role muestre soa-lab1-ec2-cw-role.

Ojo: si la instancia no tiene este role, el agente puede instalarse y arrancar, pero no podrá publicar correctamente en CloudWatch.

5.2 Instalar CloudWatch Agent en la EC2

Conéctate por SSH a la instancia soa-lab1-app y ejecuta:

sudo yum -y install amazon-cloudwatch-agent || sudo dnf -y install amazon-cloudwatch-agent

Nota: usamos yum o dnf para cubrir Amazon Linux 2 y Amazon Linux 2023. Si uno no aplica, el otro debería funcionar.

5.3 Crear la configuración del agente

Ahora crea el archivo de configuración del agente. Este archivo le indica al agente qué logs enviar y qué métricas adicionales recolectar.

sudo tee /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json > /dev/null <<'EOF'
{
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/cloud-init.log",
            "log_group_name": "/soa/lab1/system",
            "log_stream_name": "{instance_id}/cloud-init"
          }
        ]
      }
    }
  },
  "metrics": {
    "metrics_collected": {
      "mem": {
        "measurement": [
          "mem_used_percent"
        ]
      },
      "disk": {
        "measurement": [
          "disk_used_percent"
        ],
        "resources": [
          "*"
        ]
      }
    }
  }
}
EOF

¿Qué estamos haciendo aquí?

Enviamos /var/log/cloud-init.log hacia CloudWatch Logs.
Usamos el Log Group /soa/lab1/system.
Creamos un Log Stream por instancia usando {instance_id}/cloud-init.
Recolectamos métricas básicas de memoria y disco.

5.4 Arrancar el agente

Ejecuta:

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config \
  -m ec2 \
  -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json \
  -s

Este comando carga la configuración local, indica que el agente corre en modo EC2 y arranca el servicio después de aplicar el archivo.

5.5 Verificar el estado del agente

Ejecuta:

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a status

La salida debe mostrar algo parecido a "status": "running".

Checkpoint

Antes de seguir, valida:

El IAM Role soa-lab1-ec2-cw-role está asociado a la instancia.
El agente está instalado.
El comando de estado muestra running.
En CloudWatch → Logs → Log groups → /soa/lab1/system aparece un Log Stream parecido a i-xxxxxxxxxxxxxxxxx/cloud-init.

Puede tardar unos minutos en aparecer. Si no aparece de inmediato, espera un poco y refresca la consola.

Paso 6 — Consultar logs con CloudWatch Logs Insights

Ya estamos enviando logs desde la instancia hacia CloudWatch. Ahora vamos a consultarlos sin entrar por SSH al servidor.

Esta es una de las primeras ganancias reales de centralizar logs: puedes investigar desde CloudWatch, filtrar eventos y revisar actividad reciente sin depender de entrar manualmente a la EC2.

Ejecutar una consulta desde la consola

En AWS Console:

Ve a CloudWatch.
En el menú izquierdo, entra a Logs → Logs Insights.
Selecciona el Log Group /soa/lab1/system.
En el editor de query, pega esta consulta:

fields @timestamp, @message
| sort @timestamp desc
| limit 20

Selecciona un rango de tiempo reciente, por ejemplo Last 15 minutes.
Ejecuta la consulta.

Deberías ver eventos recientes del archivo /var/log/cloud-init.log, con su timestamp y mensaje correspondiente.

EC2 → CloudWatch Agent → CloudWatch Logs → Logs Insights

CLI opcional

También puedes iniciar una consulta desde CloudShell o desde tu terminal con AWS CLI configurado:

REGION="us-east-1"

QUERY_ID=$(aws logs start-query --region "$REGION" \
  --log-group-name "/soa/lab1/system" \
  --start-time $(date -u -d '15 minutes ago' +%s) \
  --end-time $(date -u +%s) \
  --query-string "fields @timestamp, @message | sort @timestamp desc | limit 20" \
  --query 'queryId' \
  --output text)

echo "$QUERY_ID"

Luego consulta el resultado:

aws logs get-query-results --region "$REGION" \
  --query-id "$QUERY_ID"

Ojo: si estás en Mac y el comando date -d no funciona, ejecuta esta parte desde CloudShell o ajusta el cálculo de tiempo según tu sistema operativo.

Checkpoint

Antes de seguir, valida:

La consulta devuelve eventos.
Puedes ver timestamps recientes.
El Log Group usado es /soa/lab1/system.

Paso 7 — Crear SNS Topic y suscripción por email

Ahora necesitamos un canal de notificación. Cuando la alarma de CloudWatch cambie a estado ALARM, queremos que alguien se entere. Para este primer lab usaremos algo simple y efectivo: Amazon SNS + email.

No estamos automatizando remediación todavía. Aquí solo queremos cerrar el flujo mínimo de alerta.

Crear el SNS Topic desde la consola

En AWS Console:

Ve a Amazon SNS.
En el menú izquierdo, entra a Topics.
Selecciona Create topic.
En Type, selecciona Standard.
En Name, usa soa-lab1-alerts-v2.
Crea el topic.

Crear la suscripción por email

Ahora entra al topic soa-lab1-alerts-v2 y crea una suscripción:

Selecciona Create subscription.
En Protocol, elige Email.
En Endpoint, escribe tu correo. Ejemplo: tu-correo@dominio.com.
Selecciona Create subscription.
Abre tu correo y confirma la suscripción desde el mensaje de SNS.

Ojo: si no confirmas la suscripción, SNS no podrá enviarte notificaciones. La suscripción quedará en estado Pending confirmation.

CLI opcional

Si prefieres hacerlo por CLI:

REGION="us-east-1"
EMAIL="tu-correo@dominio.com"

TOPIC_ARN=$(aws sns create-topic --region "$REGION" \
  --name "soa-lab1-alerts-v2" \
  --query 'TopicArn' \
  --output text)

echo "$TOPIC_ARN"

aws sns subscribe --region "$REGION" \
  --topic-arn "$TOPIC_ARN" \
  --protocol email \
  --notification-endpoint "$EMAIL"

Después de ejecutar esto, revisa tu correo y confirma la suscripción.

Checkpoint

Antes de seguir, valida:

Existe el SNS Topic soa-lab1-alerts-v2.
La suscripción aparece como Confirmed.
No debe quedar en Pending confirmation.

Paso 8 — Crear la alarma de CPU y notificar a SNS

Ya tenemos logs centralizados y un canal de notificación. Ahora vamos a crear una alarma sencilla de CPU.

La idea es conectar una señal técnica con una acción operativa:

CPU alta → CloudWatch Alarm → SNS → email

Esto ya le da a Camilo una primera capacidad proactiva: no esperar a que la Sra. Blanca diga “el sistema está lento”, sino recibir una alerta cuando una métrica supere un umbral definido.

Crear la alarma desde la consola

En AWS Console:

Ve a CloudWatch → Alarms.
Selecciona Create alarm.
En Specify metric and conditions, selecciona Select metric.
Busca o navega por EC2 → Per-Instance Metrics.
Selecciona la métrica CPUUtilization correspondiente a la instancia soa-lab1-app.
Selecciona Select metric.

Configura la condición así:

Threshold type: Static.
Whenever CPUUtilization is: Greater/Equal.
Threshold value: 70.
Period: 5 minutes.
Evaluation periods: 1.
Datapoints to alarm: 1 out of 1.

Nota: para un laboratorio, este umbral nos sirve para validar el flujo. En producción, el umbral debe definirse según comportamiento real de la aplicación, baseline histórico y tolerancia del negocio.

En Configure actions:

En Alarm state trigger, selecciona In alarm.
En notificación, elige Select an existing SNS topic.
Selecciona el topic soa-lab1-alerts-v2.
Continúa con Next.

En Add name and description:

Alarm name: ALARM-soa-lab1-high-cpu.
Description opcional: CPU >= 70% durante 5 minutos. Notifica a soa-lab1-alerts-v2.

Luego revisa el resumen y selecciona Create alarm.

CLI opcional para validar

Puedes revisar que la alarma exista y que tenga acciones habilitadas:

REGION="us-east-1"

aws cloudwatch describe-alarms --region "$REGION" \
  --alarm-names "ALARM-soa-lab1-high-cpu" \
  --query "MetricAlarms[0].{AlarmName:AlarmName,StateValue:StateValue,MetricName:MetricName,Namespace:Namespace,Threshold:Threshold,Period:Period,EvaluationPeriods:EvaluationPeriods,ActionsEnabled:ActionsEnabled,AlarmActions:AlarmActions}" \
  --output table

Checkpoint

Antes de seguir, valida:

La alarma ALARM-soa-lab1-high-cpu aparece en CloudWatch → Alarms.
La métrica asociada es CPUUtilization.
El threshold está en >= 70.
Actions enabled está en Yes.
En Alarm actions aparece el SNS Topic soa-lab1-alerts-v2.

Paso 9 — Probar la alarma y confirmar el email

Crear una alarma no es suficiente. En operación, lo importante es validar que el flujo completo funciona.

Aquí vamos a probar el camino completo:

CPU alta → CloudWatch Alarm → SNS Topic → Email

La idea es generar una carga controlada en la instancia para que la alarma cambie a estado ALARM y recibas la notificación por correo.

9.1 Conectarte por SSH

Conéctate nuevamente a la instancia soa-lab1-app:

ssh -i ~/Downloads/kp-soa-lab1.pem ec2-user@<PUBLIC_IP>

Reemplaza <PUBLIC_IP> por la IP pública real de tu instancia.

9.2 Instalar `stress`

Dentro de la EC2, instala la herramienta stress:

sudo yum -y install stress || sudo dnf -y install stress

9.3 Generar carga de CPU

Ejecuta una carga controlada por unos minutos:

stress --cpu 4 --timeout 600

Este comando genera carga de CPU durante 600 segundos, es decir, 10 minutos.

Ojo: la alarma está configurada con un periodo de 5 minutos. No esperes que cambie de estado al segundo. Dale unos minutos para que CloudWatch recolecte los datos y evalúe la condición.

9.4 Validar la alarma en CloudWatch

En AWS Console:

Ve a CloudWatch → Alarms.
Abre la alarma ALARM-soa-lab1-high-cpu.
Revisa el estado.

Dependiendo del momento en que revises, podrías ver una transición parecida a esta:

INSUFFICIENT_DATA → OK → ALARM

No siempre ocurre exactamente en ese orden, pero lo importante es que la alarma llegue a estado ALARM al menos una vez.

9.5 Confirmar el correo de SNS

Revisa el correo que usaste en la suscripción de SNS. Deberías recibir una notificación con un asunto parecido a:

ALARM: "ALARM-soa-lab1-high-cpu"

Cuando termine la prueba de carga, la CPU debería bajar y la alarma volverá a OK. Esto puede tardar algunos minutos.

Checkpoint

Antes de cerrar el lab, valida:

La alarma ALARM-soa-lab1-high-cpu llegó a estado ALARM.
Recibiste el correo de SNS.
Al terminar la carga, la alarma volvió a estado OK o empezó a normalizarse.
El flujo completo quedó probado: métrica, alarma, notificación.

Clean up completo — SOA-Lab1

Ahora vamos a eliminar los recursos creados en el laboratorio. Esto evita costos innecesarios y mantiene tu cuenta limpia para futuros labs.

Trabajaremos en la región us-east-1.

Recursos a eliminar

CloudWatch Alarm: ALARM-soa-lab1-high-cpu
SNS Topic: soa-lab1-alerts-v2
CloudWatch Log Group: /soa/lab1/system
EC2 Instance: soa-lab1-app
Security Group: soa-lab1-app-sg
Key Pair: kp-soa-lab1
IAM Role: soa-lab1-ec2-cw-role

Orden recomendado

Elimina los recursos en este orden para evitar bloqueos o dependencias:

CloudWatch Alarm: elimínala primero para que deje de evaluar y notificar.
SNS Topic: borra el topic soa-lab1-alerts-v2. Al eliminarlo, también se eliminan sus suscripciones asociadas.
CloudWatch Log Group: elimina /soa/lab1/system.
EC2 Instance: termina la instancia soa-lab1-app.
Security Group: elimina soa-lab1-app-sg solo cuando la instancia ya esté terminada.
Key Pair: elimina kp-soa-lab1 desde EC2 → Key Pairs.
IAM Role: elimina soa-lab1-ec2-cw-role. Si AWS no te deja borrarlo de inmediato, revisa si aún tiene políticas asociadas o si la instancia todavía aparece vinculada.

Ojo: el Security Group puede quedar bloqueado mientras la instancia siga existiendo. Si no te deja borrarlo, espera a que la instancia quede completamente terminada y vuelve a intentar.

Validación final

Al terminar, confirma que:

No existe la alarma ALARM-soa-lab1-high-cpu.
No existe el SNS Topic soa-lab1-alerts-v2.
No existe el Log Group /soa/lab1/system.
La instancia soa-lab1-app está terminada.
No existe el Security Group soa-lab1-app-sg.
No existe el Key Pair kp-soa-lab1.
No existe el IAM Role soa-lab1-ec2-cw-role.

Troubleshooting rápido

Si algo no funciona, revisa estos puntos:

No llega el email de SNS: revisa si la suscripción quedó en Pending confirmation. Debes abrir el correo de SNS y confirmar la suscripción.
No aparecen logs en CloudWatch: confirma que el CloudWatch Agent esté en estado running y que la instancia tenga asociado el role soa-lab1-ec2-cw-role con la política CloudWatchAgentServerPolicy.
SSH no conecta: verifica que el Security Group permita SSH 22 desde tu IP pública real en formato /32. Ojo: la IP de CloudShell no necesariamente es tu IP local.
La alarma no dispara: recuerda que la alarma usa un periodo de 5 minutos. Si tarda, mantén la carga unos minutos más, usa stress --cpu 4 --timeout 600 o baja temporalmente el umbral para validar el flujo.

Well-Architected lens: ¿Qué aplicamos aquí?

Este laboratorio es pequeño, pero ya toca varios principios importantes del AWS Well-Architected Framework:

Operational Excellence: centralizamos logs y usamos Logs Insights para investigar sin depender de entrar manualmente a la instancia.
Reliability: una alarma básica permite detectar una condición anómala antes de que el problema dependa solo del reporte de un usuario.
Security: restringimos SSH a tu IP pública /32 y evitamos exponer el puerto 22 a 0.0.0.0/0.
Cost Optimization: configuramos retención corta de logs y hacemos cleanup completo al final.
Performance Efficiency: usamos una instancia pequeña y suficiente para el objetivo del lab, sin sobredimensionar recursos.

Resultado esperado

Al finalizar este laboratorio deberías tener claro cómo construir una observabilidad mínima para una instancia EC2:

Crear un Log Group en CloudWatch Logs.
Instalar y configurar CloudWatch Agent.
Consultar logs con Logs Insights.
Crear un SNS Topic con suscripción por email.
Crear una alarma de CPU.
Probar el flujo real de alerta.
Limpiar todos los recursos del laboratorio.

La idea no era montar una plataforma completa de monitoreo, sino construir una primera base operativa: ver señales, consultar evidencia y recibir una alerta cuando algo se sale del comportamiento esperado.

Referencias oficiales

¿Qué viene en el próximo lab?

En este laboratorio dejamos una capacidad mínima de observabilidad: logs centralizados, una alarma y una notificación funcionando.

Pero observar una carga es solo una parte de operar bien. También necesitamos saber quién hizo qué, cuándo lo hizo y desde dónde.

En el próximo laboratorio vamos a entrar en un tema clave de seguridad y auditoría:

SCS-Lab1 — CloudTrail: Trail + S3 + KMS + Log Validation

La idea será construir un baseline de auditoría en una cuenta AWS: crear un trail, enviar eventos a S3, protegerlos con KMS y habilitar validación de integridad de logs.

En otras palabras: pasar de “tengo señales operativas” a “tengo evidencia auditable y protegida”.

Nos vemos en el próximo laboratorio de Digital Cafe Luna.

Caso de uso

¿Qué vamos a construir?

Convención de nombres

Requisitos previos

Paso 1 — Preparar acceso por SSH

1.1 Crear el Key Pair

1.2 Crear el Security Group

CLI opcional

Checkpoint

Paso 2 — Lanzar la instancia EC2

Crear la instancia desde la consola

CLI opcional para validar

Checkpoint

Paso 3 — Conectarte por SSH y validar la instancia

Obtener la IP pública

Conectarte por SSH

Validaciones rápidas dentro de la instancia

Checkpoint

Paso 4 — Preparar CloudWatch Logs

Crear el Log Group desde la consola

CLI opcional

Checkpoint

Paso 5 — Instalar y configurar CloudWatch Agent

5.1 Crear el IAM Role para la instancia

5.2 Instalar CloudWatch Agent en la EC2

5.3 Crear la configuración del agente

5.4 Arrancar el agente

5.5 Verificar el estado del agente

Checkpoint

Paso 6 — Consultar logs con CloudWatch Logs Insights

Ejecutar una consulta desde la consola

CLI opcional

Checkpoint

Paso 7 — Crear SNS Topic y suscripción por email

Crear el SNS Topic desde la consola

Crear la suscripción por email

CLI opcional

Checkpoint

Paso 8 — Crear la alarma de CPU y notificar a SNS

Crear la alarma desde la consola

CLI opcional para validar

Checkpoint

Paso 9 — Probar la alarma y confirmar el email

9.1 Conectarte por SSH

9.2 Instalar stress

9.3 Generar carga de CPU

9.4 Validar la alarma en CloudWatch

9.5 Confirmar el correo de SNS

Checkpoint

Clean up completo — SOA-Lab1

Recursos a eliminar

Orden recomendado

Validación final

Troubleshooting rápido

Well-Architected lens: ¿Qué aplicamos aquí?

Resultado esperado

Referencias oficiales

¿Qué viene en el próximo lab?

9.2 Instalar `stress`