DEV Community: Luis Eduardo Lunar Guevara

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

Luis Eduardo Lunar Guevara — Mon, 18 May 2026 23:00:00 +0000

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.

Certificarse en AWS no debería quedarse solo en responder preguntas: nace Digital Cafe Luna

Luis Eduardo Lunar Guevara — Mon, 11 May 2026 23:00:00 +0000

Nelson: Alejandra, últimamente he estado pensando en algo que veo mucho en el mundo corporativo.

Alejandra: ¿Qué cosa?

Nelson: Que muchas veces las certificaciones terminan convertidas en una hoja de cálculo: personas certificadas, badges, métricas, cumplimiento… y sí, todo eso tiene valor. Pero me pregunto algo: ¿eso realmente garantiza que una persona pueda operar bien dentro del alcance de esa certificación?

Alejandra: O sea, ¿alguien puede aprobar el examen, pero no necesariamente saber llevar eso a la práctica?.

Nelson: Exactamente y es muy común. Puedes saber qué servicio usar para monitorear, alertar o remediar. Pero la pregunta real es otra: ¿lo sabes hacer?, ¿lo has hecho?, ¿lo puedes validar?, ¿entiendes qué riesgo estás reduciendo?

Esa conversación resume bastante bien la inquietud que me llevó a crear esta serie.

No estoy en contra de las certificaciones; al contrario, creo que certificarse ayuda a ordenar conocimiento, entender un alcance técnico y validar una base formal frente a un proveedor como AWS. El problema aparece cuando el proceso se queda solo en memorizar preguntas, ver videos, repetir respuestas y buscar pasar el examen.

Porque memorizar no es lo mismo que desarrollar capacidad operativa.

Y en cloud, como sucede con muchas otras tecnologías, tarde o temprano hay que operar. Hay que entrar a la consola, usar CLI cuando haga falta, configurar, validar, equivocarse, corregir, revisar logs, entender permisos, controlar costos, limpiar recursos y tomar decisiones con criterio.

El mercado no necesita únicamente personas certificadas, opino que el mejor escenario es otro: personas con capacidad operativa real que además, estén certificadas, ¡no lo contrario!.

La brecha

Hay muchos cursos buenos, bancos de preguntas, bootcamps y documentación. Todo eso suma. Pero veo un espacio que todavía puede trabajarse mejor, especialmente en español: laboratorios ejecutables que conecten directamente las guías oficiales de examen de AWS con habilidades prácticas.

No hablo de laboratorios sueltos ni de ejercicios genéricos. La idea es partir de los objetivos de las guías oficiales, entender el dominio, revisar la tarea que se espera dominar y llevar eso a una práctica concreta en AWS.

En otras palabras:

Guía oficial / blueprint → caso práctico → laboratorio ejecutable → checkpoints → cleanup → mirada Well-Architected

Porque nuevamente una cosa es leer que CloudWatch permite monitorear recursos y crear alarmas; otra cosa es configurar logs, crear métricas, definir una alarma, conectarla con SNS, probar si dispara, validar el flujo y limpiar todo al final para no dejar costos innecesarios.

Responder bien una pregunta no es lo mismo que ejecutar bien una práctica.

Qué significa aprender AWS

Para mí, aprender AWS no es solo saber que un servicio existe y que hace, es desarrollar criterio para entender cuándo usarlo, cuándo no, qué problema resuelve, qué costo introduce, qué riesgo reduce y cómo se comporta dentro de una arquitectura real.

En cloud casi siempre hay más de una forma de resolver un problema, pero no todas las respuestas tienen la misma calidad arquitectónica. Una opción puede funcionar, pero ser costosa. Otra puede ser segura, pero compleja de operar. Otra puede resolver el problema hoy, pero dejar una deuda enorme para el equipo que tenga que mantenerla mañana.

Por eso quiero que cada laboratorio tenga una conexión clara con el AWS Well-Architected Framework. No como decoración al final del post, sino como una forma de cerrar la práctica con criterio: operación, seguridad, confiabilidad, eficiencia, costos y sostenibilidad.

Porque que algo funcione no significa necesariamente que esté bien diseñado.

Por qué Digital Cafe Luna

Para darle continuidad a la serie voy a usar una empresa ficticia llamada Digital Cafe Luna.

Es un digital coffee shop: un espacio donde personas del mundo tech, profesionales remotos, freelancers... pueden trabajar, reunirse, tomar café y compartir comunidad.

Digital Cafe Luna empieza como una tienda física pequeña, un negocio local que poco a poco va creciendo. Primero necesita operar mejor su infraestructura básica; luego empieza a vender online, aparecen nuevas sedes, más usuarios, más datos, más riesgos, más costos y más necesidad de automatización.

Ahí es donde AWS entra en la historia. No porque sí, sino porque el crecimiento del negocio empieza a exigir capacidades reales: observabilidad, seguridad, disponibilidad, control de costos, gobierno, automatización y operación cloud.

A quién va dirigida esta serie

Esta serie es para personas que están preparando certificaciones AWS, pero no quieren quedarse solo con teoría. También es para Cloud Engineers junior, intermedios o semi-senior que ya conocen servicios, pero quieren fortalecer ejecución.

También pienso en líderes técnicos, managers, directores de arquitectura, soluciones, operaciones o delivery que necesitan entender mejor lo que viven sus equipos. Porque colegas no basta con mirar la operación desde el escritorio; hay que entender qué decisiones se toman, qué restricciones existen, qué riesgos aparecen y qué implica realmente operar una plataforma.

Y, por supuesto, también pienso en personas que vienen de otros mundos profesionales y quieren entrar a cloud de forma práctica. En mis clases he visto contadores, médicos, personas de operaciones, empleados de restaurantes, negocios y muchas otras áreas.

A ellos también les puede servir una serie así.

El método

Cada laboratorio seguirá una estructura simple:

Guía oficial / blueprint: partimos de un objetivo real del examen.
Caso práctico: lo llevamos a un escenario de Digital Cafe Luna.
Lab ejecutable: configuramos servicios reales en AWS.
Checkpoints: validamos que cada parte funcione.
CleanUp completo: eliminamos recursos para evitar costos innecesarios.
Well-Architected lens: cerramos conectando la práctica con buenas decisiones de arquitectura.

La intención no es solo crear recursos. La intención es entender el caso, ejecutar, validar, equivocarse cuando toque, corregir y aprender.

Cadencia de publicación

Mi intención es publicar un laboratorio cada semana, siempre priorizando la calidad, la ejecución real y la validación.

El detalle completo estará en Dev.to, porque ahí puedo desarrollar el caso, explicar los pasos, incluir validaciones, comandos, cleanup y cierre técnico. LinkedIn será el punto de entrada: el espacio para abrir la conversación, compartir el gancho y conectar con quienes quieran ejecutar el laboratorio completo.

Qué viene primero

El primer laboratorio será:

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

Un punto sencillo para empezar, pero muy importante: si no puedes observar una carga, tampoco puedes operarla bien, mucho menos garantizar su disponibilidad.

Para cerrar

Esta serie no nace desde el ego de “miren lo que sé”. Nace desde una idea mucho más práctica: compartir mientras aprendo, ordenar conocimiento mientras lo explico y madurar capacidades mientras diseño laboratorios que otras personas también puedan ejecutar.

Mi invitación es simple:

Planifica tu tiempo.
Toma el control de tu aprendizaje.
Ejecuta los laboratorios.
Rompe cosas en ambientes controlados.
Valida, corrige, limpia y repite.

Ahí es donde la teoría empieza a convertirse en habilidad.

Nos vemos en el primer laboratorio de Digital Cafe Luna.

Trabajo remoto y cultura tóxica: lo que nadie dice

Luis Eduardo Lunar Guevara — Thu, 07 Aug 2025 01:00:00 +0000

¿Productividad o autoexplotación digital?

Antes, ibas al trabajo. Ahora, el trabajo entra al baño contigo.

Literal.

Antes había oficinas, reuniones presenciales, pausas para almorzar (o no), pero sabías que estabas en una reunión, en un lugar de trabajo.

Hoy, con el trabajo remoto, hemos normalizado lo insostenible:

Reuniones desde el inodoro (lavatory).
Almuerzos frente a tres pantallas.
Tres videollamadas al mismo tiempo… y al final, no estás realmente en ninguna.
Responder un Slack mientras estás en una llamada por Teams y compartes pantalla en Zoom.

No es una exageración. Es la vida diaria de miles.

Cultura de LinkedIn vs. realidad interna.

Y lo peor no es eso.

Lo peor es que muchas de las organizaciones que promueven esta dinámica son las que se llenan la boca con términos como “automatización”, “agilidad”, “eficiencia operacional” y “upskilling”.
Venden transformación digital, pero no transforman su propia cultura.

Mientras tanto, sus propios equipos no tienen tiempo para aprender, ni para comer, ni para vivir. Y no hablemos de innovar.

Estar siempre conectados no es estar comprometidos.

¿En qué momento se culturizó lo anormal?

Hoy muchas organizaciones que miden el compromiso por conexión, no por impacto.
Celebran “estar siempre disponibles”, cuando eso es sinónimo de estar siempre agotados.

Vale la pena insistir en esto: el problema no es el trabajo remoto. El problema es cómo se ha malinterpretado.

Porque la eficiencia mal gestionada se convierte en desgaste. Y ese desgaste termina afectando lo que más debería importar: el servicio, la calidad y la experiencia del cliente.

Lo que compran los clientes… no siempre es valor.

En este escenario, algunos clientes muchas veces no compran servicios.
Compran seguridad financiera: una gran marca que les da tranquilidad, aunque detrás haya desorden, rotación, burnout y servicios mediocres.

Mientras tanto, empresas más pequeñas, más organizadas, con talento de verdad, metodologías claras, mejores precios, prestan mejores servicios… Pero no tienen el músculo financiero para entrar a competir.

Talento promedio no escala. Talento quemado, tampoco.

¿Y quién paga el precio?

El colaborador.
Que trabaja por inercia.
Que se sostiene solo por el salario y la responsabilidad familiar.
Que va perdiendo salud, motivación… y a veces hasta sentido.

¿Y qué pasa con los equipos?

El techo de muchos prestadores de servicios proviene de tener una operación imposible de escalar.
Porque si el día a día está desordenado, saturado, caótico… No hay espacio para construir talento de verdad.

Y al escalar, no se puede permitir talento promedio.
Se necesita gente que piense, que resuelva problemas reales, con experiencia relevante y energía disponible.
No basta una lista de certificados si detrás no hay tiempo, guía ni contexto para que ese conocimiento se transforme en valor real.

Y cuando logran hacerlo (con esfuerzo, con entrega) muchas veces terminan yéndose.
Porque sin una cultura que acompañe el desarrollo operativo, el talento no florece… se fuga.

A veces me pregunto:
¿Qué pasaría si en los procesos licitatorios o RFP también se solicitará el porcentaje de rotación del personal?
¿O es que eso no es una variable crítica para sostener operaciones tecnológicas de alto impacto?

¿Y si lo hiciéramos diferente?.

No se trata solo de tiempo.
Se trata de foco, salud y claridad.

Y de imaginar:
¿Qué pasaría si todo eso que le ofrecemos a nuestros clientes… lo aplicáramos primero en nuestros equipos?

Si usáramos el agilismo no solo como discurso comercial, sino como modelo operativo real.
Si automatizáramos el caos interno antes de vender eficiencia externa.
Si el aprendizaje fuese parte del flujo de trabajo, no un lujo fuera de horario.
Si la cultura no se resumiera en frases de PowerPoint, sino en prácticas vividas.

¿Qué pasaría si de verdad invirtiéramos en capacidades internas, con la misma urgencia con la que lanzamos propuestas a los clientes?

Respuesta: Pasaría lo bueno, escalable y sostenible.

Equipos más enfocados, con mejor energía, con ideas frescas, con soluciones que nacen desde la experiencia… y no desde la fatiga.

Y sí: Ahí sí podríamos honrar esas frases que tanto usamos:

“Nos debemos a nuestros clientes.”
“Lo más importante son las personas.”

Y ahora, ¿qué hacemos?

No tengo todas las respuestas. Pero sí sé que esto hay que conversarlo.

Porque si queremos que nuestros servicios escalen, primero tenemos que huir del caos y del estancamiento.

Lo insostenible no crece. Lo ordenado, sí.

No se trata de atacar el trabajo remoto.
Se trata de no seguir normalizando lo insostenible.

¿Estás gestionando el talento… o solo apagando fuegos?

DEV Community: Luis Eduardo Lunar Guevara

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

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?

Certificarse en AWS no debería quedarse solo en responder preguntas: nace Digital Cafe Luna

La brecha

Qué significa aprender AWS

Por qué Digital Cafe Luna

A quién va dirigida esta serie

El método

Cadencia de publicación

Qué viene primero

Para cerrar

Trabajo remoto y cultura tóxica: lo que nadie dice

¿Productividad o autoexplotación digital?

Antes, ibas al trabajo. Ahora, el trabajo entra al baño contigo.

Cultura de LinkedIn vs. realidad interna.

Estar siempre conectados no es estar comprometidos.

Lo que compran los clientes… no siempre es valor.

Talento promedio no escala. Talento quemado, tampoco.

¿Y si lo hiciéramos diferente?.

Y ahora, ¿qué hacemos?

9.2 Instalar `stress`