DEV Community: Byron Antonio Lainez Sasvin

MITRE ATT&CK: el mapa del crimen que todo profesional de seguridad debería conocer

Byron Antonio Lainez Sasvin — Fri, 01 May 2026 16:37:45 +0000

En ciberseguridad hay frameworks que son bonitos en papel y nadie usa en la vida real. Y luego está MITRE ATT&CK — que usan los equipos de threat intelligence de Microsoft, CrowdStrike, Mandiant y básicamente cualquier SOC que se tome en serio su trabajo.

La diferencia es que ATT&CK no es teoría. Es una base de datos viva de cómo atacan los adversarios reales, construida a partir de incidentes reales documentados. Si quieres entender al atacante, primero necesitas hablar su idioma.

La analogía: el manual del ladrón profesional

Imagina que eres detective y quieres atrapar a ladrones de bancos. Tienes dos opciones:

  🔍 Opción A — Sin MITRE

Llegas al banco robado, ves que falta dinero, y tratas de adivinar cómo entraron. Cada robo lo investigas desde cero. No sabes si van a volver, ni qué van a intentar después.

  🗺️ Opción B — Con MITRE

Tienes un catálogo detallado de cómo operan los grupos de ladrones más peligrosos del mundo. Sabes que el Grupo A siempre entra por el sótano, deshabilita las cámaras antes de actuar, y siempre ataca un viernes. Cuando ves las señales, sabes exactamente qué va a pasar después.

Eso es MITRE ATT&CK para ciberseguridad: el catálogo de cómo operan los atacantes reales, paso a paso.

¿Qué es MITRE ATT&CK exactamente?

MITRE es una organización sin fines de lucro que trabaja con el gobierno de EE.UU. en investigación de seguridad. En 2013 empezaron a documentar las técnicas que usaban los atacantes reales en incidentes reales. Hoy, esa base de datos se llama ATT&CK (Adversarial Tactics, Techniques & Common Knowledge) y tiene más de 600 técnicas documentadas.

El framework se organiza en una matriz: las columnas son tácticas (el objetivo del atacante en esa fase) y las filas son técnicas (cómo lo consigue).

    TA0043
    Reconnaissance
    43 técnicas


    TA0042
    Resource Development
    8 técnicas


    TA0001
    Initial Access
    10 técnicas


    TA0002
    Execution
    14 técnicas


    TA0003
    Persistence
    20 técnicas


    TA0004
    Privilege Escalation
    14 técnicas


    TA0005
    Defense Evasion
    43 técnicas


    TA0006
    Credential Access
    17 técnicas


    TA0007
    Discovery
    32 técnicas


    TA0008
    Lateral Movement
    9 técnicas


    TA0009
    Collection
    17 técnicas


    TA0011
    Command & Control
    18 técnicas


    TA0010
    Exfiltration
    9 técnicas


    TA0040
    Impact
    14 técnicas

Cada táctica responde a la pregunta "¿qué quiere lograr el atacante ahora?" y cada técnica responde "¿cómo lo está haciendo?"

Un ataque real traducido a MITRE ATT&CK

Así se ve un ataque de ransomware típico cuando lo mapeas al framework. En lugar de "nos hackearon", tienes exactamente qué pasó en cada fase:

  🎯 Ataque de ransomware — mapeado a ATT&CK

    Paso 1

      El atacante envía un email con un Excel malicioso al área de contabilidad.
      → T1566.001 · Phishing: Spearphishing Attachment (Initial Access)



    Paso 2

      El Excel ejecuta una macro que descarga un payload de internet.
      → T1059.005 · Command & Scripting: Visual Basic (Execution)



    Paso 3

      El malware se registra en el inicio de Windows para sobrevivir reinicios.
      → T1547.001 · Boot or Logon Autostart: Registry Run Keys (Persistence)



    Paso 4

      Roba las credenciales de la memoria RAM del sistema.
      → T1003.001 · OS Credential Dumping: LSASS Memory (Credential Access)



    Paso 5

      Usa esas credenciales para moverse a otros equipos de la red.
      → T1021.002 · Remote Services: SMB/Windows Admin Shares (Lateral Movement)



    Paso 6

      Cifra todos los archivos y deja la nota de rescate.
      → T1486 · Data Encrypted for Impact (Impact)

Cuando documentas incidentes así, dejas de decir "nos hackearon" y empiezas a decir "el adversario usó T1566 para el acceso inicial y T1003 para escalar privilegios". Eso le dice a tu equipo exactamente qué buscar y cómo defenderse.

¿Por qué deberías aprenderlo si trabajas en seguridad?

    SOC Analyst
    Triaje más rápido
    Cuando ves una alerta de EDR, el ID de técnica ATT&CK te dice exactamente qué está pasando y qué revisar a continuación. Sin ATT&CK, investigas a ciegas.


    Threat Intelligence
    Lenguaje común
    Todos los reportes de inteligencia serios (Mandiant, CrowdStrike, CISA) usan IDs ATT&CK. Sin conocerlo, lees los reportes a medias.


    Blue Team
    Detecciones basadas en comportamiento
    Construir reglas de detección por técnica ATT&CK es más efectivo que buscar firmas de malware. Los atacantes cambian herramientas, pero las técnicas se repiten.


    Red Team / Pentester
    Simular adversarios reales
    Los ejercicios de adversary emulation usan ATT&CK para simular grupos APT específicos. Es el estándar para engagements serios.

💡

💡 Por qué importa en LATAM específicamente
Las herramientas que usamos en la región — CrowdStrike, SentinelOne, Sophos — todas mapean sus detecciones a ATT&CK. Cuando ves una alerta en el dashboard y dice T1055 - Process Injection, estás viendo ATT&CK. Si no sabes qué significa, estás perdiendo contexto en cada alerta del día.

Las 3 capas que necesitas entender

MITRE ATT&CK
> ├── Tácticas (14 en total)          ← El "qué quiere lograr"
> │   └── TA0001: Initial Access
> │   └── TA0002: Execution
> │   └── ... (12 más)
> │
> ├── Técnicas (~200)                 ← El "cómo lo hace"
> │   └── T1566: Phishing
> │   └── T1059: Command & Scripting
> │   └── ...
> │
> └── Sub-técnicas (~400)             ← El detalle específico
>     └── T1566.001: Spearphishing Attachment
>     └── T1566.002: Spearphishing Link
>     └── ...

No necesitas memorizar las 600+ técnicas. Necesitas entender la estructura y saber dónde buscar. Con el tiempo, las más comunes se te van a quedar solas — porque las verás en alertas reales todos los días.

Cómo empezar sin abrumarte

✅

✅ Plan de 3 pasos
Paso 1 — Aprende las 14 tácticas. Solo los nombres y el objetivo de cada una. Con eso ya tienes el mapa general.
Paso 2 — Estudia las técnicas más comunes. T1566 (Phishing), T1059 (Scripts), T1003 (Credential Dumping), T1486 (Ransomware). Las verás en el 80% de los incidentes reales.
Paso 3 — Mapea un incidente real. Toma cualquier reporte de threat intel (los de CISA son públicos) y trata de identificar las técnicas ATT&CK. Eso vale más que cualquier curso.

El recurso que construí para practicarlo

Aprender ATT&CK de memoria leyendo la documentación oficial es un camino lento y aburrido. Por eso construí MITRE ATT&CK Learning: una plataforma para estudiar las tácticas y técnicas con flashcards y modo quiz, en español, de forma interactiva.

La idea es la misma que con las guías de certificaciones: apréndes haciendo, no leyendo. Repasas las técnicas, las clasificas, y el modo quiz te fuerza a asociar nombres con descripciones reales.

💡

🔗 Recurso
mitre-attack-learning.byronlainez.click — Gratis, sin registro, en español.

Conclusión

MITRE ATT&CK no es un certificación ni un examen. Es el lenguaje que usa la industria para hablar de cómo atacan los adversarios. Si trabajas en ciberseguridad y no lo conoces, estás en la misma situación que un médico que no sabe anatomía: puedes trabajar, pero siempre vas a tener puntos ciegos.

Lo bueno es que tampoco necesitas un año para aprenderlo. Con las 14 tácticas claras y las técnicas más comunes internalizadas, ya puedes leer reportes de inteligencia, entender alertas de tu EDR y tener conversaciones mucho más precisas con tu equipo.

⚠️

⚠️ La única trampa
ATT&CK se actualiza constantemente — MITRE añade técnicas nuevas con cada versión. No lo trates como algo que "terminas de aprender". Es una referencia viva que vas a consultar toda tu carrera.
Compartir

  🐦 Twitter/X
  💼 LinkedIn
¿Te fue útil?

Mando contenido así cuando tengo algo que vale la pena.
    Suscribirse





    ← Anterior
    ¿Qué significan esas letras del CVSS? Guía para entenderlo de una vez


    Todos los posts →
    Ver el blog completo








byron.lainez
© 2026 · Guatemala 🇬🇹

Mapa de Ciberseguridad en AWS: Guía Completa de Servicios

Byron Antonio Lainez Sasvin — Wed, 29 Apr 2026 21:13:36 +0000

Aprender seguridad en AWS puede ser abrumador. Entras a la consola y ves una lista interminable de nombres que parecen sacados de una película de ciencia ficción. Pero si los agrupamos por su funcionalidad real, todo empieza a tener sentido.

He diseñado este mapa mental dividido en 6 categorías críticas que cubren todo el espectro de protección en la nube.

1. IAM & Identidad: Quién entra y qué hace

La identidad es el nuevo perímetro. Aquí es donde decides quién puede tocar tus recursos.

IAM (Identity and Access Management): La base de todo. Usuarios, grupos, roles y políticas (JSON) para dar permisos granulares.
Cognito: El servicio para tus aplicaciones móviles y web. Maneja el login de tus usuarios finales (Facebook, Google, Apple o email propio).
IAM Identity Center: (Antes AWS SSO). La forma moderna de gestionar el acceso centralizado a múltiples cuentas de AWS desde un solo lugar.

2. Detección y Respuesta: El equipo de vigilancia

Estos servicios te avisan cuando las cosas se ponen feas o te ayudan a investigar qué pasó.

GuardDuty: Detección inteligente de amenazas basada en logs (DPI, DNS, CloudTrail). Es tu sistema de alarmas.
Security Hub: El agregador central. Revisa si cumples mejores prácticas y centraliza las alertas de otros servicios.
Detective: Te ayuda a hacer "forensics". Analiza la raíz de un incidente visualizando las conexiones y comportamientos previos de un atacante.

✅

💡 Tip Pro
Activa GuardDuty y Security Hub desde el primer día. Son esenciales para saber si alguien está intentando entrar en tu cuenta.

3. Protección de Red y Aplicaciones: Blindaje exterior

Protección contra ataques desde Internet.

AWS Shield: Protección contra ataques DDoS (denegación de servicio). El nivel estándar es gratis y automático.

WAF (Web Application Firewall): Filtra el tráfico HTTP/S. Bloquea inyecciones SQL, Cross-Site Scripting (XSS) y ataques de bots.

Network Firewall: Un firewall de red tradicional (inspección de paquetes a nivel 3-7) para proteger toda tu VPC.

4. Cifrado y Datos: Protegiendo el tesoro

Si el atacante entra, que no pueda leer nada.

KMS (Key Management System): Gestión de llaves para cifrar casi cualquier recurso (S3, EBS, RDS).

CloudHSM: Hardware de seguridad dedicado para cuando necesitas control total sobre las llaves físicas (regulatorio).

Secrets Manager: Centraliza tus contraseñas de BD y API Keys con rotación automática. No más "hardcode" en el código.

Macie: Usa IA para encontrar datos sensibles (DPI, tarjetas de crédito, nombres) que hayas dejado olvidados en S3.

5. Auditoría y Cumplimiento: Manteniéndolo legal

Demuestra que estás haciendo lo que dices que haces.

CloudTrail: El "CCTV" de AWS. Registra cada API call. Quién hizo qué, cuándo y desde dónde.

AWS Config: Historial de cambios en tus recursos. Te permite volver atrás en el tiempo para ver cómo estaba configurado un recurso hace 3 meses.

Audit Manager: Automatiza la recolección de evidencia para auditorías (ej: SOC2, PCI, HIPAA).

6. El futuro: Seguridad con IA

Las nuevas herramientas que están cambiando el juego.

Security Agent: Evaluación automática de vulnerabilidades en tiempo de ejecución.

GuardDuty XTD: Detección extendida que ahora analiza comportamientos más profundos en servicios de bases de datos y contenedores sin necesidad de agentes complejos.

Conclusión

No necesitas usar los 20+ servicios a la vez. Empieza por IAM, activa CloudTrail, protege tus datos con KMS/Secrets Manager y mantén la vista puesta en GuardDuty/Security Hub. La seguridad en la nube no es un destino, es un proceso continuo.
Compartir

  🐦 Twitter/X
  💼 LinkedIn
¿Te fue útil?

Mando contenido así cuando tengo algo que vale la pena.
    Suscribirse





    ← Anterior
    GuardDuty vs Security Hub








byron.lainez
© 2026 · Guatemala 🇬🇹

Responsabilidad compartida en AWS: si no la entiendes, no puedes proteger la nube

Byron Antonio Lainez Sasvin — Tue, 14 Apr 2026 04:20:58 +0000

Cuando alguien me dice "usamos AWS, estamos seguros", sé de inmediato que hay una conversación pendiente. AWS es uno de los proveedores de nube más seguros del mundo. Y al mismo tiempo, todos los años hay miles de brechas de datos en AWS. Las dos cosas son verdad al mismo tiempo — y el modelo de responsabilidad compartida explica exactamente por qué.

Entender esto no es preparación para el examen CCP. Es la base sin la cual no puedes tomar ninguna decisión de seguridad en la nube de forma correcta.

La analogía del apartamento

Imagina que rentas un apartamento en un edificio seguro:

  🏢 Analogía

El edificio (AWS) es responsable de: la estructura del edificio, el sistema eléctrico, el ascensor, las cámaras del lobby, la seguridad de la entrada principal, el mantenimiento de las áreas comunes.

Pero tú eres responsable de: no dejar la puerta de tu apartamento abierta, no darle la llave a cualquiera, no dejar objetos de valor a la vista, cambiar la cerradura si pierdes una llave.

Si dejas la puerta abierta y te roban, el edificio no tiene la culpa. Aunque el lobby esté perfectamente vigilado.

AWS es el edificio. Tu cuenta, tus datos, tu configuración — eso es tu apartamento. Son dos responsabilidades distintas, y ninguna cubre a la otra.

Qué protege AWS y qué proteges tú

    AWS protege — "Seguridad DE la nube"

Hardware físico de los data centers (servidores, switches, storage)
Infraestructura de red global (fibra, routers, DDoS a nivel de red)
Hipervisores y aislamiento entre clientes
Seguridad física: acceso biométrico, cámaras, guardias 24/7
Software de los servicios administrados (RDS, Lambda, S3 en su núcleo)
Parches del sistema operativo en servicios managed (RDS, ECS Fargate)
Disponibilidad y resiliencia de la infraestructura global
Certificaciones de cumplimiento: ISO 27001, SOC 2, PCI DSS (la infraestructura)
```
Tú proteges — "Seguridad EN la nube"
```
Configuración de IAM: usuarios, roles, políticas, permisos
Configuración de red: Security Groups, NACLs, VPC, rutas
Cifrado de datos en tránsito y en reposo (tú decides si lo activas)
Parches del OS en EC2 (si usas instancias, tú las parcheas)
Configuración de S3: permisos de bucket, políticas, ACLs
Datos de clientes y su clasificación
Aplicaciones que despiegas: código, dependencias, vulnerabilidades
Configuración de logging: CloudTrail, VPC Flow Logs, S3 access logs
MFA, rotación de credenciales, gestión de API keys

⚠️

⚠️ El error más común
Pensar que porque AWS tiene ISO 27001 y SOC 2, tu cuenta también está certificada. No. Esas certificaciones cubren la infraestructura de AWS. Tu workload necesita su propio proceso de cumplimiento, con tus propias configuraciones.

Cómo cambia según el tipo de servicio

Esto es lo que complica el modelo: la división de responsabilidad no es siempre la misma. Cambia dependiendo del tipo de servicio que uses.
      Servicio
      Tipo
      OS / Plataforma
      App / Datos
      Red / Firewall




      EC2
      IaaS
      Tú
      Tú
      Tú


      RDS
      PaaS
      AWS
      Tú
      Tú


      Lambda
      Serverless
      AWS
      Tú
      Compartido


      S3
      Storage
      AWS
      Tú
      Tú


      EKS (K8s)
      Managed
      Compartido
      Tú
      Tú


      Fargate
      Serverless containers
      AWS
      Tú
      Compartido
La regla general: mientras más "managed" sea el servicio, más responsabilidad asume AWS. Pero tus datos, tu configuración y tus permisos siempre son tuyo — sin importar qué servicio uses.

Casos reales donde la confusión sale cara
  💥 Caso 1 — S3 bucket público
Una empresa sube documentos de clientes a S3. Asumen que "AWS lo protege". Nadie revisa la configuración del bucket. Resulta que el bucket tiene acceso público activado — cualquiera en internet podía descargar los archivos con solo conocer la URL. AWS nunca falló. La configuración fue responsabilidad del equipo y nadie la auditó. Resultado: brecha de datos, multa por GDPR.
  💥 Caso 2 — EC2 sin parches
Un equipo lanza instancias EC2 con Ubuntu. AWS garantiza que el hipervisor está seguro y actualizado. Pero el sistema operativo dentro de la instancia es responsabilidad del equipo. Nadie configura actualizaciones automáticas. Seis meses después, una vulnerabilidad conocida (con CVE y parche disponible) es explotada. AWS hizo su parte. El equipo no hizo la suya.
  💥 Caso 3 — IAM con permisos de admin para todo
Un desarrollador crea un usuario IAM con AdministratorAccess "para que no haya problemas de permisos". Las credenciales quedan hardcodeadas en el código, se suben a GitHub. Un bot escanea GitHub, encuentra las keys, las usa para lanzar 500 instancias EC2 minando criptomonedas. Factura de $45,000 en 72 horas. AWS detectó el tráfico anómalo, pero la configuración IAM fue decisión del equipo.

💡

💡 El patrón en los tres casos
AWS funcionó exactamente como debía. La infraestructura estuvo disponible y segura. El problema fue siempre en la capa de responsabilidad del cliente: configuración, permisos, actualizaciones. Eso es lo que el modelo de responsabilidad compartida intenta dejar claro desde el inicio.

Lo que sí deberías tener siempre activo en tu cuenta

Si entiendes el modelo, sabes que estas configuraciones son tuya — AWS no las activa por ti:

# Controles mínimos que tú debes configurar (AWS no lo hace por ti)
> 
> [ ] CloudTrail activado en todas las regiones     → quién hizo qué y cuándo
> [ ] MFA en el root account                        → la cuenta más poderosa
> [ ] MFA en todos los usuarios IAM con consola     → acceso humano protegido
> [ ] No usar el root account para operaciones      → principio de mínimo privilegio
> [ ] GuardDuty activado                            → detección de amenazas en tu cuenta
> [ ] AWS Config activado                           → auditoría de configuración
> [ ] Security Hub activado                         → panel centralizado de hallazgos
> [ ] Alertas de billing                            → detectar actividad anómala por costo
> [ ] S3 Block Public Access a nivel de cuenta      → evitar buckets accidentalmente públicos
> [ ] VPC Flow Logs activados                       → visibilidad de tráfico de red
> [ ] Rotación automática de secrets (Secrets Manager) → credenciales que no envejecen

✅

✅ La pregunta que debes hacerte siempre
Antes de asumir que un servicio AWS "ya viene seguro", pregúntate: ¿esto está en la capa de infraestructura o en la capa de configuración? Si es configuración, es tuya. Si no estás seguro, revisa la documentación del servicio en la sección "Security" — AWS siempre documenta qué protege y qué no.

Por qué esto importa más allá de la certificación

El modelo de responsabilidad compartida aparece en el examen AWS CCP como pregunta de opción múltiple. Pero en el trabajo real, es la base de cada conversación de seguridad que vas a tener sobre infraestructura en la nube:

Cuando un cliente pregunta "¿está seguro en AWS?" — necesitas saber qué parte de "seguro" puedes garantizar tú y qué parte garantiza AWS.

Cuando haces una auditoría de seguridad — necesitas saber qué controles buscar en la cuenta del cliente vs. qué asumir que AWS ya maneja.

Cuando diseñas una arquitectura — necesitas saber qué servicio te da más control (EC2) vs. cuál te quita responsabilidad operativa (Fargate, RDS).

Cuando responder un incidente en la nube — necesitas saber exactamente dónde buscar: en tu configuración, no en la infraestructura de AWS.

Conclusión

AWS puede ser el proveedor de nube más seguro del mundo y al mismo tiempo alojar miles de cuentas mal configuradas. No hay contradicción. La seguridad de la infraestructura es de AWS. La seguridad de lo que construyes sobre esa infraestructura es tuya.

Entender eso no es opcional si trabajas en la nube. Es el punto de partida. Sin ese entendimiento, no sabes qué revisar, no sabes qué preguntar, y no sabes de quién es la culpa cuando algo sale mal.

⚠️

⚠️ Para recordar siempre
"AWS es responsable de la seguridad DE la nube. Tú eres responsable de la seguridad EN la nube."
Una letra cambia todo. De la nube vs. en la nube. Tatúatelo.
Compartir

  🐦 Twitter/X
  💼 LinkedIn
¿Te fue útil?

Mando contenido así cuando tengo algo que vale la pena.
    Suscribirse





    ← Anterior
    MITRE ATT&CK: el mapa del crimen que todo profesional de seguridad debería conocer


    Todos los posts →
    Ver el blog completo








byron.lainez
© 2026 · Guatemala 🇬🇹

GuardDuty vs Security Hub: ¿Cuál es la diferencia y cómo usarlos juntos?

Byron Antonio Lainez Sasvin — Mon, 13 Apr 2026 03:40:29 +0000

Si alguna vez has entrado a la consola de AWS buscando "cómo asegurar mi cuenta", te habrás topado con estos dos servicios. A primera vista parecen hacer lo mismo: "ayudarte con la seguridad". Pero en la práctica, cumplen roles totalmente distintos y complementarios.

GuardDuty: El detective que nunca duerme

Piensa en GuardDuty como un sistema de detección de intrusiones (IDS) basado en logs. No mira si tu bucket S3 es público; lo que mira es si alguien desde una IP sospechosa está intentando acceder a él o si tus instancias EC2 están minando criptomonedas.

Utiliza Machine Learning y feeds de inteligencia de amenazas para analizar:

VPC Flow Logs (tráfico de red).
CloudTrail Events (acciones en la API).
DNS Logs (consultas a dominios maliciosos).

⚠️

⚠️ Importante
GuardDuty es reactivo: te avisa cuando algo malo ya está pasando o está por pasar.

Security Hub: El auditor y panel de control

Security Hub es un servicio de CSPM (Cloud Security Posture Management). Su trabajo principal es medir tu postura de seguridad frente a estándares como el AWS Foundational Security Best Practices o CIS Foundations Benchmark.

Te dirá cosas como: "Tienes el usuario root sin MFA" o "Tus bases de datos no están cifradas". Pero lo más potente de Security Hub no es solo su auditoría, sino su capacidad de ser el agregador central.

La diferencia clave
      Característica
      Amazon GuardDuty
      AWS Security Hub




      **Tipo**
      Detección de Amenazas (Threat Detection)
      Gestión de Postura (Compliance)


      **Foco**
      Comportamientos maliciosos actuales.
      Configuraciones erróneas y mejores prácticas.


      **Acción**
      Analiza logs en tiempo real.
      Realiza escaneos periódicos de recursos.
✅

💡 El Combo Perfecto
La mejor configuración es habilitar ambos y configurar Security Hub como el punto único de visibilidad. Security Hub puede importar automáticamente todos los "Findings" de GuardDuty.

Cómo activarlos juntos vía CLI

Si manejas varias regiones, habilitarlos manualmente es una tortura. Aquí te dejo cómo empezar con GuardDuty:

# Habilitar GuardDuty en la región actual
> aws guardduty create-detector --enable

Y para Security Hub:

# Habilitar Security Hub
> aws securityhub enable-security-hub

Conclusión

No elijas uno. GuardDuty detecta al atacante que está dentro; Security Hub cierra las puertas que dejaste abiertas para que no entre. Si solo usas uno, tienes un punto ciego gigante en tu arquitectura cloud.
Compartir

  🐦 Twitter/X
  💼 LinkedIn
¿Te fue útil?

Mando contenido así cuando tengo algo que vale la pena.
    Suscribirse





    ← Anterior
    Cómo iniciar en AWS desde cero


    Siguiente →
    Mapa de Ciberseguridad en AWS








byron.lainez
© 2026 · Guatemala 🇬🇹

Cómo iniciar en AWS: la guía honesta para empezar sin perderte

Byron Antonio Lainez Sasvin — Sat, 11 Apr 2026 18:34:59 +0000

Cuando yo empecé con AWS, lo primero que hice fue abrirla consola y quedarme viendo 200 servicios sin saber por dónde empezar. Si te pasó lo mismo, este post es para ti. No voy a explicarte qué es "la nube" — eso ya lo sabes. Voy directo a lo práctico: qué hacer primero, qué no tocar todavía, y cómo no llevarte una sorpresa en la factura.

Primero: la analogía que lo cambia todo

AWS es como un supermercado enorme donde puedes comprar ingredientes para cocinar lo que quieras. Antes de AWS, tenías que construir tu propia cocina desde cero — comprar el terreno, instalar la electricidad, comprar los electrodomésticos. Ahora entras al supermercado, tomas lo que necesitas y pagas solo por eso.

💡

💡 La clave
AWS tiene más de 200 servicios. No necesitas aprender todos. Necesitas aprender los 5-6 que forman la base — el resto los aprendes cuando los necesitas.

Paso 1: Crear tu cuenta y entender el Free Tier

Ve a aws.amazon.com y crea una cuenta. Necesitas un correo, una tarjeta de crédito/débito (para verificación) y un número de teléfono. AWS no te cobra si te mantienes dentro del Free Tier.

``` free tier

Free Tier — 12 meses desde que creas la cuenta

EC2: 750 horas/mes · t2.micro o t3.micro (Linux)
Solo una instancia. Dos instancias = el doble de horas = cobro.
S3: 5 GB de almacenamiento estándar
+ 20,000 GET requests/mes + 2,000 PUT requests/mes
RDS: 750 horas/mes · db.t2.micro o db.t3.micro (Single-AZ)
MySQL, PostgreSQL, MariaDB, Oracle (SE1), SQL Server (EX)

Always Free — no expiran, son permanentes

Lambda: 1,000,000 invocaciones/mes
+ 400,000 GB-segundos de cómputo/mes
DynamoDB: 25 GB de almacenamiento
+ 25 WCU (escrituras) + 25 RCU (lecturas) por mes
CloudWatch: 10 métricas personalizadas + 10 alarmas + 1M API requests/mes

Logs de CloudWatch: 5 GB de ingesta/mes → Free Tier 12 meses (no siempre)






⚠️ 

⚠️ El error más común con el Free Tier
      Crear recursos y olvidarlos. Una instancia EC2 corriendo 24/7 consume sus 750 horas en 31 días exactos. Si tienes **dos instancias**, consumes el doble y la segunda te la cobran. **Siempre apaga lo que no uses.**



## Paso 2: Lo primero que debes configurar (antes de cualquier otra cosa)




        01
        MFA en el root account
        El root account tiene acceso total a todo. Ponle autenticación de dos factores inmediatamente. Ve a IAM → Security credentials → Assign MFA.


        02
        No uses el root para trabajar
        Crea un usuario IAM con permisos de administrador para tu uso diario. El root solo se toca en emergencias. Esto es crítico.


        03
        Configura alertas de billing
        Ve a Billing → Budgets → Create budget. Pon una alerta si el gasto supera $5. Así nunca te sorprende una factura.


        04
        Activa CloudTrail
        Registra todo lo que pasa en tu cuenta. Si algo sale mal, CloudTrail te dice quién hizo qué y cuándo. Gratis el primer trail.




## Paso 3: Los 6 servicios core que necesitas aprender



De los 200+ servicios, estos 6 son la base de prácticamente todo lo que vas a construir. Aprende estos antes de cualquier otro:




        🔐

          IAM — Identity and Access Management FREE
          Controla quién puede hacer qué en tu cuenta. Usuarios, grupos, roles y políticas. Es el primer servicio que debes entender bien — un IAM mal configurado es la puerta de entrada de la mayoría de incidentes en la nube.



        💻

          EC2 — Elastic Compute Cloud
          Servidores virtuales en la nube. Lanzas una instancia, instalas lo que necesitas y listo. Es el servicio más flexible de AWS — y también el que más fácil se te puede ir la factura si no lo apagas.



        🪣

          S3 — Simple Storage Service
          Almacenamiento de archivos escalable. Puedes guardar desde imágenes hasta backups completos. También se usa para alojar sitios web estáticos. La "S" de S3 no es de simple — es de "te sorprenderás lo que puedes hacer con esto".



        🌐

          VPC — Virtual Private Cloud
          Tu red privada dentro de AWS. Defines subnets, rutas y reglas de firewall (Security Groups). Todo lo que creas en AWS vive dentro de una VPC. Entender VPC es entender cómo se comunican tus servicios.



        ⚡

          Lambda — Serverless Functions 1M FREE/mes
          Ejecuta código sin gestionar servidores. Subes una función (Python, Node, etc.), defines cuándo se ejecuta y pagas por invocación. Perfecto para automatizaciones, webhooks y procesamiento de eventos.



        🗄️

          RDS — Relational Database Service
          Bases de datos relacionales administradas: MySQL, PostgreSQL, MariaDB. AWS gestiona los backups, parches y alta disponibilidad. Tú solo te preocupas por tu base de datos, no por el servidor.





## Paso 4: Tu primer proyecto práctico



La mejor forma de aprender AWS es construyendo algo. Este proyecto te enseña los 4 servicios más importantes en un solo ejercicio:

# Proyecto: Sitio web estático + backend serverless
> 
> 1. S3  → Crea un bucket y sube un HTML simple
>          (activa "Static website hosting")
> 
> 2. IAM → Crea un rol con permisos solo para ese bucket
>          (practica el principio de mínimo privilegio)
> 
> 3. Lambda → Crea una función que responda a peticiones HTTP
>             (Python o Node.js, usa el runtime que conozcas)
> 
> 4. API Gateway → Conecta Lambda a una URL pública
>                  (crea un endpoint /api/saludo)
> 
> Resultado: un sitio web con un backend real, en la nube,
>            por menos de $0.01 al mes dentro del free tier.

✅

✅ Por qué este proyecto
Toca S3, IAM, Lambda y API Gateway — los 4 servicios que aparecen en el 80% de las arquitecturas serverless. Si puedes construir esto desde cero, ya tienes base para el examen CCP y para conversaciones reales de trabajo.

Paso 5: El modelo de precios (para no asustarte)

AWS cobra por uso. No hay mensualidad fija. Esto es bueno (pagas exactamente lo que usas) y malo (si dejas algo corriendo sin querer, te llega la factura). Los tres modelos principales:

On-Demand    → Pagas por hora/segundo. Sin compromiso.
>                Ideal para: aprender, experimentar, cargas variables.
> 
> Reserved     → Compromiso de 1 o 3 años. Hasta 72% de descuento.
>                Ideal para: workloads estables de producción.
> 
> Spot         → Capacidad sobrante de AWS a precio reducido (hasta 90%).
>                Ideal para: procesamiento batch, CI/CD, no crítico.
>                Riesgo: AWS puede terminar la instancia con 2 min de aviso.

Para aprender: usa siempre On-Demand dentro del Free Tier. Para producción: empieza On-Demand y cuando tengas estabilidad, evalúa Reserved.

El camino de certificaciones en AWS

Las certificaciones de AWS son de las más valoradas en LATAM para conseguir trabajo en cloud. Este es el camino que yo recomendaría si empezaras hoy:
    Foundational
    ☁️ AWS Cloud Practitioner (CCP)
    2-3 meses


    Associate
    ⚙️ AWS Solutions Architect Associate (SAA-C03)
    3-4 meses


    Associate
    🛡️ AWS Security Specialty (SCS-C02) *— recomendado si vas a seguridad*
    4-6 meses


    Specialty
    🤖 AWS AI Practitioner (AIF-C01) *— relevante hoy*
    2-3 meses
💡

💡 Mi recomendación personal
Empieza con CCP. No porque sea fácil, sino porque te da el mapa completo de AWS antes de especializarte. Sin ese mapa, las certificaciones de Associate se vuelven memorización pura. Con él, tienen sentido.

Recursos gratuitos para aprender

No necesitas pagar un curso de $200 para empezar. Estos recursos son gratuitos y buenos:

AWS Skill Builder        → skillbuilder.aws
>                            Cursos oficiales gratuitos de AWS
> 
> AWS CCP Flashcards       → awsccp.byronlainez.click
>                            200 tarjetas interactivas en español
> 
> AWS AI Practitioner      → awsaipractitioner.byronlainez.click
>                            Guía completa AIF-C01 en español
> 
> Documentación oficial    → docs.aws.amazon.com
>                            Siempre la referencia más actualizada
> 
> AWS Free Tier            → aws.amazon.com/free
>                            Experimenta sin gastar

Únete a la comunidad local

Aprender solo es posible, pero aprender en comunidad es más rápido y menos frustrante. Si estás en Guatemala, el AWS User Group El Progreso es el único grupo AWS activo en el oriente del país. Nos reunimos, compartimos experiencias reales y aprendemos juntos.

✅

✅ La verdad sobre aprender AWS
No necesitas memorizar los 200+ servicios. Necesitas entender IAM, EC2, S3, VPC, Lambda y RDS, construir algo con ellos, y saber que el resto existe para cuando lo necesites. Empieza pequeño, rompe cosas en el Free Tier y pregunta en la comunidad. Así es como todos aprendemos.

Conclusión

AWS puede parecer abrumador al principio porque es grande. Pero la manera de no perderse es la misma que con cualquier cosa grande: empiezas por una esquina, aprendes bien esa parte, y vas expandiendo. La esquina correcta para empezar es: crea tu cuenta, protégela con MFA, activa las alertas de billing, aprende IAM y construye algo con S3 y Lambda.

El resto llega solo.
Compartir

  🐦 Twitter/X
  💼 LinkedIn
¿Te fue útil?

Mando contenido así cuando tengo algo que vale la pena.
    Suscribirse





    ← Anterior
    Responsabilidad compartida en AWS: si no la entiendes, no puedes proteger la nube


    Todos los posts →
    Ver el blog completo








byron.lainez
© 2026 · Guatemala 🇬🇹

¿Qué es y para qué sirve AWS Kiro?

Byron Antonio Lainez Sasvin — Fri, 10 Apr 2026 22:07:15 +0000

El desarrollo de software en la nube acaba de dar un salto gigante. Ya no estamos hablando solo de herramientas tipo Copilot que completan la siguiente línea de código, ahora hablamos de verdaderos compañeros de desarrollo que entienden el contexto de tu cuenta de AWS y te asisten de manera proactiva.

Hoy vamos a explorar AWS Kiro: qué es, cómo funciona y, más importante aún, para qué te sirve en el día a día.

¿Qué es AWS Kiro?

En pocas palabras, AWS Kiro es una herramienta de codificación impulsada por inteligencia artificial (agente de IA). Está desarrollado por Amazon y potenciado por los modelos base de Amazon Bedrock (como la familia Claude). Lo interesante es que viene en dos sabores:

Kiro IDE: Un editor basado en un fork de VS Code (Code OSS), que integra todas estas capacidades de IA directamente en tu entorno gráfico.
Kiro CLI: Una potente interfaz de línea de comandos diseñada para que la IA controle y automatice tareas de DevOps e infraestructura conversando directamente con tu terminal.

¿Para qué sirve? (Casos de Uso)

Kiro está pensado para acompañarte "de inicio a fin" en un proyecto, y esto lo hace a través de características bien definidas:

1. Spec-Driven Development (Desarrollo guiado por especificaciones)

¿Cansado de empezar a escribir código sin saber bien hacia dónde vas? AWS Kiro tiene un "Spec Mode" o modo de especificación. Tú le describes tu problema en lenguaje natural, y Kiro te redacta historias de usuario, esquemas de bases de datos, y flujos de datos antes de escribir una sola línea de código. Esto te obliga (para bien) a seguir buenas prácticas de ingeniería.

2. Workflow de Agente de IA

Le puedes pedir que lea la documentación de tu repo, que estructure los archivos necesarios, que genere el código, y posteriormente los tests unitarios. Todo de forma orquestada. Actúa más como un developer junior/mid al que le delegas una tarea que como un autocompletado ciego.

3. Operaciones de DevOps desde la Terminal

Con Kiro CLI, el ciclo de despliegue se acelera brutalmente. Puedes pedirle en la consola: "Haz un deploy a S3 de la carpeta dist de este proyecto" o "Analiza mis logs de CloudWatch y encuentra el error 500", y la IA traducirá eso a comandos de terminal y de AWS CLI.

✅

💡 Extensibilidad total
Kiro soporta MCP (Model Context Protocol), lo que significa que puedes conectar el agente con bases de conocimiento privadas, apis externas e incluso otras herramientas de red, abriendo infinitas posibilidades.

Conclusión

AWS Kiro es un adelanto al futuro donde la IA actúa de manera agéntica—es decir, tomando decisiones, explorando archivos, proponiendo arquitecturas y programando junto a ti. Si manejas infraestructura en AWS y desarrollas software, probar su IDE o su CLI puede ahorrarte no solo tiempo, sino un montón de frustración cuando tienes que lidiar con proyectos pesados.
Compartir

  🐦 Twitter/X
  💼 LinkedIn
¿Te fue útil?

Mando contenido así cuando tengo algo que vale la pena.
    Suscribirse





    ← Anterior
    Mapa de Ciberseguridad en AWS








byron.lainez
© 2026 · Guatemala 🇬🇹

¿Qué es AWS CloudWatch, Casos de Uso y Por Qué Deberías Aprenderlo Hoy?

Byron Antonio Lainez Sasvin — Thu, 09 Apr 2026 08:11:16 +0000

¿Qué es AWS CloudWatch, Casos de Uso y Por Qué Deberías Aprenderlo Hoy?

Logs, Métricas, Alarmas y por qué sin observabilidad estás operando la nube a ciegas.

Son las 3:00 a.m. de un martes. Tu teléfono empieza a sonar desesperadamente porque la página de inicio o tu API estrella está caída. Entras a AWS, abres la consola de tu servidor de producción o de tu base de datos, y te haces la gran pregunta: "¿Qué demonios falló?"

Si alguna vez te ha pasado esto, entiendes exactamente por qué aprender a manejar la observabilidad en la nube no es opcional. Y aquí es donde AWS CloudWatch se convierte en tu mejor amigo y el protagonista de esta guía.

¿Qué es AWS CloudWatch y para qué sirve realmente?

En términos abstractos, Amazon define a CloudWatch como un servicio integral de monitoreo y observabilidad estructurada. En español: es el sistema nervioso central de toda tu infraestructura en AWS.

CloudWatch recolecta datos operativos en tiempo real de tus recursos en la forma de logs (registros), métricas y eventos, dándote una visión microscópica y unificada de tus recursos en la nube, aplicaciones y servicios on-premise.

Se divide principalmente en tres pilares fundamentales que todo Search Engine Optimizer (SEO), DevOps o Desarrollador debería conocer:

Métricas (Metrics): Datos cuantitativos de rendimiento de tus sistemas (Ej. El consumo de CPU o latencia de red de un EC2).
Registros (Logs): Líneas de texto detalladas de lo que hacen tus componentes (Ej. Errores 500 en tu backend Node.js o Lambda Function).
Alarmas (Alarms): Respuestas automáticas ante comportamientos anómalos (Ej. "Mándame un SMS y ejecuta un Lambda automáticamente si mi web app no responde durante 5 minutos seguidos").

⚠️ CloudWatch no es CloudTrail
Es la confusión más recurrente en entrevistas técnicas de AWS. CloudWatch te dice "qué está pasando con el rendimiento y la salud de tu recurso". CloudTrail te dice "quién, cómo y desde dónde se tocó la configuración de dicho recurso a nivel de consola o API de AWS".

Por Qué Deberías Aprender AWS CloudWatch Hoy Mismo

Entender los fundamentos básicos de EC2 y S3 es el primer paso, pero el verdadero valor técnico de un ingeniero Cloud, SRE o Arquitecto radica en su capacidad para garantizar que las arquitecturas sean rentables y no colapsen en el mejor momento.

Aprender CloudWatch te permite evolucionar: pasas de ser alguien que despliega cosas por probar a alguien que opera y mantiene sistemas corporativos vivos. Adicional a esto, más del 85% de las certificaciones de AWS (desde Practitioner y SAA, hasta Security Specialty) incluyen preguntas mandatarias pesadas sobre configuración y monitoreo usando CloudWatch. Si aspiras a certificarte, debes dominarlo.

Casos de Uso Principales de CloudWatch en el Día a Día

No se necesita ser un Arquitecto de Soluciones nivel 3 para sacarle jugo. Estos son los escenarios más comunes y efectivos donde CloudWatch se aplica en la industria todos los días:

1. Configuración de Alarmas de Facturación (Billing Alarms)

Nadie quiere una deuda sorpresa de $5,000 USD al final del mes. El clásico "por favor, avísame si AWS me va a cobrar más de algo presupuestado". Configurar alertar de facturación atadas a presupuestos y SNS es la primera responsabilidad de todos al abrir una nueva cuenta de AWS.

💡 Nivel Pro: Hazlo con Infraestructura como Código (Terraform)
No lo hagas a mano en la consola. Acostúmbrate a codificar tu configuración. Aquí tienes un snippet rápido para desplegar tu primera alarma de facturación con Terraform:

resource "aws_cloudwatch_metric_alarm" "billing_alarm" {
  alarm_name          = "Alarma-Costos-Altos"
  comparison_operator = "GreaterThanOrEqualToThreshold"
  evaluation_periods  = "1"
  metric_name         = "EstimatedCharges"
  namespace           = "AWS/Billing"
  period              = "21600" # 6 horas
  statistic           = "Maximum"
  threshold           = "10"    # Avisar al llegar a 10 USD
  alarm_actions       = [aws_sns_topic.billing_alerts.arn]

  dimensions = {
    Currency = "USD"
  }
}

2. Proteger y Auditar el SEO Técnico (Uptime y 5xx)

Un caso de uso espectacular del que pocos desarrolladores backend hablan con el área de Marketing (y que aplica perfectamente si tu objetivo es construir infraestructuras ultra resilientes): proteger el tráfico y evitar penalizaciones limitando el downtime. Usando CloudWatch Synthetics (Canaries) puedes simular constantemente la navegación de los usuarios o crawlers dentro de tus URLs críticas desde múltiples partes del mundo.

Si Googlebot visita tu sitio y obtiene un error 5xx repetidamente, el impacto negativo en tus ránkings orgánicos (SEO) puede ser implacable. CloudWatch detecta e informa estas caídas instantáneamente para que la correción suceda antes de que el crawler indexe el error.

3. Análisis Forense Inmediato de Logs con "Logs Insights"

¿Tienes miles de líneas de error en formato JSON y buscas rápidamente ubicar el error de un respectivo user_id? Con CloudWatch Logs Insights, en lugar de conectarse por SSH al servidor a iterar "grep" con miedo, puedes hacer consultas en tiempo real por los miles de logs distribuidos, estructurados y guardados en fracciones de segundos, utilizando su propio sintaxis muy similar a SQL.

Ejemplo Rápido: Monitorear Errores con Logs Insights

# Busca rápidamente los errores lanzados en las últimas horas en tu backend
fields @timestamp, @message, @logStream, @log
| filter @message like /ERROR/ or @message like /Exception/
| sort @timestamp desc
| limit 20

✅ Resultado Real
Poner este tipo de análisis en práctica acorta el 'Mean Time to Resolution' (MTTR) de horas a un par de minutos, demostrando a tu equipo, jefatura o clientes la madurez Cloud y de Troubleshooting que posees.

Arquitectura de Observabilidad Moderna

Para visualizar cómo todo esto se conecta, este es el flujo típico de observabilidad en un entorno moderno:

Aplicación (EC2 / Lambda) ➔ Escribe logs en CloudWatch Logs.
Filtro de Métricas ➔ Escanea los logs buscando palabras como "ERROR" y crea una Métrica personalizada.
CloudWatch Alarms ➔ Detecta si la métrica sube a más de 5 errores en 5 minutos.
Amazon SNS ➔ Dispara una notificación que te llega directo a Slack o a un webhook.

Conclusión

No asumas de forma intuitiva que tu infraestructura está funcionando bien solo porque los usuarios o quejas aún no han aparecido en Twitter. Con el poder que te otorga AWS CloudWatch para logs y tracking avanzado, te abres puerta a cambiar tu visión de ser reactivo a un creador hiper proactivo.

¿Quieres destacar y dominar la nube de AWS u optimizar tu SEO técnico? Ensaya a colocar tus ojos en la operatividad con CloudWatch, antes de que sea la caída general del sistema a las 3 a.m. la que termine tocando la puerta.