|

Por qué CloudWatch no muestra memoria RAM en EC2

En pocas palabras: EC2 no muestra memoria en CloudWatch porque esa métrica no forma parte del monitoreo básico del namespace AWS/EC2, que solo incluye CPU y red. Para verla hay que instalar el CloudWatch Agent, que reporta mem_used_percent bajo el namespace CWAgent.

Si buscás memoria RAM EC2 CloudWatch en Google es porque te pasó lo mismo que le pasa a media internet de sysadmins: abrís el dashboard, esperás ver el uso de RAM de tu instancia y no hay nada. CloudWatch no muestra memoria por defecto porque esa métrica no forma parte del monitoreo básico. Hace falta instalar el CloudWatch Agent para que el dato mem_used_percent empiece a llegar.

El CloudWatch Agent es un software de Amazon Web Services que se instala dentro del sistema operativo de una instancia EC2 para recolectar métricas internas como memoria, disco y swap, datos que el hipervisor no puede ver desde afuera. Sin este agente, CloudWatch solo expone CPU, red y estado de la instancia bajo el namespace AWS/EC2, según la documentación oficial de AWS.

En este artículo:

En 30 segundos

  • CPU y red vienen por defecto en el namespace AWS/EC2; memoria, disco por partición y swap no.
  • La métrica se llama mem_used_percent y la reporta el CloudWatch Agent bajo el namespace CWAgent.
  • El agente es open source bajo licencia MIT y está alojado en GitHub, según AWS.
  • El flujo completo es EC2 → CloudWatch Agent → Alarma → Slack, y se puede armar con un módulo Terraform como terraform-aws-modules/notify-slack/aws.
  • Las métricas del agente se facturan como custom metrics, no como las básicas gratuitas de AWS/EC2.

¿Qué métricas trae EC2 por defecto en CloudWatch?

Por defecto, cada instancia EC2 envía a CloudWatch métricas de CPU (CPUUtilization) y de red (NetworkIn, NetworkOut), todas bajo el namespace AWS/EC2, sin instalar nada. Lo que no viene incluido es cualquier dato que dependa del sistema operativo invitado.

Memoria RAM, uso de disco por partición, swap o cantidad de procesos corriendo: nada de eso llega solo. Necesitás algo corriendo adentro de la instancia que lo mida y lo mande, y ese algo es el CloudWatch Agent. Relacionado: guía para desplegar Coolify en AWS.

¿Por qué EC2 no muestra memoria en CloudWatch?

memoria ram ec2 cloudwatch diagrama explicativo

El hipervisor de AWS ve la instancia desde afuera: mide CPU asignada y paquetes de red, pero no tiene acceso al sistema operativo invitado, que es donde vive el dato de memoria usada. Por eso la RAM no puede llegar a CloudWatch sin un agente instalado dentro del SO.

Ponele que tenés un servidor con 8 GB de RAM corriendo al 95% de uso. Desde afuera, AWS solo ve que la CPU está tranquila y que la red circula normal, hasta que la aplicación se cuelga por falta de memoria y el dashboard de CloudWatch no te avisó nada, porque nunca tuvo ese dato. Esa es la trampa: pensás que estás “monitoreado” (entre comillas, porque en realidad solo tenés la mitad de la foto) y en realidad te falta la métrica que más importa cuando algo se rompe en producción.

¿Cómo instalar el CloudWatch Agent para monitorear la memoria RAM en EC2?

Instalás el CloudWatch Agent con un script de arranque que descarga el paquete, lo instala y le pasa una configuración JSON que le dice qué medir. Un flujo típico, descripto en una guía publicada el 24 de septiembre de 2026, es EC2 → CloudWatch Agent → métricas de memoria → alarma → Slack.

En la práctica, según describe kubeblogs, el orden de pasos es este:

  • Configuración en Parameter Store: guardás un JSON con el bloque mem_used_percent y un intervalo de recolección de 60 segundos.
  • Rol IAM con política custom: el rol necesita cloudwatch:PutMetricData, permisos de logs y ssm:GetParameter para leer la config.
  • User data en el lanzamiento: el script descarga el agente, lo instala con install.sh y aplica la configuración con el flag -c ssm:.
  • Verificación: con el comando amazon-cloudwatch-agent-ctl -m ec2 -a status confirmás que el agente está corriendo antes de dar por hecho que la métrica ya está viajando.

El agente es open source bajo licencia MIT y AWS lo mantiene en GitHub, según su documentación oficial. Ojo con esto: las métricas que manda se facturan como custom metrics, no entran en el monitoreo básico gratuito.

¿Cómo crear una alarma de memoria y enviarla a Slack?

Armás la alarma sobre el namespace CWAgent, apuntando a mem_used_percent, con un umbral (por ejemplo 85%) y una acción que dispara una notificación SNS conectada a Slack. Es el mismo patrón que ya usás para CPU, solo que apuntando a otro namespace. Para más detalles técnicos, mirá deploy automático de Docker Compose a EC2.

¿Y si el umbral se pasa de largo sin que nadie se entere? Exacto, ahí está el problema que esta alarma resuelve. El ejemplo de Terraform que circula en la guía de kubeblogs usa el módulo terraform-aws-modules/notify-slack/aws versión ~>5.0 para mandar el aviso, con memory_threshold en 85 y memory_period en 300 segundos como valores por defecto en el archivo terraform.tfvars.

¿Se puede desplegar el CloudWatch Agent con Terraform?

Sí, se puede gestionar tanto el agente como las alarmas con Terraform en vez de tocar cada instancia a mano. El patrón descripto usa una data source que filtra instancias por tag (por ejemplo tag:env = prod) y arma un for_each para crear una alarma de CPU y otra de memoria por cada instance_id encontrado.

El pipeline completo, tal como aparece en la fuente, corre en GitHub Actions: hace terraform init, fmt, plan (con un comentario automático en el pull request) y apply automático cuando el push llega a la rama dev. Usa la acción hashicorp/setup-terraform@v2 (la versión referenciada en la fuente original), configurada con terraform_version: 1.5.7 —la versión de Terraform usada en esa guía— para instalar el CLI, y aws-actions/configure-aws-credentials con un rol OIDC. Así nadie tiene que pegar credenciales a mano en cada corrida: el pipeline se encarga de revisar el diff automáticamente, esperar que alguien lo apruebe y recién ahí aplicar el cambio en producción. Más contexto en guía completa de scripts de automatización.

¿Qué pasa si no monitoreo la memoria de mis instancias EC2?

Sin métrica de memoria, la presión de RAM se acumula sin avisos hasta que la aplicación se cae o la instancia queda inestable. Es un problema silencioso.

La comunidad de AWS lo viene pisando hace rato: en repost.aws hay preguntas activas sobre cómo extender el agente a un Auto Scaling Group completo, y AWS actualizó hace 5 meses una guía específica sobre el error “Insufficient Data” en alarmas que monitorean disco y memoria. No es un caso aislado.

Qué significa esto para equipos en Latinoamérica

Para equipos chicos que manejan pocas instancias, el costo extra de custom metrics suele ser marginal. El tema cambia cuando tenés una flota grande con Auto Scaling: ahí conviene calcular antes cuántas métricas nuevas vas a generar, porque se suman rápido a la factura.

Errores comunes al monitorear memoria en EC2

  • Copiar código sin revisar el nombre de la métrica: en el propio snippet de Terraform que circula como referencia, el recurso de alarma de memoria tiene metric_name = “me” en vez de mem_used_percent. Si lo pegás tal cual, la alarma nunca va a disparar aunque la RAM esté al tope.
  • Olvidar el permiso ssm:GetParameter en el rol IAM: sin ese permiso puntual sobre el parámetro de configuración, el agente arranca pero no encuentra qué medir, y el user data termina sin errores visibles pero sin métricas.
  • No verificar el estado del agente después de instalarlo: el comando amazon-cloudwatch-agent-ctl -m ec2 -a status tarda dos segundos en correr y ahorra horas de “¿por qué no aparece la métrica?”.
  • Ignorar el error “Insufficient Data”: es un error frecuente en alarmas que monitorean disco y memoria en EC2, y AWS mantiene una guía específica para resolverlo.

Preguntas Frecuentes

¿Por qué CloudWatch no muestra la memoria de mi instancia EC2?

Porque el hipervisor de AWS no tiene acceso al sistema operativo invitado, que es donde se mide el uso de RAM. Solo puede reportar métricas externas como CPU y red bajo el namespace AWS/EC2. Para ver memoria hace falta instalar el CloudWatch Agent dentro de la instancia. En distribuir herramientas con GitHub Actions profundizamos sobre esto.

¿Cómo instalo el agente de CloudWatch para ver la memoria RAM?

Descargás el paquete con un script de user data, lo instalás con install.sh y le pasás una configuración JSON almacenada en Parameter Store que activa la medición mem_used_percent. El rol IAM de la instancia necesita permisos de cloudwatch:PutMetricData y ssm:GetParameter.

¿Qué métricas de memoria devuelve el CloudWatch Agent?

La métrica principal es mem_used_percent, el porcentaje de memoria usada, aparece bajo el namespace CWAgent con el intervalo de recolección que definas en la configuración del agente (por ejemplo cada 60 segundos).

¿Se puede configurar una alarma de memoria en EC2 con Slack?

Sí. Se crea una alarma de CloudWatch sobre mem_used_percent en el namespace CWAgent, con un umbral definido, y se conecta a un topic de SNS que dispara la notificación a un canal de Slack a través de un webhook.

¿Se puede desplegar el CloudWatch Agent con Terraform?

Sí, tanto el agente como las alarmas de memoria y CPU se pueden gestionar con Terraform, usando data sources que filtran instancias por tag y un for_each que crea una alarma por cada instancia encontrada, todo automatizable con un pipeline de CI/CD.

Conclusión

La memoria RAM de EC2 no aparece en CloudWatch por diseño, no por un bug: el hipervisor no puede verla y hace falta el CloudWatch Agent para que ese dato exista. Si administrás instancias en producción, instalar el agente, configurar mem_used_percent y armar una alarma conectada a Slack no es opcional, es el mínimo para no enterarte de un problema de memoria cuando la aplicación ya se cayó. Antes de copiar cualquier ejemplo de Terraform que encuentres dando vueltas, revisá que el metric_name esté bien escrito y que el rol IAM tenga los permisos justos. Es la diferencia entre una alarma que funciona y una que da una falsa sensación de seguridad.

Fuentes

Te puede interesar...