Amazon CloudWatch: o que é, componentes e quando usar

Autor: Pedro Tebaldi PM do KeepGreen| Revisão técnica: Ednilson Correa SRE

Publicado jan/2026Atualizado set/2026

Equipes que trabalham com cloud computing na AWS encontram o Amazon CloudWatch logo no primeiro dia. Ele é o serviço nativo de monitoramento e observabilidade da AWS. Coleta métricas, logs, traces, alarmes, dashboards e até sinais de APM de mais de 70 serviços, sem agente adicional para começar.

No entanto, o produto evoluiu muito nos últimos três anos. A maioria dos guias em português ainda descreve a versão de 2019. Hoje o CloudWatch engloba Application Signals (APM nativo), RUM, Synthetics e Internet Monitor. Somado a isso, integra-se direto ao OpenTelemetry, ao lado dos componentes clássicos de Metrics, Logs e Alarms.

Este guia atualiza a fotografia da ferramenta. Ele mostra como o CloudWatch funciona por dentro, quais componentes importam e quanto custa de verdade. Por fim, trata de quando compensa combinar a observabilidade nativa com uma camada externa.

O que é o Amazon CloudWatch (e onde ele se encaixa em cloud computing)

O Amazon CloudWatch é o serviço nativo de monitoramento e observabilidade da AWS. Ele coleta métricas, logs e traces dos serviços AWS e das aplicações que rodam na nuvem. Funciona também em ambientes on-premises ou em outros provedores quando o agente unificado é instalado.

Em termos simples, o CloudWatch responde duas perguntas operacionais: o que está acontecendo agora na infraestrutura e nas aplicações. Em seguida, ele mostra o que aconteceu quando algo falhou. Por isso, é o ponto de partida de qualquer estratégia de monitoramento na AWS.

O CloudWatch não opera isolado. Ele se conecta a praticamente todo o catálogo da AWS, incluindo EC2, RDS, Lambda, ECS, EKS, S3, API Gateway, ELB, DynamoDB e Route 53. Cada serviço publica métricas automáticas no repositório do CloudWatch sem nenhuma configuração adicional.

Como o CloudWatch funciona por dentro

A arquitetura do CloudWatch é, no essencial, um repositório de métricas de série temporal. Ele se acopla a um pipeline de logs e a um motor de alarmes. Os serviços AWS empurram dados para esse repositório e o operador consulta, visualiza ou cria gatilhos sobre eles.

Cada métrica vive em um namespace (por exemplo, AWS/EC2 ou AWS/Lambda) e carrega dimensões que identificam o recurso específico. Em seguida, o operador escolhe estatísticas (Average, Sum, p95) e períodos para construir alarmes, dashboards ou queries.

Por padrão, a resolução é de 60 segundos. Para cargas críticas, existe a opção de high-resolution metrics com granularidade de 1 segundo. Métricas de alta resolução custam mais e pedem critério de uso.

No lado de logs, a estrutura é hierárquica. Cada serviço grava em um log group, que contém vários log streams. Cada stream guarda eventos individuais. Logs Insights é o motor de query SQL-like que cruza dados de múltiplos grupos em segundos, sem exportar para outra ferramenta.

Os componentes essenciais do CloudWatch

A coluna vertebral do CloudWatch continua composta por quatro pilares: Metrics, Logs, Alarms e Dashboards. Eles cobrem o que a maioria das equipes de TI precisa para começar a monitorar uma carga na AWS.

CloudWatch Metrics

O Metrics armazena dados de série temporal de todos os serviços AWS suportados. A maior parte das métricas chega ao repositório de forma automática (basic monitoring, gratuita, intervalos de 5 minutos). O detailed monitoring reduz o intervalo para 1 minuto e tem custo adicional por instância.

Aplicações próprias publicam custom metrics via API PutMetricData ou pelo CloudWatch Agent. Ainda assim, custom metrics são uma das categorias de cobrança que mais crescem. Isso acontece principalmente quando equipes adicionam dimensões cardinality-alta sem perceber.

CloudWatch Logs e Logs Insights

O Logs ingere eventos de serviços AWS, da aplicação ou de hosts on-premises. Cada log group recebe uma política de retenção (de 1 dia a “para sempre”). A retenção padrão é “Never expire”, o que costuma ser a primeira pegadinha de fatura.

Logs Insights consulta esses dados com sintaxe própria parecida com SQL. A AWS oferece duas Logs classes: Standard para análise frequente e Infrequent Access, que custa metade do preço por GB ingerido.

O Live Tail mostra eventos em tempo real e ajuda no troubleshooting interativo. Ele dispensa abrir terminal SSH em cada host.

CloudWatch Alarms e Dashboards

Alarmes monitoram uma métrica contra um limite e disparam ações: notificação SNS, auto scaling, Lambda, Systems Manager. Existem três variações principais. A primeira é o standard alarm (uma métrica). A segunda é o composite alarm (combinação booleana de vários alarmes para reduzir ruído). A terceira é o anomaly detection alarm (limite dinâmico via machine learning).

Dashboards consolidam widgets de métricas, logs, alarmes e mapas em uma única visão, com suporte a cross-account e cross-region. Assim, são o ponto de chegada visual da operação do dia a dia.

Componentes modernos: APM, RUM, Synthetics e Internet Monitor

A partir de 2022, a AWS expandiu o CloudWatch para cobrir camadas que antes exigiam ferramentas externas. Esses componentes são o motivo pelo qual o serviço deixou de ser apenas “métricas e alarmes”. A partir daí, o CloudWatch passou a competir com plataformas de observabilidade dedicadas.

Application Signals (APM nativo)

Lançado em 2024, o Application Signals é o APM nativo da AWS. Ele captura latência, taxa de erros e throughput por serviço. Além disso, monta um service map automático e calcula SLOs e SLIs sem instrumentação manual extensa. Por trás, usa o AWS Distro for OpenTelemetry para coletar os traces.

CloudWatch Synthetics

Synthetics roda canaries, scripts Node.js ou Python que simulam usuários reais em endpoints web ou APIs. Cada canary executa em uma frequência definida e gera métricas de disponibilidade e latência. Em caso de falha, captura screenshots automaticamente para análise posterior.

CloudWatch RUM

O RUM (Real User Monitoring) coleta dados de performance e erros do navegador do usuário final. Ele mede Core Web Vitals, JavaScript errors e tempos de carregamento de página. Dessa forma, ajuda equipes de frontend a correlacionar performance técnica com impacto em conversão.

Internet Monitor e Insights especializados

Problemas em rotas BGP ou em ISPs específicos aparecem no Internet Monitor, separados por grupo de usuários e por geografia. Já os Container Insights (EKS, ECS, Fargate), Lambda Insights e Database Insights entregam métricas detalhadas de runtime. Eles capturam perfis de memória e queries lentas, sem instrumentação manual.

CloudWatch Agent e integração com OpenTelemetry

O CloudWatch Agent unificado roda em Linux, Windows e em servidores on-premises. Ele coleta métricas de sistema (CPU, memória, disco, rede), logs e métricas customizadas. Em seguida, envia tudo para o CloudWatch Logs e Metrics. Substitui os agentes específicos antigos como o awslogs e o System Manager Agent.

Para times que adotam padrões abertos, a AWS distribui o AWS Distro for OpenTelemetry (ADOT). Trata-se de uma versão suportada do OTel Collector com exporters nativos para o CloudWatch. Em outras palavras, dá para instrumentar aplicações com OpenTelemetry e usar o CloudWatch como backend.

Outro recurso útil é o Embedded Metric Format (EMF). Ao gravar logs em um JSON específico, o CloudWatch Logs extrai métricas automaticamente sem custo extra de PutMetricData. Essa é, inclusive, uma das formas mais baratas de publicar custom metrics em workloads serverless.

O agente unificado funciona em ambientes híbridos e multi-cloud. Dessa forma, ele permite consolidar a coleta de hosts fora da AWS no mesmo repositório de métricas, conforme detalhado no guia oficial de instalação.

Quanto custa o Amazon CloudWatch (e por que a fatura cresce)

O CloudWatch usa modelo pay-per-use, sem compromisso mínimo, com nível gratuito para a maioria dos componentes. Mesmo assim, é uma das linhas que mais crescem na fatura AWS de empresas que escalam. A causa principal são logs e custom metrics não auditados.

A categoria que costuma surpreender é a de ingestão e armazenamento de logs. Cada GB ingerido no CloudWatch Logs Standard tem custo. A retenção padrão de “Never expire” faz a base crescer indefinidamente. Equipes maduras combinam Infrequent Access para compliance com filtros no agente, reduzindo o volume na origem.

Preço de tabela por componente

Todos os preços abaixo saem de uma API pública da AWS, que dispensa credencial, portanto dá para conferir cada linha sem abrir conta. Os valores são da versão de 31 de agosto de 2026, para a região us-east-1. O nível gratuito de cada linha vem da mesma fonte.

Para cenários de alta escala, vale incluir o CloudWatch dentro de uma prática estruturada de FinOps. A revisão mensal deve focar em três categorias críticas: logs, custom metrics e queries Insights. Além disso, a AWS publica os valores atualizados na página oficial de preços, com variação por região.

A armadilha da cardinalidade: uma métrica que vira 81

Das nove linhas acima, a de métrica customizada é a que mais engana, porque a cobrança não é por nome de métrica. A documentação do CloudWatch trata cada combinação única de dimensões como uma métrica separada, ou seja, um nome só pode virar centenas de séries cobradas.

Para medir o efeito, publicamos uma única métrica em três formatos, em 2 de setembro de 2026. O laboratório rodou sem conta na AWS, no LocalStack 4.9.2 com o AWS CLI 2.31.9. Contra uma conta real, o mesmo comando funciona trocando apenas o endpoint.

# 1. Uma métrica com uma dimensão de baixa cardinalidade
aws cloudwatch put-metric-data --namespace "Loja/Checkout" \
  --metric-name LatenciaMs --value 184 --unit Milliseconds \
  --dimensions Servico=checkout

# 2. A mesma métrica com o id da instância junto (40 instâncias)
aws cloudwatch put-metric-data --namespace "Loja/Checkout" \
  --metric-name LatenciaMs --value 184 --unit Milliseconds \
  --dimensions Servico=checkout,InstanceId=i-0a0000000001

# 3. A mesma métrica com o id do pedido junto (40 pedidos)
aws cloudwatch put-metric-data --namespace "Loja/Checkout" \
  --metric-name LatenciaMs --value 184 --unit Milliseconds \
  --dimensions Servico=checkout,PedidoId=PED-000001

# Quantas métricas cobradas passaram a existir no namespace?
aws cloudwatch list-metrics --namespace "Loja/Checkout" \
  --query 'length(Metrics)'

81

São 81 métricas cobradas saindo de um único --metric-name. Portanto, pelo preço de tabela, 81 vezes US$ 0,30 dá US$ 24,30 por mês. Troque PedidoId por um identificador realmente aberto, com 5.000 pedidos no mês. Como resultado, a mesma linha de código passa a custar US$ 1.500 mensais.

Dessa forma, a dimensão que ajudava no debug vira a maior linha da fatura. Por isso a revisão trimestral precisa olhar o número de séries, não o número de nomes de métrica.

CloudWatch vs. CloudTrail: monitoramento operacional vs. trilha de auditoria

A confusão entre os dois serviços é frequente, mas eles resolvem problemas diferentes. O CloudWatch responde “o sistema está saudável?”. Já o CloudTrail responde “quem fez o quê e quando?”. Ambos rodam em paralelo na maioria dos ambientes maduros.

O padrão recomendado pela AWS é direcionar os eventos do CloudTrail para um log group do CloudWatch Logs. A partir daí, criam-se alarmes operacionais sobre ações sensíveis (por exemplo, alteração de IAM ou de Security Group). Dessa forma, as duas camadas conversam.

Limites do CloudWatch e quando combinar com observabilidade externa

Para cargas 100% AWS e times pequenos, o CloudWatch nativo costuma ser suficiente. Ele cobre métricas, logs, alarmes, APM e RUM sem exigir contrato com terceiros. Além disso, a curva de aprendizado é menor por estar tudo no mesmo console.

Por outro lado, alguns cenários pressionam os limites da ferramenta nativa. Cargas multicloud sofrem com a falta de uma visão única. Os workloads rodam ao mesmo tempo no Azure (consulte Azure Monitor) e no GCP (veja Google Cloud Operations). Equipes com retenção longa de logs por exigência regulatória descobrem que a fatura escala rápido.

Outro ponto comum é a correlação cross-stack. Um trace pode começar em uma aplicação on-premises, passar pela AWS e terminar em um SaaS externo. Nesse caminho, o CloudWatch enxerga apenas o trecho dentro da AWS. Ou seja, em ambientes cloud híbridos, essa quebra é frequente.

Existe ainda a dimensão de compliance. Auditorias que exigem retenção de 5+ anos com WORM e controles de acesso granulares obrigam, em muitos casos, uma camada externa. O guia de segurança em cloud computing aprofunda esse tópico.

Em resumo, a combinação típica funciona assim. O CloudWatch atua como camada de coleta nativa. Por cima dela, uma plataforma de observabilidade externa agrega dados de outros provedores, retenção longa e correlação cross-stack quando o ambiente exige.

Boas práticas para evitar surpresas no fim do mês

Antes de tudo, defina retenção em cada log group já no momento da criação. A política padrão de “Never expire” é a maior fonte isolada de gasto inesperado em ambientes que crescem rápido.

Esse padrão aparece na resposta da API antes de qualquer log chegar ao grupo.

# Um log group recém-criado não traz política de retenção
aws logs create-log-group --log-group-name /aws/lambda/checkout
aws logs describe-log-groups --log-group-name-prefix /aws/lambda/checkout \
  --query 'logGroups[0].{grupo:logGroupName,retencaoEmDias:retentionInDays}'

{
    "grupo": "/aws/lambda/checkout",
    "retencaoEmDias": null
}

# null é o "Never Expire" da tela. Definindo 30 dias:
aws logs put-retention-policy --log-group-name /aws/lambda/checkout \
  --retention-in-days 30

# Auditoria: quantos grupos do ambiente estão sem retenção definida?
aws logs describe-log-groups \
  --query 'length(logGroups[?retentionInDays==null])'

2

Sem política definida, o campo retentionInDays volta nulo, isto é, o Never Expire da tela. Com 100 GB ingeridos por mês e retenção de 30 dias, o armazenamento estabiliza perto de US$ 3 mensais. Por outro lado, sem retenção nenhuma, o mesmo ambiente chega ao 12º mês perto de US$ 36. Depois disso, o valor continua subindo.

Ainda no bloco, a última consulta serve de auditoria: ela devolve quantos grupos do ambiente seguem sem política definida.

Em seguida, filtre logs na origem. O CloudWatch Agent suporta filtros regex que descartam linhas irrelevantes antes do envio. Como resultado, reduz tanto a ingestão quanto o custo de queries Insights subsequentes.

Use composite alarms para atacar a fadiga de alertas. Em vez de cinco alarmes que disparam ao mesmo tempo no mesmo incidente, um composite agrega a condição em uma única notificação acionável. Da mesma forma, anomaly detection elimina thresholds estáticos para métricas sazonais.

Por fim, revise dashboards e métricas customizadas a cada trimestre. Times costumam acumular dashboards de POCs que ninguém abre há meses. Custom metrics duplicadas quase sempre cabem em uma só, separadas por dimensão.

Conclusão

O Amazon CloudWatch deixou de ser apenas um repositório de métricas. Ele virou uma plataforma de observabilidade nativa que cobre métricas, logs, alarmes, dashboards, APM, monitoramento sintético e RUM. A integração com OpenTelemetry e o suporte a workloads on-premises completam o pacote.

Para times AWS-puros e operações pequenas, o CloudWatch nativo costuma fechar a conta sozinho. À medida que o ambiente cresce em complexidade (multicloud, retenção longa, correlação cross-stack), faz sentido combinar a camada nativa com uma plataforma externa de observabilidade.

Quer estruturar um monitoramento de ambientes AWS que vá além das métricas básicas e converse com o resto da operação de TI? Fale com um especialista da OpServices.