DEV Community: Luis Eduardo Lunar Guevara

SCS-Lab2 — Data Protection en S3 con KMS: cifrado, políticas y evidencia por CLI

Luis Eduardo Lunar Guevara — Tue, 09 Jun 2026 02:56:41 +0000

Región: us-east-1

Duración estimada: 35–55 minutos

Costo-riesgo: Bajo–Medio

Certificación: AWS Certified Security - Specialty (SCS-C03)

Dominio: Data Protection

Tarea 5.2: Design and implement controls for data at rest

Caso de uso

Camilo viene de una clase de AWS donde hablaron de Data Protection, pero se quedó con una duda que no se atrevió a preguntar al instructor:

“Ok, cifré… ¿cómo se ve eso en la realidad?”

En Digital Café Luna ya están guardando facturas y reportes en S3. La Sra. Blanca quiere que nadie lea esos documentos y que Camilo pueda demostrarle, con evidencia, que los archivos están cifrados y bajo control.

¿Qué vamos a construir?

Este laboratorio busca cerrar la brecha entre teoría y operación, vas a crear:

Un bucket S3 para documentos de Café Luna.
Una KMS key administrada por el cliente.
Cifrado por defecto en S3 usando SSE-KMS.
Una bucket policy que obligue HTTPS y uploads con la KMS key del lab.
Evidencia por CLI usando head-object, ServerSideEncryption y SSEKMSKeyId.
Cleanup completo.

)

Figura 1 — La Sra. Blanca quiere proteger facturas y reportes; Camilo configura S3 privado, KMS, políticas del bucket y valida la evidencia por CLI.

Nota de alcance

Este lab se enfoca en data at rest para objetos en S3 usando SSE-KMS. No vamos a cubrir IAM Rol, Secrets Manager, rotación de llaves ni acceso entre aplicaciones, eso lo dejamos para próximos labs.

Convención de nombres

Recurso	Nombre
KMS Key Alias	`alias/scs-lab2-data-key`
S3 Bucket	`scs-lab2-data-<tu-sufijo>`
Prefix data	`data/`
Prefix evidencia	`evidence/`
Bucket policy file	`scs-lab2-bucket-guardrails.json`

Nota práctica: el nombre del bucket debe ser único globalmente. Sugerencia puedes usar 4 números aleatorios como sufijo.

Requisitos previos

Cuenta AWS con permisos para crear recursos en S3 y KMS.
Región us-east-1.
AWS CLI configurado. Valida con aws sts get-caller-identity.
Recomendado: usar CloudShell para evitar problemas locales.

Ojo: KMS puede generar costos por key y por requests. En este lab lo mantenemos pequeño y cerramos con cleanup para evitar sustos.

Paso 1 — Preparar variables y crear la KMS key

Este lab lo haremos por CLI, es viable, limpio y nos ayuda a ganar habilidad en el CLI.

REGION="us-east-1"
LAB_ID="scs-lab2"
ACCOUNT_ID="$(aws sts get-caller-identity --query Account --output text)"

KMS_ALIAS="alias/${LAB_ID}-data-key"
KMS_DESC="SCS Lab2 - Data Protection baseline with S3 and KMS"

echo "REGION=$REGION"
echo "ACCOUNT_ID=$ACCOUNT_ID"
echo "KMS_ALIAS=$KMS_ALIAS"

Crear la KMS key:

KMS_KEY_ID="$(aws kms create-key \
  --region "$REGION" \
  --description "$KMS_DESC" \
  --key-usage ENCRYPT_DECRYPT \
  --origin AWS_KMS \
  --tags TagKey=Name,TagValue="${LAB_ID}-data-key" TagKey=Lab,TagValue="$LAB_ID" \
  --query 'KeyMetadata.KeyId' \
  --output text)"

echo "KMS_KEY_ID=$KMS_KEY_ID"

Crear el alias:

aws kms create-alias \
  --region "$REGION" \
  --alias-name "$KMS_ALIAS" \
  --target-key-id "$KMS_KEY_ID"

Obtener el ARN de la key:

KMS_KEY_ARN="$(aws kms describe-key \
  --region "$REGION" \
  --key-id "$KMS_KEY_ID" \
  --query 'KeyMetadata.Arn' \
  --output text)"

echo "KMS_KEY_ARN=$KMS_KEY_ARN"

Validar:

aws kms describe-key \
  --region "$REGION" \
  --key-id "$KMS_KEY_ID" \
  --query 'KeyMetadata.{KeyId:KeyId,Arn:Arn,State:KeyState,Manager:KeyManager}' \
  --output table

aws kms list-aliases \
  --region "$REGION" \
  --query "Aliases[?AliasName=='$KMS_ALIAS'].{AliasName:AliasName,TargetKeyId:TargetKeyId}" \
  --output table

Checkpoint

Valida que:

La key aparece en estado Enabled.
El alias alias/scs-lab2-data-key apunta a tu KMS_KEY_ID.
La key quedó taggeada con Lab=scs-lab2.

Paso 2 — Crear el bucket S3 y habilitar cifrado por defecto

Ahora crearemos un bucket privado y dejaremos cifrado por defecto con la KMS key del lab.

SUFFIX="$(printf "%04d" $((RANDOM%10000)))"
BUCKET="${LAB_ID}-data-camilo-${SUFFIX}"

echo "BUCKET=$BUCKET"

Crear bucket:

aws s3api create-bucket \
  --region "$REGION" \
  --bucket "$BUCKET"

Bloquear acceso público:

aws s3api put-public-access-block \
  --region "$REGION" \
  --bucket "$BUCKET" \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

Agregar tags:

aws s3api put-bucket-tagging \
  --region "$REGION" \
  --bucket "$BUCKET" \
  --tagging "TagSet=[{Key=Name,Value=${LAB_ID}-data-bucket},{Key=Lab,Value=$LAB_ID}]"

Configurar cifrado por defecto con SSE-KMS:

aws s3api put-bucket-encryption \
  --region "$REGION" \
  --bucket "$BUCKET" \
  --server-side-encryption-configuration "{
    \"Rules\": [
      {
        \"ApplyServerSideEncryptionByDefault\": {
          \"SSEAlgorithm\": \"aws:kms\",
          \"KMSMasterKeyID\": \"$KMS_KEY_ARN\"
        },
        \"BucketKeyEnabled\": true
      }
    ]
  }"

Validar:

aws s3api head-bucket \
  --region "$REGION" \
  --bucket "$BUCKET"

aws s3api get-public-access-block \
  --region "$REGION" \
  --bucket "$BUCKET"

aws s3api get-bucket-encryption \
  --region "$REGION" \
  --bucket "$BUCKET"

Checkpoint

Valida que:

El bucket existe.
Public Access Block está activo.
Default encryption está en aws:kms.
La KMS key corresponde a la key del lab.

Paso 3 — Subir un objeto cifrado con KMS y validarlo

Ahora vamos a subir una factura de prueba y comprobar con CLI cómo quedó guardada.

echo "Factura demo - $(date -u)" > factura-demo.txt

Subir el objeto usando SSE-KMS con la key del lab:

aws s3 cp factura-demo.txt "s3://$BUCKET/data/factura-demo.txt" \
  --region "$REGION" \
  --sse aws:kms \
  --sse-kms-key-id "$KMS_KEY_ARN"

Validar el objeto:

aws s3api head-object \
  --region "$REGION" \
  --bucket "$BUCKET" \
  --key "data/factura-demo.txt" \
  --query "{SSE:ServerSideEncryption,KMSKey:SSEKMSKeyId}" \
  --output table

Comparar alias contra la key real:

KEY_ID_FROM_ALIAS="$(aws kms list-aliases \
  --region "$REGION" \
  --query "Aliases[?AliasName=='$KMS_ALIAS'].TargetKeyId" \
  --output text)"

echo "Alias apunta a KeyId: $KEY_ID_FROM_ALIAS"
echo "Key creada en el lab: $KMS_KEY_ID"

Checkpoint

Valida que:

head-object muestra SSE = aws:kms.
SSEKMSKeyId apunta a la KMS key del lab.
El alias apunta al mismo KMS_KEY_ID.

Paso 4 — Aplicar guardrails: HTTPS y KMS key correcta

Ya tenemos cifrado por defecto, pero ahora vamos a poner guardrails para reducir errores humanos:

bloquear tráfico sin HTTPS;
bloquear uploads sin SSE-KMS explícito;
bloquear uploads con una KMS key diferente a la del lab.

Ojo: este guardrail exige intención explícita en el upload. Aunque el bucket tenga default encryption, vamos a pedir que se envíe los headers de SSE-KMS y la key correcta.

Crear la bucket policy:

cat > scs-lab2-bucket-guardrails.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::$BUCKET",
        "arn:aws:s3:::$BUCKET/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    },
    {
      "Sid": "DenyPutWithoutKMSEncryption",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::$BUCKET/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    },
    {
      "Sid": "DenyPutWithWrongKMSKey",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::$BUCKET/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption-aws-kms-key-id": "$KMS_KEY_ARN"
        }
      }
    }
  ]
}
EOF

Aplicar la policy:

aws s3api put-bucket-policy \
  --region "$REGION" \
  --bucket "$BUCKET" \
  --policy file://scs-lab2-bucket-guardrails.json

Checkpoint

Valida que get-bucket-policy devuelve la policy sin error.

aws s3api get-bucket-policy \
  --region "$REGION" \
  --bucket "$BUCKET" \
  --query Policy \
  --output text

Paso 5 — Probar el guardrail

Aquí hacemos la prueba màs importante, demostrar que el bucket bloquea uploads inseguros y acepta uploads con aws:kms y la key correcta.

Intento incorrecto: debe fallar

echo "prueba sin SSE-KMS - $(date -u)" > sin-kms.txt

aws s3 cp sin-kms.txt "s3://$BUCKET/data/sin-kms.txt" \
  --region "$REGION"

La salida esperada es un error AccessDenied.

Intento correcto: debe funcionar

aws s3 cp sin-kms.txt "s3://$BUCKET/data/con-kms.txt" \
  --region "$REGION" \
  --sse aws:kms \
  --sse-kms-key-id "$KMS_KEY_ARN"

Evidencia final

aws s3api head-object \
  --region "$REGION" \
  --bucket "$BUCKET" \
  --key "data/con-kms.txt" \
  --query "{SSE:ServerSideEncryption,KMSKey:SSEKMSKeyId}" \
  --output table

Checkpoint

Valida que:

El upload sin SSE-KMS falla.
El upload con --sse aws:kms funciona.
head-object muestra SSE = aws:kms.
SSEKMSKeyId apunta a la key del lab.

Clean up completo

Este lab deja S3 y KMS configurados. Para no dejar costos ni recursos colgados, eliminamos en este orden:

objetos;
bucket policy;
bucket;
alias;
KMS key con borrado programado.

Vaciar bucket:

aws s3 rm "s3://$BUCKET" \
  --region "$REGION" \
  --recursive

Quitar bucket policy:

aws s3api delete-bucket-policy \
  --region "$REGION" \
  --bucket "$BUCKET"

Borrar bucket:

aws s3api delete-bucket \
  --region "$REGION" \
  --bucket "$BUCKET"

Borrar alias:

aws kms delete-alias \
  --region "$REGION" \
  --alias-name "$KMS_ALIAS"

Programar borrado de la KMS key:

aws kms schedule-key-deletion \
  --region "$REGION" \
  --key-id "$KMS_KEY_ID" \
  --pending-window-in-days 7

Validar cleanup:

aws s3api head-bucket \
  --region "$REGION" \
  --bucket "$BUCKET" 2>&1 | tail -n 2

aws kms list-aliases \
  --region "$REGION" \
  --query "Aliases[?AliasName=='$KMS_ALIAS']" \
  --output table

aws kms describe-key \
  --region "$REGION" \
  --key-id "$KMS_KEY_ID" \
  --query "KeyMetadata.KeyState" \
  --output text

Ojo: 404 Not Found en el bucket es esperado si ya fue eliminado. En KMS, la key debe quedar en PendingDeletion.

Troubleshooting

AccessDenied al subir a S3: revisa si falta --sse aws:kms o si estás usando una KMS key distinta a la del lab.
KMS alias no existe: valida con aws kms list-aliases y confirma alias/scs-lab2-data-key.
head-object no muestra aws:kms: el objeto pudo subirse sin SSE-KMS. Vuelve a subirlo forzando --sse aws:kms.
No puedes borrar el bucket: elimina primero objetos, luego bucket policy y vuelve a intentar.
No puedes borrar la key de inmediato: KMS requiere borrado programado, mínimo 7 días.

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

Security: cifrado en reposo con SSE-KMS y guardrails explícitos para reducir errores humanos.
Operational Excellence: evidencia por CLI para auditar sin depender de “fe en la consola”.
Cost Optimization: lab corto y cleanup completo para controlar S3 y KMS.
Reliability: guardrails ayudan a evitar que datos entren mal configurados.

Resultado esperado

Al finalizar este laboratorio, Camilo puede demostrar con evidencia:

que un objeto en S3 quedó cifrado con aws:kms;
qué KMS key lo cifró usando SSEKMSKeyId;
que el bucket bloquea prácticas inseguras, como uploads sin SSE-KMS o con una key distinta.

La idea no era solo “activar cifrado”, sino entender cómo se ve, cómo se valida y cómo se controla.

Referencias oficiales

¿Qué viene en el próximo lab?

Camilo ya vio cómo funciona KMS, cómo se cifra un objeto, cómo se valida por CLI y cómo se aplican guardrails (básicos) en S3.

En el próximo lab subimos el nivel: trabajaremos con IAM Roles y políticas de acceso para que solo los componentes correctos puedan leer o escribir datos.

Nada de credenciales sueltas por ahí.

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

SAA-Lab1 — Scaling en AWS (baseline): ALB + Auto Scaling + CloudFront

Luis Eduardo Lunar Guevara — Mon, 01 Jun 2026 23:00:00 +0000

Región: us-east-1

Duración estimada: 35–55 minutos

Costo-riesgo: Medio

Certificación: AWS Certified Solutions Architect - Associate (SAA-C03)

Dominio: Design Secure Architectures

Tarea 1.2: Design secure workloads and applications

Caso de uso

La plataforma de Digital Café Luna venía bastante estable… hasta que se les ocurrió hacer un evento especial de fin de semana. El tráfico sube, la aplicación empieza a sentirse lenta y Camilo se da cuenta que una sola instancia no es suficiente.

La Sra. Blanca no entiende de escalamiento vertical y horizontal, ella solo quiere algo:

“Que el sistema no se caiga justo cuando más estamos vendiendo.”

Este laboratorio es el salto de un servidor único a un baseline más realista: Application Load Balancer, Auto Scaling Group y CloudFront trabajando juntos para absorber variaciones de tráfico.

No vamos a montar una arquitectura perfecta y mucho menos lista para producción.

¿Qué vamos a construir?

En este laboratorio vas a crear:

Un Application Load Balancer como punto de entrada.
Un Target Group para enrutar tráfico hacia instancias EC2.
Un Launch Template con una app básica en NGINX.
Un Auto Scaling Group con capacidad mínima distribuida en dos subnets.
Una distribución de CloudFront apuntando al ALB.
Validaciones del flujo Usuario → CloudFront → ALB → EC2.
Cleanup completo.

Figura 1 — CloudFront recibe la solicitud, la envía al ALB y el ALB distribuye tráfico hacia instancias EC2 administradas por Auto Scaling.

Nota de alcance

Usaremos la default VPC para hacer las cosas mas simple y enfocarnos en el objetivo principal.

En labs posteriores podemos madurar esto con SSM Session Manager, HTTPS end-to-end, WAF y controles más finos. Por ahora queremos entender el flujo base y verlo funcionando.

Ojo: en este baseline el ALB seguirá siendo público. CloudFront estará delante, pero no vamos a restringir todavía el ALB para aceptar tráfico únicamente desde CloudFront.

Convención de nombres

Recurso	Nombre
ALB	`saa-lab1-alb`
Target Group	`saa-lab1-tg`
Launch Template	`saa-lab1-lt`
Auto Scaling Group	`saa-lab1-asg`
Security Group ALB	`saa-lab1-alb-sg`
Security Group App/EC2	`saa-lab1-app-sg`
CloudFront Distribution	`saa-lab1-cf`
Tag estándar	`Name=<recurso>` y `Lab=saa-lab1`

Requisitos previos

Región us-east-1.
Permisos para EC2, Load Balancing, Auto Scaling y CloudFront.
Default VPC disponible.
Acceso a AWS Console y CloudShell o AWS CLI local.

Paso 1 — Identificar VPC y subnets

Necesitamos una VPC y al menos dos subnets en AZ distintas.

En AWS Console:

Ve a VPC → Your VPCs.
Verifica que estás en us-east-1.
Usa la Default VPC.
Ve a VPC → Subnets.
Identifica dos subnets en AZ distintas, por ejemplo us-east-1a y us-east-1b.

Checkpoint

Valida que:

Tienes una VPC en us-east-1.
Identificaste dos subnets en AZ distintas.

Paso 2 — Crear Security Groups

Crearemos dos Security Groups: uno para el ALB y otro para las instancias de aplicación.

Desde la consola

Security Group del ALB

Name: saa-lab1-alb-sg
Inbound: HTTP 80 desde 0.0.0.0/0
Outbound: default
Tags: Name=saa-lab1-alb-sg, Lab=saa-lab1

Security Group App/EC2

Name: saa-lab1-app-sg
Inbound: HTTP 80 desde el Security Group del ALB
Outbound: default
Tags: Name=saa-lab1-app-sg, Lab=saa-lab1

Mosca con esto: las instancias no deben recibir HTTP directo desde Internet, el tráfico debe entrar por el ALB.

Figura 2 — Security Group del ALB.

Figura 3 — Security Group App/EC2.

Checkpoint

Valida que:

El ALB SG permite HTTP desde Internet.
El App SG permite HTTP solo desde el SG del ALB.

Paso 3 — Crear Target Group, Launch Template y Auto Scaling Group

El ALB enruta tráfico hacia un Target Group. El Auto Scaling Group registra ahí sus instancias.

Crear Target Group

En AWS Console:

Ve a EC2 → Target Groups → Create target group.
Target type: Instances
Name: saa-lab1-tg
Protocol/Port: HTTP : 80
VPC: default VPC
Health check path: /
Tags: Name=saa-lab1-tg, Lab=saa-lab1

Figura 4 — Target Groups.

Crear Launch Template

En EC2 → Launch Templates → Create launch template:

Name: saa-lab1-lt
AMI: Amazon Linux 2023
Instance type: t3.nano o t3.micro
Key pair: None
Subnet: Don’t include
Security group: saa-lab1-app-sg
Auto-assign public IP: Enable
Tags: Name=saa-lab1-lt, Lab=saa-lab1

User data:

#!/bin/bash
set -euo pipefail
dnf -y update
dnf -y install nginx

cat > /usr/share/nginx/html/index.html << HTML
<!doctype html>
<html>
<head><meta charset="utf-8"><title>Digital Cafe Luna</title></head>
<body>
<h2>Digital Cafe Luna - OK</h2>
<p>Host: $(hostname)</p>
<p>Time: $(date -u)</p>
</body>
</html>
HTML

systemctl enable --now nginx

Figura 5 — Launch Templates.

Crear Auto Scaling Group

En EC2 → Auto Scaling groups → Create:

Name: saa-lab1-asg
Launch template: saa-lab1-lt
VPC: default VPC
Subnets: dos subnets en AZ distintas
Attach to load balancer: Existing target group → saa-lab1-tg
Health checks: ELB
Grace period: 60–120s
Desired: 2
Min: 2
Max: 4
Tags: Name=saa-lab1-asg, Lab=saa-lab1

Figura 6 — Auto Scaling groups.

Checkpoint

Valida que:

El ASG tiene dos instancias.
El Target Group muestra targets healthy.
Las instancias solo reciben HTTP desde el ALB SG.

Paso 4 — Crear el Application Load Balancer

Ahora crearemos el ALB, que será el origin de CloudFront y distribuirá tráfico al Target Group.

En AWS Console:

Ve a EC2 → Load Balancers → Create load balancer.
Selecciona Application Load Balancer.
Name: saa-lab1-alb
Scheme: Internet-facing
IP address type: IPv4
VPC: default VPC
Mappings: dos subnets en AZ distintas
Security Group: saa-lab1-alb-sg
Listener: HTTP 80
Default action: Forward to saa-lab1-tg

Figura 7 — Load Balancers.

Checkpoint

Valida que:

El ALB está Active.
El listener HTTP 80 envía tráfico a saa-lab1-tg.
El DNS del ALB muestra Digital Cafe Luna - OK.

Paso 5 — Crear CloudFront delante del ALB

Vamos a poner CloudFront delante del ALB para mostrar cómo una distribución global puede servir como entrada de la aplicación.

En este lab la carga no justifica CloudFront por sí sola, el objetivo de configurarlo es meramente didáctico.

Desde la consola

Ve a CloudFront → Distributions → Create distribution.

Plan: Pay as you go
Distribution name: saa-lab1-cf
Description: Digital Cafe Luna - scaling baseline
Distribution type: Single website or app
Domain: vacío, usaremos xxxxx.cloudfront.net
Origin type: Elastic Load Balancer
Origin: DNS del ALB
Origin protocol policy: HTTP only
HTTP port: 80
Cache settings: recommended/default
Security protections: deja lo incluido
Rate limiting: apagado para este lab

Ojo: Pay as you go no significa “gratis”. CloudFront puede generar costos por requests, transferencia y uso. Haz el cleanup y no pasa nada.

Ojo: HTTP only funciona porque el ALB escucha por HTTP. En producción, la mejora natural sería HTTPS end-to-end.

Checkpoint

Valida que:

La distribución pasa de Deploying a Enabled.
Tienes un dominio tipo xxxxx.cloudfront.net.
Al abrir https://xxxxx.cloudfront.net, ves Digital Cafe Luna - OK.

Paso 6 — Validación final

Confirma el flujo completo:

Usuario → CloudFront → ALB → Target Group → EC2 en Auto Scaling Group

Desde tu terminal:

CF_DOMAIN="xxxxx.cloudfront.net"

curl -I "https://$CF_DOMAIN"
curl "https://$CF_DOMAIN"

Checkpoint

Valida que:

CloudFront responde.
El ALB sigue activo.
El Target Group tiene targets healthy.
La página muestra Digital Cafe Luna - OK.

Clean up completo — SAA-Lab1

Elimina los recursos en este orden:

CloudFront
- Disable distribución saa-lab1-cf
- Espera que despliegue el cambio
- Delete distribution
Auto Scaling
- ASG saa-lab1-asg: Desired/Min = 0
- Delete ASG
- Delete Launch Template saa-lab1-lt
Load Balancing
- Delete ALB saa-lab1-alb
- Delete Target Group saa-lab1-tg
Security Groups
- Delete saa-lab1-app-sg
- Delete saa-lab1-alb-sg

Si un Security Group aparece “in use”, espera 2–3 minutos. Puede quedar una ENI pendiente.

Troubleshooting rápido

CloudFront da 504 pero el ALB responde: revisa el origin protocol. Si el ALB es HTTP, el origin debe usar HTTP.
Targets unhealthy: revisa user data, NGINX y que el App SG permita HTTP 80 desde el ALB SG.
CloudFront queda Deploying: paciencia. Puede tardar varios minutos.
SG in use al borrar: espera 2–3 minutos y reintenta.

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

Reliability: ALB + health checks + ASG para tolerar fallos y sostener capacidad.
Performance Efficiency: CloudFront ayuda a reducir latencia y carga directa al origin.
Operational Excellence: naming, tags y checkpoints hacen el lab repetible.
Cost Optimization: arquitectura mínima y cleanup completo.
Security: las instancias no reciben tráfico directo desde Internet.

Resultado esperado

Al final del lab, Camilo cuenta con un baseline real de escalamiento para Digital Café Luna: un endpoint global con CloudFront, un origin estable con ALB y capacidad elástica con Auto Scaling Group.

Referencias oficiales

¿Qué viene en el próximo lab?

Camilo escuchó en su última clase el concepto de Data Protection y se quedó con esa sensación típica:

“La teoría está buena, pero quiero verlo funcionando.”

En el próximo laboratorio vamos a aterrizarlo en Digital Café Luna con un caso simple: proteger facturas y reportes en Amazon S3.

Vamos a crear un bucket privado, habilitar SSE-KMS, usar una KMS key administrada por el cliente y aplicar políticas que obliguen el uso de HTTPS.

También validaremos la evidencia por CLI, para que Camilo entienda mejor cómo se ve el manejo de KMS en la práctica, cuándo un objeto queda cifrado con aws:kms, qué key lo protegió y cómo comprobarlo sin quedarnos solo con lo que dice la consola.

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

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

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

Región: us-east-1

Duración estimada: 35–55 minutos

Costo-riesgo: Medio

Certificación: AWS Certified Security - Specialty (SCS-C03)

Dominio: Detection

Tarea 1.2: Design and implement logging solutions

Caso de uso

Digital Cafe Luna ya superó sus primeros tropiezos operativos. La aplicación que apoya facturación e inventario funciona mejor, el negocio va creciendo y ahora más personas interactúan en la plataforma. Robert, compañero de estudio de Camilo, también está colaborando con algunos ajustes técnicos.

Un día, la Sra. Blanca nota un comportamiento extraño en el aplicativo y hace la pregunta incómoda:

“¿Quién cambió qué y cuándo?”

Camilo duda. No sabe si el cambio lo hizo él, Robert o algún proceso de la cuenta. Ahí entiende algo clave: no basta con tener recursos funcionando, se necesita trazabilidad para investigar cambios, responder con evidencia y proteger los registros que cuentan la historia de lo ocurrido.

Sin auditoría, investigar se vuelve opinión.

En este laboratorio vamos a construir un baseline de auditoría en una sola cuenta AWS usando AWS CloudTrail, Amazon S3, AWS KMS y log file validation. No es una estrategia multi-account todavía; es la base para registrar actividad, almacenar logs, cifrarlos y validar su integridad.

¿Qué vamos a construir?

En este laboratorio vas a crear:

Un CloudTrail Trail multi-region.
Un bucket S3 dedicado para logs.
Bloqueo de acceso público y versioning en S3.
Una KMS key administrada por el cliente.
Una key policy para permitir uso desde CloudTrail.
Log file validation.
Una prueba controlada para buscar evidencia en CloudTrail.
Cleanup completo.

Figura 1 — CloudTrail registra actividad, entrega logs en S3, los protege con KMS y habilita validación de integridad.

Nota de alcance

Este laboratorio se ejecuta en una sola cuenta AWS. Más adelante puede evolucionar hacia un Organization Trail, pero aquí nos enfocamos en el fundamento: crear el trail, enviar logs a S3, cifrarlos y validar integridad.

Convención de nombres

Recurso	Nombre
CloudTrail Trail	`scs-lab1-trail`
S3 Bucket	`scs-lab1-cloudtrail-logs-<tu-alias>-<4digitos>`
KMS Key Alias	`alias/scs-lab1-cloudtrail`
S3 Prefix	`cloudtrail/`

Nota práctica: el bucket de S3 debe tener un nombre único globalmente, por eso usamos <tu-alias>-<4digitos>.

Requisitos previos

Cuenta AWS con permisos para CloudTrail, S3 y KMS.
Región us-east-1.
Acceso a AWS Console y CloudShell o AWS CLI local.
Un sufijo único para el bucket. Ejemplo: camilo-4721.
Entender que este lab es single account.

Ojo: este laboratorio toca KMS. Si tu cuenta tiene políticas restrictivas, lo más común es fallar por permisos en la key policy.

Paso 1 — Crear el bucket S3 para los logs

CloudTrail necesita un destino para entregar logs. Usaremos un bucket dedicado, con acceso público bloqueado y versioning habilitado.

Crear el bucket desde la consola

En AWS Console:

Ve a S3 → Buckets.
Selecciona Create bucket.
Usa el nombre scs-lab1-cloudtrail-logs-<tu-alias>-<4digitos>.
Región: us-east-1.
Deja Block Public Access habilitado.
En Bucket Versioning, selecciona Enable.
Crea el bucket.

CLI opcional

REGION="us-east-1"
LAB_ID="scs-lab1"
ALIAS="camilo"
SUFFIX="4721"

BUCKET="${LAB_ID}-cloudtrail-logs-${ALIAS}-${SUFFIX}"

aws s3api create-bucket \
  --region "$REGION" \
  --bucket "$BUCKET"

aws s3api put-public-access-block \
  --region "$REGION" \
  --bucket "$BUCKET" \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

aws s3api put-bucket-versioning \
  --region "$REGION" \
  --bucket "$BUCKET" \
  --versioning-configuration Status=Enabled

aws s3api put-bucket-tagging \
  --region "$REGION" \
  --bucket "$BUCKET" \
  --tagging "TagSet=[{Key=Name,Value=${LAB_ID}-cloudtrail-logs},{Key=Lab,Value=${LAB_ID}}]"

aws s3api get-bucket-versioning \
  --region "$REGION" \
  --bucket "$BUCKET"

aws s3api get-public-access-block \
  --region "$REGION" \
  --bucket "$BUCKET"

Checkpoint

Valida que:

El bucket existe en us-east-1.
Block Public Access está activo.
Bucket Versioning está en Enabled.
El bucket tiene el tag Lab=scs-lab1.

Paso 2 — Crear la KMS key

Ahora crearemos una KMS key administrada por el cliente para cifrar los logs de CloudTrail con SSE-KMS.

Crear la KMS key desde la consola

En AWS Console:

Ve a KMS → Customer managed keys.
Selecciona Create key.
Tipo: Symmetric.
Uso: Encrypt and decrypt.
Alias: alias/scs-lab1-cloudtrail.
En Key administrators, selecciona tu usuario o rol administrador.
En Key users, agrega también tu usuario o rol administrador.
Crea la key.

Agregar permiso para CloudTrail

En la key:

Entra a Key policy.
Selecciona Edit.
Agrega este statement sin eliminar los permisos administrativos existentes.

{
  "Sid": "AllowCloudTrailToUseTheKey",
  "Effect": "Allow",
  "Principal": {
    "Service": "cloudtrail.amazonaws.com"
  },
  "Action": [
    "kms:GenerateDataKey*",
    "kms:Encrypt",
    "kms:Decrypt",
    "kms:DescribeKey"
  ],
  "Resource": "*"
}

Ojo: el principal debe ser cloudtrail.amazonaws.com como Service principal.

CLI opcional para validar

REGION="us-east-1"

aws kms describe-key \
  --region "$REGION" \
  --key-id "alias/scs-lab1-cloudtrail" \
  --query "{KeyId:KeyMetadata.KeyId,Arn:KeyMetadata.Arn,State:KeyMetadata.KeyState,Usage:KeyMetadata.KeyUsage}" \
  --output table

aws kms list-aliases \
  --region "$REGION" \
  --query "Aliases[?AliasName=='alias/scs-lab1-cloudtrail'].[AliasName,TargetKeyId]" \
  --output table

Checkpoint

Valida que:

La key está en estado Enabled.
El alias existe.
Tu usuario o rol conserva permisos.
La key policy permite uso desde CloudTrail.

Paso 3 — Crear el CloudTrail Trail multi-region

Ahora vamos a crear el trail para registrar actividad de la cuenta y conservar evidencia en S3.

Crear el trail desde la consola

En AWS Console:

Ve a CloudTrail → Trails.
Selecciona Create trail.
Nombre: scs-lab1-trail.
En Storage location, selecciona Use existing S3 bucket.
Elige el bucket del lab.
Si usas prefijo, coloca cloudtrail.
Habilita Log file SSE-KMS encryption.
Selecciona alias/scs-lab1-cloudtrail.
Habilita Log file validation.
Asegúrate de que sea multi-region.

En eventos:

Management events: habilitado.
Read: habilitado.
Write: habilitado.
Data events: deshabilitado.
Insights events: deshabilitado.
Network activity events: deshabilitado.

CLI opcional para validar

REGION="us-east-1"

aws cloudtrail describe-trails --region "$REGION" \
  --query "trailList[?Name=='scs-lab1-trail'].[Name,S3BucketName,IsMultiRegionTrail,KmsKeyId,LogFileValidationEnabled]" \
  --output table

aws cloudtrail get-trail-status --region "$REGION" \
  --name "scs-lab1-trail" \
  --query "{IsLogging:IsLogging,LatestDeliveryTime:LatestDeliveryTime,LatestDigestDeliveryTime:LatestDigestDeliveryTime,LatestDeliveryError:LatestDeliveryError}" \
  --output table

Checkpoint

Valida que:

IsMultiRegionTrail aparece como true.
LogFileValidationEnabled aparece como true.
IsLogging aparece como true.
LatestDeliveryError está vacío o sin errores relevantes.

Paso 4 — Generar un evento y confirmar entrega

Crear CloudTrail no basta. Hay que validar que registra eventos y entrega logs en S3.

Acción en AWS → CloudTrail → S3 bucket → Evidencia disponible

Generar un evento desde la consola

Puedes crear una access key temporal solo como evento de prueba:

Ve a IAM → Users.
Selecciona tu usuario.
Entra a Security credentials.
En Access keys, selecciona Create access key.
Crea la key solo para generar el evento.
No la uses para nada productivo.

Ojo: elimina esta access key en el cleanup.

También puedes usar un cambio menor, como agregar un tag no crítico.

Validar entrega por CLI

REGION="us-east-1"

aws cloudtrail get-trail-status --region "$REGION" \
  --name "scs-lab1-trail" \
  --query "{IsLogging:IsLogging,LatestDeliveryTime:LatestDeliveryTime,LatestDeliveryError:LatestDeliveryError}" \
  --output table

Ajusta BUCKET con tu bucket real:

REGION="us-east-1"
BUCKET="scs-lab1-cloudtrail-logs-camilo-4721"
ACCOUNT_ID="$(aws sts get-caller-identity --query Account --output text)"

aws s3 ls "s3://$BUCKET/cloudtrail/AWSLogs/$ACCOUNT_ID/" \
  --recursive \
  --human-readable \
  --summarize | tail -n 20

Si no usaste prefijo:

aws s3 ls "s3://$BUCKET/AWSLogs/$ACCOUNT_ID/" \
  --recursive \
  --human-readable \
  --summarize | tail -n 20

Paso 5 — Verificar cifrado y log file validation

Ahora validamos que los logs estén cifrados con SSE-KMS y que CloudTrail genere archivos digest para integridad.

Validar desde la consola

En AWS Console:

Ve a CloudTrail → Trails.
Abre scs-lab1-trail.
Valida:
- Log file SSE-KMS encryption: Enabled.
- AWS KMS key: alias/scs-lab1-cloudtrail.
- Log file validation: Enabled.

Confirmar por CLI

REGION="us-east-1"

aws cloudtrail describe-trails --region "$REGION" \
  --query "trailList[?Name=='scs-lab1-trail'].[Name,IsMultiRegionTrail,LogFileValidationEnabled,KmsKeyId,S3BucketName,S3KeyPrefix]" \
  --output table

Verifica objetos digest:

BUCKET="scs-lab1-cloudtrail-logs-camilo-4721"
ACCOUNT_ID="$(aws sts get-caller-identity --query Account --output text)"

aws s3 ls "s3://$BUCKET/cloudtrail/AWSLogs/$ACCOUNT_ID/CloudTrail-Digest/" \
  --recursive | tail -n 10

Verifica cifrado en un objeto real:

BUCKET="scs-lab1-cloudtrail-logs-camilo-4721"
ACCOUNT_ID="$(aws sts get-caller-identity --query Account --output text)"

OBJ_KEY=$(aws s3api list-objects-v2 \
  --bucket "$BUCKET" \
  --prefix "cloudtrail/AWSLogs/$ACCOUNT_ID/CloudTrail/" \
  --query "reverse(sort_by(Contents,&LastModified))[0].Key" \
  --output text)

echo "$OBJ_KEY"

aws s3api head-object \
  --bucket "$BUCKET" \
  --key "$OBJ_KEY" \
  --query "{SSE:ServerSideEncryption,KMSKey:SSEKMSKeyId}" \
  --output table

Salida esperada:

SSE     aws:kms
KMSKey  arn:aws:kms:...

Paso 6 — Buscar el cambio en CloudTrail

Ahora usamos CloudTrail para responder con evidencia:

“¿Quién cambió qué y cuándo?”

Buscar desde la consola

En AWS Console:

Ve a CloudTrail → Event history.
En Lookup attributes, filtra según la acción.
Si creaste una access key, busca:
- Event name: CreateAccessKey.
- Event name: DeleteAccessKey, si ya la eliminaste.
Abre el evento y revisa:
- Event name
- Event time
- User name / ARN
- Source IP address
- AWS Region
- User agent

Buscar por CLI

REGION="us-east-1"

START_TIME=$(date -u -d '60 minutes ago' +"%Y-%m-%dT%H:%M:%SZ")

aws cloudtrail lookup-events --region "$REGION" \
  --start-time "$START_TIME" \
  --max-results 10 \
  --query "Events[].{Time:EventTime,Name:EventName,User:Username,EventId:EventId}" \
  --output table

Por evento específico:

REGION="us-east-1"

aws cloudtrail lookup-events --region "$REGION" \
  --lookup-attributes AttributeKey=EventName,AttributeValue=CreateAccessKey \
  --max-results 5 \
  --query "Events[].{Time:EventTime,Name:EventName,User:Username,EventId:EventId}" \
  --output table

Detalle del evento:

REGION="us-east-1"

aws cloudtrail lookup-events --region "$REGION" \
  --lookup-attributes AttributeKey=EventName,AttributeValue=CreateAccessKey \
  --max-results 1 \
  --query "Events[0].CloudTrailEvent" \
  --output text

Ojo: si estás en Mac y date -d no funciona, ejecuta esa parte desde CloudShell o ajusta el cálculo de tiempo.

Clean up completo — SCS-Lab1

Elimina los recursos para evitar costos y mantener la cuenta limpia.

Recursos a eliminar

CloudTrail Trail: scs-lab1-trail
S3 Bucket: scs-lab1-cloudtrail-logs-<tu-alias>-<4digitos>
KMS Key: alias/scs-lab1-cloudtrail
Access key temporal: si la creaste

Orden recomendado

Elimina la access key temporal.
Elimina el CloudTrail Trail.
Vacía y elimina el S3 Bucket.
Agenda la eliminación de la KMS Key.

Desde la consola

En CloudTrail → Trails, elimina scs-lab1-trail.
En S3 → Buckets, vacía y elimina el bucket del lab.
En KMS → Customer managed keys, selecciona la key y usa Schedule key deletion.

Ojo: si versioning está habilitado, revisa versiones y delete markers antes de eliminar el bucket.

CLI opcional para validar cleanup

REGION="us-east-1"

aws cloudtrail describe-trails --region "$REGION" \
  --query "trailList[?Name=='scs-lab1-trail'].[Name]" \
  --output table

BUCKET="scs-lab1-cloudtrail-logs-camilo-4721"

if aws s3api head-bucket --bucket "$BUCKET" 2>/dev/null; then
  echo "Bucket aún existe: $BUCKET"
else
  echo "Bucket eliminado o no accesible: $BUCKET"
fi

REGION="us-east-1"

aws kms describe-key \
  --region "$REGION" \
  --key-id "alias/scs-lab1-cloudtrail" \
  --query "{KeyId:KeyMetadata.KeyId,State:KeyMetadata.KeyState,DeletionDate:KeyMetadata.DeletionDate}" \
  --output table

Troubleshooting rápido

CloudTrail no entrega logs en S3: revisa LatestDeliveryError, bucket policy, prefijo y KMS.
KMS policy falla: valida Principal.Service = cloudtrail.amazonaws.com.
No aparecen objetos digest: espera unos minutos y confirma que ya llegan logs normales.
OBJ_KEY sale como None: revisa si usaste prefijo cloudtrail.
El bucket no se deja borrar: elimina contenido, versiones y delete markers.
No puedes agendar eliminación de la KMS key: valida que sigues siendo administrador de la key.

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

Security: pasamos de sospechas a evidencia verificable.
Operational Excellence: dejamos un flujo repetible de investigación.
Reliability: reducimos cambios silenciosos sin trazabilidad.
Cost Optimization: mantenemos el lab autocontenido y con cleanup completo.
Performance Efficiency: evitamos data events e Insights para no recolectar señales innecesarias.

Resultado esperado

Al finalizar deberías poder crear un baseline de auditoría en una cuenta AWS: trail multi-region, logs en S3, cifrado con KMS, validación de integridad, búsqueda de eventos y cleanup completo.

La idea no era solo “prender CloudTrail”, sino dejar evidencia auditable, protegida y verificable.

Al final, Camilo puede responder con más claridad:

“¿Quién cambió qué y cuándo?”

Referencias oficiales

¿Qué viene en el próximo lab?

Digital Cafe Luna ya tiene una base de auditoría en una sola cuenta. El siguiente paso es prepararse para un reto real: escalar

SAA-Lab1 — Scaling en AWS (baseline): ALB + Auto Scaling + CloudFront

Montaremos un baseline de escalamiento con balanceo, escalado automático y caché en el borde, usando el dominio por defecto de CloudFront.

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

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?