Tools

Tools: SOA-Lab1 — Observabilidad mínima: CloudWatch Logs + Alarmas + SNS (2026)

2026-05-19 0 views admin
Tools: SOA-Lab1 — Observabilidad mínima: CloudWatch Logs + Alarmas + SNS (2026)

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? Región: us-east-1

Duración estimada: 35–55 minutosCosto-riesgo: BajoCertificació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 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. En este laboratorio vas a crear: 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. Usaremos el prefijo soa-lab1 para que puedas buscar, filtrar y eliminar recursos sin perder tiempo. 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. Antes de comenzar, asegúrate de tener: 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. 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. 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). Ahora crea el Security Group que permitirá SSH solo desde tu IP. 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. 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. Antes de seguir, valida: 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. Cuando la instancia esté corriendo, puedes validar con: Antes de seguir, confirma: 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. También puedes obtenerla por CLI: En los siguientes comandos usaré el placeholder <PUBLIC_IP>. Reemplázalo por la IP real de tu instancia. 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: Luego entra a la instancia: Cuando pregunte si confías en el host, responde yes. Una vez dentro, ejecuta: Y valida salida a Internet: Antes de seguir, confirma: 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. 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. Si prefieres hacerlo por CLI: Antes de seguir, valida: 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. Primero necesitamos que la EC2 tenga permisos para publicar logs y métricas en CloudWatch. Ahora asócialo a la instancia: 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. Conéctate por SSH a la instancia soa-lab1-app y ejecuta: Nota: usamos yum o dnf para cubrir Amazon Linux 2 y Amazon Linux 2023. Si uno no aplica, el otro debería funcionar. Ahora crea el archivo de configuración del agente. Este archivo le indica al agente qué logs enviar y qué métricas adicionales recolectar. ¿Qué estamos haciendo aquí? 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. La salida debe mostrar algo parecido a "status": "running". Antes de seguir, valida: Puede tardar unos minutos en aparecer. Si no aparece de inmediato, espera un poco y refresca la consola. 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. Deberías ver eventos recientes del archivo /var/log/cloud-init.log, con su timestamp y mensaje correspondiente. También puedes iniciar una consulta desde CloudShell o desde tu terminal con AWS CLI configurado: Luego consulta el resultado: 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. Antes de seguir, valida: 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. Ahora entra al topic soa-lab1-alerts-v2 y crea una suscripción: Ojo: si no confirmas la suscripción, SNS no podrá enviarte notificaciones. La suscripción quedará en estado Pending confirmation. Si prefieres hacerlo por CLI: Después de ejecutar esto, revisa tu correo y confirma la suscripción. Antes de seguir, valida: 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: 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. Configura la condición así: 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 Add name and description: Luego revisa el resumen y selecciona Create alarm. Puedes revisar que la alarma exista y que tenga acciones habilitadas: Antes de seguir, valida: 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: 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. Conéctate nuevamente a la instancia soa-lab1-app: Reemplaza <PUBLIC_IP> por la IP pública real de tu instancia. Dentro de la EC2, instala la herramienta stress: Ejecuta una carga controlada por unos minutos: 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. Dependiendo del momento en que revises, podrías ver una transición parecida a esta: No siempre ocurre exactamente en ese orden, pero lo importante es que la alarma llegue a estado ALARM al menos una vez. Revisa el correo que usaste en la suscripción de SNS. Deberías recibir una notificación con un asunto parecido a: Cuando termine la prueba de carga, la CPU debería bajar y la alarma volverá a OK. Esto puede tardar algunos minutos. Antes de cerrar el lab, valida: 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. Elimina los recursos en este orden para evitar bloqueos o dependencias: 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. Al terminar, confirma que: Si algo no funciona, revisa estos puntos: Este laboratorio es pequeño, pero ya toca varios principios importantes del AWS Well-Architected Framework: Al finalizar este laboratorio deberías tener claro cómo construir una observabilidad mínima para una instancia EC2: 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. 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. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse

Command

Copy

# 0) Variables REGION="us-east-1" MYIP="$(-weight: 500;">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 # 0) Variables REGION="us-east-1" MYIP="$(-weight: 500;">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 # 0) Variables REGION="us-east-1" MYIP="$(-weight: 500;">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 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 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 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 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 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 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 chmod 400 ~/Downloads/kp-soa-lab1.pem chmod 400 ~/Downloads/kp-soa-lab1.pem chmod 400 ~/Downloads/kp-soa-lab1.pem ssh -i ~/Downloads/kp-soa-lab1.pem ec2-user@<PUBLIC_IP> ssh -i ~/Downloads/kp-soa-lab1.pem ec2-user@<PUBLIC_IP> ssh -i ~/Downloads/kp-soa-lab1.pem ec2-user@<PUBLIC_IP> ssh -i ~/Downloads/kp-soa-lab1.pem ec2-user@3.123.45.67 ssh -i ~/Downloads/kp-soa-lab1.pem ec2-user@3.123.45.67 ssh -i ~/Downloads/kp-soa-lab1.pem ec2-user@3.123.45.67 -weight: 500;">curl -s https://checkip.amazonaws.com -weight: 500;">curl -s https://checkip.amazonaws.com -weight: 500;">curl -s https://checkip.amazonaws.com 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 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 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 -weight: 600;">sudo -weight: 500;">yum -y -weight: 500;">install amazon-cloudwatch-agent || -weight: 600;">sudo -weight: 500;">dnf -y -weight: 500;">install amazon-cloudwatch-agent -weight: 600;">sudo -weight: 500;">yum -y -weight: 500;">install amazon-cloudwatch-agent || -weight: 600;">sudo -weight: 500;">dnf -y -weight: 500;">install amazon-cloudwatch-agent -weight: 600;">sudo -weight: 500;">yum -y -weight: 500;">install amazon-cloudwatch-agent || -weight: 600;">sudo -weight: 500;">dnf -y -weight: 500;">install amazon-cloudwatch-agent -weight: 600;">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 -weight: 600;">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 -weight: 600;">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 -weight: 600;">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 -weight: 600;">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 -weight: 600;">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 -weight: 600;">sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a -weight: 500;">status -weight: 600;">sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a -weight: 500;">status -weight: 600;">sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a -weight: 500;">status fields @timestamp, @message | sort @timestamp desc | limit 20 fields @timestamp, @message | sort @timestamp desc | limit 20 fields @timestamp, @message | sort @timestamp desc | limit 20 EC2 → CloudWatch Agent → CloudWatch Logs → Logs Insights EC2 → CloudWatch Agent → CloudWatch Logs → Logs Insights EC2 → CloudWatch Agent → CloudWatch Logs → Logs Insights REGION="us-east-1" QUERY_ID=$(aws logs -weight: 500;">start-query --region "$REGION" \ --log-group-name "/soa/lab1/system" \ ---weight: 500;">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" REGION="us-east-1" QUERY_ID=$(aws logs -weight: 500;">start-query --region "$REGION" \ --log-group-name "/soa/lab1/system" \ ---weight: 500;">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" REGION="us-east-1" QUERY_ID=$(aws logs -weight: 500;">start-query --region "$REGION" \ --log-group-name "/soa/lab1/system" \ ---weight: 500;">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" aws logs get-query-results --region "$REGION" \ --query-id "$QUERY_ID" aws logs get-query-results --region "$REGION" \ --query-id "$QUERY_ID" aws logs get-query-results --region "$REGION" \ --query-id "$QUERY_ID" 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" 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" 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" CPU alta → CloudWatch Alarm → SNS → email CPU alta → CloudWatch Alarm → SNS → email CPU alta → CloudWatch Alarm → SNS → email 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 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 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 CPU alta → CloudWatch Alarm → SNS Topic → Email CPU alta → CloudWatch Alarm → SNS Topic → Email CPU alta → CloudWatch Alarm → SNS Topic → Email ssh -i ~/Downloads/kp-soa-lab1.pem ec2-user@<PUBLIC_IP> ssh -i ~/Downloads/kp-soa-lab1.pem ec2-user@<PUBLIC_IP> ssh -i ~/Downloads/kp-soa-lab1.pem ec2-user@<PUBLIC_IP> -weight: 600;">sudo -weight: 500;">yum -y -weight: 500;">install stress || -weight: 600;">sudo -weight: 500;">dnf -y -weight: 500;">install stress -weight: 600;">sudo -weight: 500;">yum -y -weight: 500;">install stress || -weight: 600;">sudo -weight: 500;">dnf -y -weight: 500;">install stress -weight: 600;">sudo -weight: 500;">yum -y -weight: 500;">install stress || -weight: 600;">sudo -weight: 500;">dnf -y -weight: 500;">install stress stress --cpu 4 --timeout 600 stress --cpu 4 --timeout 600 stress --cpu 4 --timeout 600 INSUFFICIENT_DATA → OK → ALARM INSUFFICIENT_DATA → OK → ALARM INSUFFICIENT_DATA → OK → ALARM ALARM: "ALARM-soa-lab1-high-cpu" ALARM: "ALARM-soa-lab1-high-cpu" ALARM: "ALARM-soa-lab1-high-cpu" - 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. - 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. - 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. - 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. - Si usas Mac/Linux, selecciona .pem. - Si usas Windows con PuTTY, selecciona .ppk. - 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. - 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. - 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. - 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. - VPC: default VPC. - Subnet: No preference. - Auto-assign public IP: Enabled. - Firewall: Select existing security group. - Security group: soa-lab1-app-sg. - 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. - Ve a EC2 → Instances. - Selecciona la instancia soa-lab1-app. - Copia el valor de Public IPv4 address. - Pudiste conectarte por SSH. - Ves el prompt de ec2-user. - uname -a responde correctamente. - La instancia tiene salida a Internet. - 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. - Existe el Log Group /soa/lab1/system. - La retención está configurada en 3 days. - Ve a IAM → Roles. - Selecciona Create role. - En Trusted entity type, selecciona AWS -weight: 500;">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. - Ve a EC2 → Instances. - Selecciona soa-lab1-app. - Ve a Actions → Security → Modify IAM role. - Selecciona soa-lab1-ec2-cw-role. - Guarda el cambio. - 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. - 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. - 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: - Selecciona un rango de tiempo reciente, por ejemplo Last 15 minutes. - Ejecuta la consulta. - La consulta devuelve eventos. - Puedes ver timestamps recientes. - El Log Group usado es /soa/lab1/system. - 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. - 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. - Existe el SNS Topic soa-lab1-alerts-v2. - La suscripción aparece como Confirmed. - No debe quedar en Pending confirmation. - 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. - Threshold type: Static. - Whenever CPUUtilization is: Greater/Equal. - Threshold value: 70. - Period: 5 minutes. - Evaluation periods: 1. - Datapoints to alarm: 1 out of 1. - 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. - Alarm name: ALARM-soa-lab1-high-cpu. - Description opcional: CPU >= 70% durante 5 minutos. Notifica a soa-lab1-alerts-v2. - 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. - Ve a CloudWatch → Alarms. - Abre la alarma ALARM-soa-lab1-high-cpu. - Revisa el estado. - 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. - 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 - 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. - 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. - 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. - 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. - 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. - Amazon CloudWatch Logs — Conceptos y Log Groups - CloudWatch Logs Insights — Consultas y uso - CloudWatch Alarms — Crear alarmas y acciones - Amazon SNS — Topics y suscripciones - CloudWatch Agent — Instalación y configuración en EC2

🏷️ Tags

toolsutilitiessecurity toolsobservabilidadcloudwatchalarmasconstruirconvenci

More from Tools

Tools: SSH died. Spent 3 hours fixing the wrong thing. (2026)

Tools: SSH died. Spent 3 hours fixing the wrong thing. (2026)

2026-05-20 0
Tools: Ultimate Guide: MainWP vs ManageWP vs custom scripts: how I manage 15+ WordPress sites in 2025

Tools: Ultimate Guide: MainWP vs ManageWP vs custom scripts: how I manage 15+ WordPress sites in 2025

2026-05-20 0
Tools: Metrics: How cAdvisor and CRI Collect Kubernetes Stats Kubelet

Tools: Metrics: How cAdvisor and CRI Collect Kubernetes Stats Kubelet

2026-05-20 0
Tools: Essential Guide: GPU Observability for Workloads That Cannot Phone Home

Tools: Essential Guide: GPU Observability for Workloads That Cannot Phone Home

2026-05-20 0

Trending

1

CVE-2025-61481: Critical Remote Code Execution Vulnerability in MikroTik RouterOS & SwitchOS

2025-10-27 • 189 views
2

CVE-2025-43939: Dell Unity OS Command Injection (High)

2025-10-30 • 148 views
3

Google disputes false claims of massive Gmail data breach

2025-10-30 • 130 views
4

Microsoft: DNS outage impacts Azure and Microsoft 365 services

2025-10-30 • 88 views
5

3.5B Accounts, 1 Critical Flaw: Meta Closes WhatsApp Data-Harvesting

2025-11-25 • 81 views