Monitoramento de Memória RAM no EC2: Por que o CloudWatch Agent é Obrigatório

Você abre o console do CloudWatch, navega até as métricas da sua instância EC2 e percebe que CPU, rede e disco de I/O estão lá — mas RAM não aparece em lugar nenhum. Não é um bug, não é permissão faltando: o CloudWatch simplesmente não coleta métricas de memória por padrão, e entender por que isso acontece evita horas de busca no lugar errado.

TL;DR — Monitoramento de Memória no EC2

PontoDetalhe
Métricas padrão do EC2Coletadas pelo hipervisor AWS — CPU, rede, disco de I/O de bloco. Sem acesso ao SO convidado.
Memória RAM e disco usadoVisíveis apenas de dentro do SO. Exigem o CloudWatch Agent instalado na instância.
CloudWatch AgentProcesso rodando dentro do SO que publica métricas customizadas no namespace CWAgent.
IAM necessárioA instância precisa de uma IAM Role com a policy CloudWatchAgentServerPolicy.
CustoMétricas customizadas têm custo separado das métricas padrão — verifique a tabela de preços atual da AWS.

Por que o CloudWatch Não Enxerga a RAM por Padrão

O CloudWatch coleta métricas do EC2 através da infraestrutura do hipervisor — a camada que a AWS controla abaixo da sua instância. Esse mecanismo consegue observar o que acontece ao redor da VM: quantos ciclos de CPU foram consumidos, quantos bytes trafegaram pela interface de rede, quantas operações de I/O ocorreram no volume EBS. O que ele não consegue ver é o estado interno do sistema operacional convidado.

Memória RAM é alocada e gerenciada pelo kernel do SO. O hipervisor sabe quanto de memória física foi atribuído à instância, mas não sabe quanto está em uso pelo SO, por aplicações, ou quanto está em cache. Essa distinção é fundamental: uma instância com 8 GB de RAM alocada pode estar com 7,8 GB em uso ou com 2 GB — o hipervisor reporta o mesmo número nos dois casos.

O mesmo raciocínio se aplica ao uso de disco: o hipervisor vê operações de leitura e escrita no bloco, mas não sabe quantos gigabytes estão ocupados dentro do sistema de arquivos. Isso é informação do SO.

É como monitorar um servidor físico olhando apenas para o painel de energia do data center. Você vê consumo elétrico, temperatura e tráfego de rede no switch — mas para saber quanto de RAM o processo Java está consumindo, você precisa de acesso ao sistema operacional.
graph TD HV["Hipervisor AWS
camada de virtualização"] CW["CloudWatch
namespace AWS/EC2"] EC2["Instância EC2
SO Convidado"] AGT["CloudWatch Agent
processo no SO"] CWCUST["CloudWatch
namespace CWAgent"] MEM["Métricas do SO
RAM, Disco, Swap"] HV -->|"CPU, Rede, I/O de bloco
(automático)"| CW EC2 -->|"contém"| AGT EC2 -->|"expõe internamente"| MEM MEM -->|"lidas pelo"| AGT AGT -->|"publica via API
(requer IAM Role)"| CWCUST style HV fill:#FF9900,color:#000 style CW fill:#232F3E,color:#fff style EC2 fill:#1A73E8,color:#fff style AGT fill:#34A853,color:#fff style CWCUST fill:#232F3E,color:#fff style MEM fill:#EA4335,color:#fff
  1. Hipervisor AWS: coleta métricas da camada de virtualização e publica automaticamente no CloudWatch — sem nenhuma configuração da sua parte.
  2. SO Convidado: memória, swap e uso de sistema de arquivos existem apenas dentro da instância. Nenhum agente externo consegue ler esses valores.
  3. CloudWatch Agent: processo rodando dentro do SO que lê as métricas do kernel e as publica no CloudWatch via API, usando as credenciais da IAM Role anexada à instância.
  4. Namespace CWAgent: as métricas publicadas pelo agente ficam separadas das métricas padrão do EC2, no namespace CWAgent.

Instalando e Configurando o CloudWatch Agent para Monitoramento de Memória

O processo tem três partes: IAM Role com as permissões corretas, instalação do agente e configuração das métricas desejadas. Pular qualquer uma dessas etapas resulta em métricas não aparecendo no console — sem mensagem de erro óbvia.

Passo 1 — IAM Role na Instância

O agente precisa publicar métricas e, opcionalmente, buscar sua configuração no SSM Parameter Store. A policy gerenciada CloudWatchAgentServerPolicy cobre ambos os casos. Anexe-a a uma IAM Role e associe essa role à instância EC2.

Se a instância já existe sem uma role, você pode associar uma role existente ou criar uma nova diretamente pelo console ou CLI — sem precisar recriar a instância.

# Criar a role (se ainda não existir)
aws iam create-role \
  --role-name EC2CloudWatchAgentRole \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"Service": "ec2.amazonaws.com"},
      "Action": "sts:AssumeRole"
    }]
  }'

# Anexar a policy gerenciada
aws iam attach-role-policy \
  --role-name EC2CloudWatchAgentRole \
  --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy

# Criar instance profile e associar a role
aws iam create-instance-profile \
  --instance-profile-name EC2CloudWatchAgentProfile

aws iam add-role-to-instance-profile \
  --instance-profile-name EC2CloudWatchAgentProfile \
  --role-name EC2CloudWatchAgentRole

# Associar o instance profile à instância EC2
aws ec2 associate-iam-instance-profile \
  --instance-id i-1234567890abcdef0 \
  --iam-instance-profile Name=EC2CloudWatchAgentProfile

Passo 2 — Instalação do Agente

O CloudWatch Agent está disponível via SSM Run Command (sem precisar de acesso SSH) ou instalação manual. O método via SSM é preferível em ambientes com muitas instâncias.

Via SSM Run Command (Amazon Linux 2 / Amazon Linux 2023):

aws ssm send-command \
  --instance-ids i-1234567890abcdef0 \
  --document-name AWS-ConfigureAWSPackage \
  --parameters '{"action":["Install"],"name":["AmazonCloudWatchAgent"]}' \
  --region us-east-1

Instalação manual via SSH (Amazon Linux 2):

sudo yum install -y amazon-cloudwatch-agent

Instalação manual via SSH (Ubuntu/Debian):

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

Passo 3 — Configuração das Métricas

O agente usa um arquivo JSON de configuração. O assistente interativo amazon-cloudwatch-agent-config-wizard é a forma mais segura de gerar esse arquivo sem erros de sintaxe. Para ambientes automatizados, armazene a configuração no SSM Parameter Store e referencie-a na inicialização do agente.

Configuração mínima para coletar memória e uso de disco — salve como /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json:

🔽 Clique para expandir — configuração do CloudWatch Agent 
{
  "metrics": {
    "namespace": "CWAgent",
    "metrics_collected": {
      "mem": {
        "measurement": [
          "mem_used_percent",
          "mem_available",
          "mem_used",
          "mem_total"
        ],
        "metrics_collection_interval": 60
      },
      "disk": {
        "measurement": [
          "used_percent",
          "used",
          "free"
        ],
        "metrics_collection_interval": 60,
        "resources": [
          "/"
        ]
      }
    },
    "append_dimensions": {
      "InstanceId": "${aws:InstanceId}",
      "InstanceType": "${aws:InstanceType}",
      "AutoScalingGroupName": "${aws:AutoScalingGroupName}"
    }
  }
}

Após salvar a configuração, inicie o agente:

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

Verifique o status do agente:

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -m ec2 \
  -a status

Passo 4 — Verificar as Métricas no CloudWatch

Após o primeiro intervalo de coleta (padrão 60 segundos), as métricas aparecem no namespace CWAgent. Confirme via CLI antes de configurar alarmes:

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

Para consultar o valor atual de uso de memória:

aws cloudwatch get-metric-statistics \
  --namespace CWAgent \
  --metric-name mem_used_percent \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T01:00:00Z \
  --period 300 \
  --statistics Average \
  --region us-east-1

Criando um Alarme de Memória no CloudWatch

Com as métricas publicadas, configurar um alarme é direto. O ponto de atenção aqui é que alarmes no namespace CWAgent exigem que as dimensões correspondam exatamente às que o agente está publicando — incluindo InstanceId e qualquer outra dimensão configurada no append_dimensions.

aws cloudwatch put-metric-alarm \
  --alarm-name EC2-MemoryHigh-i-1234567890abcdef0 \
  --alarm-description 'Uso de memoria acima de 85%' \
  --namespace CWAgent \
  --metric-name mem_used_percent \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --statistic Average \
  --period 300 \
  --evaluation-periods 2 \
  --threshold 85 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:AlertaInfra \
  --region us-east-1
graph LR AGT["CloudWatch Agent
coleta a cada 60s"] NS["Namespace CWAgent
mem_used_percent"] ALM["Alarme CloudWatch
threshold 85%"] SNS["Tópico SNS
AlertaInfra"] NOTIF["Notificação
e-mail / Lambda"] AGT -->|"PutMetricData"| NS NS -->|"avalia 2 períodos
de 5 minutos"| ALM ALM -->|"estado ALARM"| SNS SNS --> NOTIF style AGT fill:#34A853,color:#fff style NS fill:#232F3E,color:#fff style ALM fill:#FF9900,color:#000 style SNS fill:#1A73E8,color:#fff style NOTIF fill:#EA4335,color:#fff
  1. O CloudWatch Agent coleta mem_used_percent a cada 60 segundos e publica no namespace CWAgent.
  2. O alarme avalia a média dos últimos 2 períodos de 5 minutos (10 minutos de janela).
  3. Se o threshold de 85% for atingido em ambos os períodos, o alarme transita para ALARM.
  4. A ação de alarme publica uma mensagem no tópico SNS configurado, que pode disparar e-mail, SMS ou uma função Lambda.

Diagnóstico: Métricas Não Aparecem no CloudWatch

Esse é o cenário clássico: você instalou o agente, iniciou o serviço, esperou alguns minutos — e nada aparece no namespace CWAgent. O erro mais comum aqui é assumir que o problema é no agente, quando na verdade é na IAM Role.

Sintoma: list-metrics retorna vazio para o namespace CWAgent mesmo com o agente rodando.
Diagnóstico inicial: verificar os logs do agente — parece óbvio, mas a maioria vai direto para reinstalar o agente.
Causa real: a IAM Role não estava associada à instância, ou a policy CloudWatchAgentServerPolicy não foi anexada à role.
Fix: verificar a role associada à instância e as permissões antes de qualquer outra ação.

Verifique a role associada à instância — se esse comando retornar vazio, o agente não tem como se autenticar na API do CloudWatch:

aws ec2 describe-instances \
  --instance-ids i-1234567890abcdef0 \
  --query 'Reservations[0].Instances[0].IamInstanceProfile' \
  --region us-east-1

Verifique os logs do agente diretamente na instância para identificar erros de autenticação ou configuração:

sudo tail -100 /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log

Verifique o status do processo do agente:

sudo systemctl status amazon-cloudwatch-agent

Se o agente estiver rodando mas os logs mostrarem erros de permissão (AccessDenied), o problema é exclusivamente na IAM Role — reinstalar o agente não vai resolver nada.

Escalando para Múltiplas Instâncias com SSM e Auto Scaling

Gerenciar a configuração do agente manualmente em cada instância não escala. O padrão operacional correto é armazenar a configuração no SSM Parameter Store e usar o UserData ou um SSM Association para aplicar automaticamente em novas instâncias.

Armazene a configuração no SSM Parameter Store:

aws ssm put-parameter \
  --name /cloudwatch-agent/config/default \
  --type String \
  --value file://amazon-cloudwatch-agent.json \
  --region us-east-1

Inicie o agente referenciando o parâmetro do SSM (execute dentro da instância ou via SSM Run Command):

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config \
  -m ec2 \
  -c ssm:/cloudwatch-agent/config/default \
  -s

Com esse padrão, qualquer instância que inicializar com a IAM Role correta e executar esse comando no UserData vai automaticamente começar a publicar métricas de memória — sem intervenção manual.

Próximos Passos e Monitoramento de Memória no EC2

Com o CloudWatch Agent configurado, você tem visibilidade real do que está acontecendo dentro das suas instâncias EC2. Os próximos passos naturais são criar dashboards no CloudWatch consolidando métricas de CPU (namespace padrão do EC2) com memória e disco (namespace CWAgent), e configurar alarmes compostos para situações onde CPU e memória estão simultaneamente elevados.

Para ambientes com Auto Scaling, considere usar métricas de memória como gatilho de scaling policies — mas atenção: o CloudWatch Application Auto Scaling suporta métricas customizadas em políticas de target tracking. Verifique a documentação atual para confirmar o suporte ao seu caso de uso específico.

Glossário

TermoDefinição
CloudWatch AgentProcesso instalado dentro do SO da instância EC2 que coleta métricas do sistema operacional e as publica no CloudWatch via API.
Namespace CWAgentNamespace do CloudWatch onde o agente publica métricas customizadas, separado do namespace padrão AWS/EC2.
HipervisorCamada de virtualização gerenciada pela AWS que fornece as métricas padrão do EC2 sem acesso ao SO convidado.
Instance ProfileContêiner IAM que permite associar uma IAM Role a uma instância EC2, fornecendo credenciais temporárias ao SO.
SSM Parameter StoreServiço da AWS para armazenar configurações e segredos, usado aqui para centralizar a configuração do CloudWatch Agent.

Comentários

Postar um comentário

Postagens mais visitadas deste blog

Variáveis de Ambiente no Lambda: Configuração, Acesso e Criptografia com KMS

Você tem um endpoint de banco de dados que precisa chegar até a função Lambda — hardcodar isso no código é o caminho mais rápido para um vazamento de credencial em um repositório público. Variáveis de ambiente no Lambda resolvem esse problema, e quando combinadas com KMS, você adiciona uma camada de criptografia que vai além do padrão gerenciado pela AWS. TL;DR — Variáveis de Ambiente no Lambda Ponto Detalhe Onde configurar Console, CLI ( --environment ), IaC (CloudFormation/SAM/Terraform) Criptografia padrão AWS gerencia com chave própria (aws/lambda) — transparente, sem custo adicional de KMS Criptografia customizada Você fornece uma CMK do KMS; Lambda criptografa em repouso e você descriptografa em runtime Acesso no código process.env.NOME (Node.js), os.environ['NOME'] (Python) Limite de tamanho 4 KB total para todas as variáveis — verifique a documentação oficial para limites atuais ...
Leia mais

S3 Access Denied: Por que 'Bloquear Acesso Público' impede seu objeto mesmo após torná-lo público

Você fez upload de uma imagem no S3, marcou o objeto como público, copiou a URL e abriu no navegador — e recebeu um 403 Access Denied . A configuração de ACL do objeto está correta, mas o acesso público continua bloqueado. O culpado quase sempre é o Block Public Access no nível do bucket, uma camada de controle que opera acima das ACLs e políticas de objeto e que muita gente ignora até levar o primeiro 403 em produção. TL;DR — S3 Access Denied com objeto público Camada O que controla O que verificar Block Public Access (bucket) Bloqueia ACLs e políticas públicas no bucket inteiro aws s3api get-public-access-block --bucket NOME ACL do objeto Permissão pública no objeto individual aws s3api get-object-acl --bucket NOME --key CHAVE Bucket Policy Permissões baseadas em política no bucket aws s3api get-bucket-policy --bucket NOME Object Ownership Controla se ACLs são respeitadas ou ignoradas aws s3api get-buc...
Leia mais