SOA-Lab1 — Observabilidad mínima: CloudWatch Logs + Alarmas + SNS
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.
- Si usas Mac/Linux, selecciona
- 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, puerto22, sourceMy 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:
MYIPdebe 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
22solo 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 permitet3.nano, usat3.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
Runningy con2/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-appestá en estadoRunning. - Tiene
Public IPv4 address. - Tiene el Security Group
soa-lab1-app-sg. - Tiene los tags
Name=soa-lab1-appyLab=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 [email protected]
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 -aresponde 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
yumodnfpara 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.loghacia 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-roleestá 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 -dno 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:
[email protected]. - 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="[email protected]"
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
CPUUtilizationcorrespondiente a la instanciasoa-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-cpuaparece 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-cpullegó a estadoALARM. - Recibiste el correo de SNS.
- Al terminar la carga, la alarma volvió a estado
OKo 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-sgsolo cuando la instancia ya esté terminada. -
Key Pair: elimina
kp-soa-lab1desde 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-appestá 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
runningy que la instancia tenga asociado el rolesoa-lab1-ec2-cw-rolecon la políticaCloudWatchAgentServerPolicy. -
SSH no conecta: verifica que el Security Group permita SSH
22desde 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 600o 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
/32y evitamos exponer el puerto 22 a0.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
- 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
¿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.
