Monitoreo de Uso de Memoria en EC2: Por Qué Necesitas el Agente de CloudWatch

Uno de los primeros momentos de confusión al operar instancias EC2 en producción es abrir la consola de CloudWatch, buscar una métrica de RAM y no encontrar nada. La instancia lleva horas corriendo, el CPU se ve bien, pero no hay forma de saber si el proceso Java está consumiendo el 90% de la memoria disponible. Esto no es un bug ni una limitación oscura — es una consecuencia directa de cómo AWS separa sus responsabilidades operativas, y entenderlo cambia cómo instrumentas tus instancias desde el primer día.

TL;DR: Monitoreo de Memoria en EC2

Aspecto Comportamiento
Métricas por defecto de EC2 CPU, red, disco a nivel de hipervisor — sin RAM, sin uso de disco del SO
¿Por qué no hay RAM por defecto? AWS no tiene acceso al interior del SO invitado sin un agente instalado
Solución oficial Instalar y configurar el Agente de CloudWatch dentro de la instancia
Métricas que habilita el agente Uso de memoria, uso de disco, métricas de procesos, logs del SO
Namespace en CloudWatch CWAgent (separado de AWS/EC2)
Costo Las métricas personalizadas tienen costo adicional — verificar precios actuales en AWS

Cómo Funciona el Monitoreo de EC2: El Modelo de Responsabilidad Compartida

EC2 opera bajo el modelo de responsabilidad compartida de AWS. AWS gestiona el hipervisor y la infraestructura física subyacente. Tú gestionas el sistema operativo invitado y todo lo que corre dentro de él. Esta separación no es solo contractual — tiene implicaciones técnicas directas sobre qué métricas puede recolectar AWS sin tu intervención.

El hipervisor puede observar cuántos ciclos de CPU consume la VM, cuántos bytes pasan por la interfaz de red virtual, y cuántas operaciones de I/O llegan al volumen EBS. Todo esto ocurre en la capa de infraestructura, fuera del SO invitado. La memoria es diferente: el hipervisor asigna RAM a la instancia, pero el uso interno — cuánto está usando el kernel, cuánto está en caché, cuánto está libre — solo es visible desde dentro del SO.

Es como arrendar un apartamento: el propietario sabe cuánta electricidad consume el edificio completo, pero no puede saber si dejaste las luces encendidas en tu habitación sin entrar al apartamento.

El Agente de CloudWatch es el mecanismo que le da a AWS visibilidad dentro del SO invitado. Corre como un proceso dentro de tu instancia, recolecta métricas del sistema operativo usando las APIs estándar del SO (como /proc/meminfo en Linux), y las envía a CloudWatch como métricas personalizadas bajo el namespace CWAgent.

graph TD HV["Hipervisor AWS
CPUUtilization, NetworkIn, DiskReadOps"] CWEC2["CloudWatch Namespace: AWS/EC2"] BOUNDARY["── Límite del SO Invitado ──"] AGENT["Agente de CloudWatch
Proceso dentro del SO"] OS["Sistema Operativo Invitado
/proc/meminfo, df, swap"] CWCUSTOM["CloudWatch Namespace: CWAgent"] HV -->|"métricas de hipervisor"| CWEC2 HV --- BOUNDARY BOUNDARY --- OS OS -->|"mem, disk, swap"| AGENT AGENT -->|"PutMetricData"| CWCUSTOM
  1. Capa de hipervisor: AWS recolecta automáticamente CPU, red y operaciones de EBS. Estas aparecen en el namespace AWS/EC2.
  2. Límite del SO invitado: Sin un agente, AWS no puede cruzar esta frontera para leer métricas internas del SO.
  3. Agente de CloudWatch: Corre dentro del SO, lee métricas del sistema operativo y las publica en CloudWatch bajo el namespace CWAgent.
  4. CloudWatch: Almacena ambos conjuntos de métricas, pero en namespaces separados. Las alarmas y dashboards pueden combinarlos.

Métricas Disponibles por Defecto vs. con el Agente de CloudWatch

Antes de instalar nada, vale la pena entender exactamente qué obtienes en cada escenario para justificar el trabajo de instrumentación.

Métrica Sin agente (AWS/EC2) Con Agente (CWAgent)
Uso de CPU ✅ CPUUtilization ✅ Detalle por núcleo disponible
Tráfico de red ✅ NetworkIn / NetworkOut ✅ Detalle por interfaz
Operaciones de disco (EBS) ✅ DiskReadOps / DiskWriteOps ✅ Por dispositivo
Uso de memoria RAM ❌ No disponible ✅ mem_used_percent, mem_available
Uso de espacio en disco del SO ❌ No disponible ✅ disk_used_percent por punto de montaje
Métricas de swap ❌ No disponible ✅ swap_used_percent
Logs del SO y aplicaciones ❌ No disponible ✅ Recolección de logs configurable

Instalación y Configuración del Agente de CloudWatch en EC2

El proceso tiene tres partes: permisos IAM, instalación del agente, y configuración de qué métricas recolectar. Saltarse los permisos es el error más común — el agente arranca sin errores visibles pero no puede publicar métricas porque le faltan permisos para llamar a cloudwatch:PutMetricData.

Paso 1: Configurar el Rol IAM de la Instancia

La instancia necesita un rol IAM con permisos para publicar métricas y, si vas a recolectar logs, para escribir en CloudWatch Logs. AWS provee la política administrada CloudWatchAgentServerPolicy que cubre los permisos necesarios para el caso de uso estándar del agente.

Si prefieres una política mínima en lugar de usar la política administrada, los permisos esenciales para métricas son:

🔽 Ver política IAM mínima para el Agente de CloudWatch 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudwatch:PutMetricData",
        "ec2:DescribeVolumes",
        "ec2:DescribeTags",
        "logs:PutLogEvents",
        "logs:DescribeLogStreams",
        "logs:DescribeLogGroups",
        "logs:CreateLogStream",
        "logs:CreateLogGroup"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ssm:GetParameter"
      ],
      "Resource": "arn:aws:ssm:us-east-1:123456789012:parameter/AmazonCloudWatch-*"
    }
  ]
}

Adjunta el rol a la instancia. Si la instancia ya existe sin rol, puedes asociarlo sin detenerla:

aws ec2 associate-iam-instance-profile \
  --instance-id i-0abcdef1234567890 \
  --iam-instance-profile Name=CloudWatchAgentRole

Paso 2: Instalar el Agente de CloudWatch

La forma más directa en Amazon Linux 2 o Amazon Linux 2023 es usar el gestor de paquetes. En otras distribuciones, el método varía — consulta la documentación oficial para Ubuntu, RHEL o Windows.

Conéctate a la instancia y ejecuta:

# Amazon Linux 2 / Amazon Linux 2023
sudo yum install amazon-cloudwatch-agent -y

# Ubuntu / Debian
wget https://s3.amazonaws.com/amazoncloudwatch-agent/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb
sudo dpkg -i amazon-cloudwatch-agent.deb

Paso 3: Generar la Configuración del Agente

El agente usa un archivo JSON de configuración que define qué métricas recolectar y con qué frecuencia. Puedes generarlo interactivamente con el asistente incluido, o escribirlo directamente. Para la mayoría de los casos de producción, el asistente es más rápido para el primer setup:

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

El asistente pregunta si quieres recolectar métricas de memoria, disco, y logs. Al terminar, guarda la configuración en /opt/aws/amazon-cloudwatch-agent/bin/config.json. También puedes almacenar esta configuración en SSM Parameter Store para reutilizarla en múltiples instancias — es la práctica recomendada para flotas.

Si prefieres un archivo de configuración mínimo que capture memoria y disco sin usar el asistente:

🔽 Ver configuración mínima para memoria y disco 
{
  "metrics": {
    "namespace": "CWAgent",
    "metrics_collected": {
      "mem": {
        "measurement": [
          "mem_used_percent"
        ],
        "metrics_collection_interval": 60
      },
      "disk": {
        "measurement": [
          "disk_used_percent"
        ],
        "metrics_collection_interval": 60,
        "resources": [
          "/"
        ]
      }
    }
  }
}

Paso 4: Iniciar el Agente

Con la configuración lista, inicia el agente apuntando al archivo de configuración:

# Iniciar con configuración local
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config \
  -m ec2 \
  -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json \
  -s

# Verificar estado
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a status

Si el estado muestra running, el agente está activo. Las métricas tardan uno o dos minutos en aparecer en CloudWatch.

Paso 5: Verificar que las Métricas Lleguen a CloudWatch

Confirma que el agente está publicando antes de construir alarmas sobre estas métricas. Un agente que arranca correctamente pero no tiene permisos IAM falla silenciosamente en los logs de la aplicación — los errores aparecen en /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log, no en la consola de CloudWatch.

aws cloudwatch list-metrics \
  --namespace CWAgent \
  --dimensions Name=InstanceId,Value=i-0abcdef1234567890 \
  --region us-east-1

Si el comando devuelve métricas como mem_used_percent y disk_used_percent, la instrumentación está funcionando. Si devuelve una lista vacía después de 3-5 minutos, revisa los logs del agente y los permisos IAM.

graph TD INSTALL["Agente instalado"] START["Agente iniciado"] CHECK_STATUS["amazon-cloudwatch-agent-ctl -a status"] STATUS_OK{"Estado: running?"} CHECK_METRICS["list-metrics --namespace CWAgent"] METRICS_OK{"¿Aparecen métricas?"} CHECK_LOGS["Revisar amazon-cloudwatch-agent.log"] CHECK_IAM["Verificar rol IAM y política adjunta"] OK["✅ Instrumentación funcionando"] INSTALL --> START START --> CHECK_STATUS CHECK_STATUS --> STATUS_OK STATUS_OK -->|"No"| CHECK_LOGS STATUS_OK -->|"Sí"| CHECK_METRICS CHECK_METRICS --> METRICS_OK METRICS_OK -->|"Sí"| OK METRICS_OK -->|"No"| CHECK_LOGS CHECK_LOGS --> CHECK_IAM CHECK_IAM -->|"Corregir permisos y reiniciar agente"| CHECK_METRICS

Crear una Alarma de CloudWatch para Uso de Memoria

Con las métricas fluyendo, crear una alarma es directo. El namespace es CWAgent, no AWS/EC2 — este es el error más frecuente al configurar alarmas para métricas del agente por primera vez.

aws cloudwatch put-metric-alarm \
  --alarm-name "EC2-MemoryUsage-High" \
  --alarm-description "Uso de memoria superior al 85%" \
  --namespace CWAgent \
  --metric-name mem_used_percent \
  --dimensions Name=InstanceId,Value=i-0abcdef1234567890 \
  --statistic Average \
  --period 300 \
  --threshold 85 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:AlertaTecnica \
  --region us-east-1

Diagnóstico: El Agente Está Instalado Pero No Aparecen Métricas

Este es el patrón que más tiempo consume en producción. El agente está corriendo, el estado dice running, pero en CloudWatch no hay nada bajo CWAgent. La primera hipótesis suele ser un problema de configuración del agente — y casi siempre es incorrecta.

El problema real en la mayoría de los casos es que el rol IAM de la instancia no tiene el permiso cloudwatch:PutMetricData, o el rol no está adjunto a la instancia en absoluto. El agente recolecta las métricas correctamente desde el SO, intenta publicarlas, recibe un error de autorización de la API de CloudWatch, y lo registra en su propio log — pero no falla de forma visible.

Síntoma: el log del agente muestra líneas como error: RequestError: send request failed o AccessDenied. La consola de CloudWatch simplemente no muestra nada.

Diagnóstico en orden:

# 1. Verificar que el rol IAM está adjunto a la instancia
aws ec2 describe-instances \
  --instance-ids i-0abcdef1234567890 \
  --query 'Reservations[0].Instances[0].IamInstanceProfile' \
  --region us-east-1

# 2. Revisar los logs del agente dentro de la instancia
sudo tail -100 /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log

# 3. Verificar estado del agente
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a status

Si el rol está adjunto pero los logs muestran errores de autorización, verifica que la política CloudWatchAgentServerPolicy (o tu política personalizada) esté efectivamente adjunta al rol — no solo que el rol exista.

aws iam list-attached-role-policies \
  --role-name NombreDetuRol

Distribuir la Configuración a Múltiples Instancias con SSM

Configurar el agente manualmente en cada instancia no escala. El patrón de producción es almacenar la configuración en SSM Parameter Store y usar SSM Run Command o el documento AmazonCloudWatch-ManageAgent para distribuirla.

# Guardar la configuración en SSM Parameter Store
aws ssm put-parameter \
  --name "/AmazonCloudWatch-Config-Produccion" \
  --type "String" \
  --value file://config.json \
  --region us-east-1

# Iniciar el agente en una instancia usando la configuración de SSM
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config \
  -m ec2 \
  -c ssm:/AmazonCloudWatch-Config-Produccion \
  -s

Para flotas grandes, el documento SSM AmazonCloudWatch-ManageAgent permite ejecutar esta configuración en múltiples instancias simultáneamente usando SSM Run Command con filtros por etiquetas. Esto convierte la instrumentación en una operación de un solo comando para toda una flota.

Monitoreo de Memoria en EC2: Próximos Pasos

Una vez que el Agente de CloudWatch está publicando métricas de memoria y disco, el siguiente nivel es construir dashboards que correlacionen métricas del namespace AWS/EC2 con las del namespace CWAgent — ver CPU y RAM en el mismo gráfico revela patrones que ninguno de los dos muestra por separado.

Para automatizar la instalación del agente en nuevas instancias, considera incluirlo en tu AMI base o en el script de User Data. Instrumentar después del despliegue siempre llega tarde — cuando necesitas las métricas, ya pasó el incidente.

Consulta la documentación oficial del Agente de CloudWatch para la referencia completa de métricas disponibles, opciones de configuración avanzadas, y el esquema completo del archivo de configuración: Instalar el Agente de CloudWatch.

Glosario de Términos Clave

Término Definición
Agente de CloudWatch Proceso que corre dentro del SO invitado de EC2 para recolectar métricas del sistema operativo y logs, y publicarlos en CloudWatch.
Namespace CWAgent Espacio de nombres en CloudWatch donde el agente publica métricas personalizadas del SO. Separado del namespace AWS/EC2 que usa la monitorización por defecto.
Métrica personalizada Métrica publicada en CloudWatch por código de aplicación o por el agente, a diferencia de las métricas estándar que AWS publica automáticamente.
Modelo de responsabilidad compartida Marco de AWS que define qué gestiona AWS (infraestructura, hipervisor) y qué gestiona el cliente (SO invitado, aplicaciones, datos).
SSM Parameter Store Servicio de AWS para almacenar configuraciones y secretos. Usado habitualmente para distribuir la configuración del Agente de CloudWatch a flotas de instancias.

Comentarios

Publicar un comentario

Entradas populares de este blog

EC2 sin acceso a Internet en VPC personalizada: Internet Gateway y Route Table

Creaste una VPC personalizada, lanzaste una instancia EC2 en una subred pública y no puedes hacer ping a google.com — ni SSH funciona desde fuera. Este es uno de los problemas más frecuentes al trabajar con redes en AWS, y casi siempre se reduce a tres capas que deben estar alineadas: el Internet Gateway, la Route Table y la configuración de IP pública. Si falla cualquiera de las tres, el tráfico no sale. TL;DR — Acceso a Internet en EC2 dentro de VPC personalizada Capa Qué debe estar configurado Error típico Internet Gateway Creado y adjunto a la VPC IGW existe pero no está adjunto Route Table Ruta 0.0.0.0/0 apuntando al IGW Route Table sin ruta de salida Subred pública Asociada a la Route Table correcta Subred usa la Route Table principal sin IGW IP pública Auto-assign habilitado o EIP asignado Instancia sin IP pública Security Group Regla de salida 0.0.0.0/0 permitida Egress bloqueado por SG restr...
Leer más

Actualizar Contenido en CloudFront: Cómo Crear una Invalidación para Limpiar el Caché del Edge

Reemplazaste un archivo en S3, recargaste el navegador, y CloudFront sigue sirviendo la versión antigua. Es uno de esos momentos donde sabes exactamente qué pasó, pero necesitas la solución correcta ahora mismo — sin esperar que el TTL expire solo. Este artículo explica cómo funciona el caché de CloudFront y cómo crear una invalidación de CloudFront para forzar la purga inmediata del edge. TL;DR — Invalidación de CloudFront en 30 Segundos Situación Acción Archivo actualizado en S3, CloudFront sirve versión vieja Crear invalidación con la ruta del archivo Múltiples archivos actualizados Usar wildcard /* o listar rutas específicas Quieres evitar invalidaciones frecuentes Usar versionado de archivos en el nombre (cache busting) Herramienta Consola AWS, CLI ( aws cloudfront create-invalidation ), o SDK Cómo Funciona el Caché de CloudFront CloudFront opera como una red de puntos de presencia distribui...
Leer más

Aumentar el Timeout de Lambda: Configuración, Límites y Diagnóstico en Producción

Tu función Lambda se detiene a los 3 segundos, pero el proceso que ejecuta necesita 10. No es un bug en tu código — es el timeout por defecto de Lambda actuando exactamente como fue diseñado. El problema es que ese valor predeterminado de 3 segundos sorprende a casi todos la primera vez, especialmente cuando la función funciona perfectamente en local pero falla en producción con un error Task timed out after 3.00 seconds . TL;DR — Aumentar el Timeout de Lambda Aspecto Detalle Timeout por defecto 3 segundos Timeout máximo 15 minutos (900 segundos) Dónde configurarlo Consola AWS, CLI, CloudFormation, SAM, Terraform Error observable Task timed out after X.XX seconds Coste asociado Mayor timeout = mayor ventana de facturación potencial Alternativa para tareas largas AWS Step Functions o procesamiento asíncrono Cómo Funciona el Timeout en AWS Lambda Lambda ejecuta tu función dentro de un entor...
Leer más