Amazon CloudWatch: o que é, componentes e quando usar

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, Internet Monitor e integração direta com OpenTelemetry, além dos componentes clássicos de Metrics, Logs e Alarms.

Este guia atualiza a fotografia da ferramenta. Em seguida, mostra como ela funciona por dentro, quais componentes importam, quanto custa de verdade e quando faz sentido 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.

Vale destacar que 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.

A resolução padrão é de 60 segundos. Para cargas críticas, existe a opção de high-resolution metrics com granularidade de 1 segundo. Vale destacar que métricas de alta resolução custam mais e devem ser usadas com critério.

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. Adicionalmente, a AWS oferece dois Logs classes: Standard (para análise frequente) e Infrequent Access (até 50% mais barato para logs de compliance pouco lidos).

Vale ressaltar o Live Tail, que 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. Em suma, 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”. Por conseguinte, 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. Adicionalmente, monta um service map automático e calcula SLOs/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

O Internet Monitor mostra como problemas em rotas BGP ou em ISPs específicos afetam a aplicação para grupos de usuários por geografia. Já os Container Insights (EKS, ECS, Fargate), Lambda Insights e Database Insights entregam métricas detalhadas de runtime. Adicionalmente, 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 é uma das formas mais baratas de publicar custom metrics em workloads serverless.

Vale destacar que o agente unificado funciona em ambientes híbridos e multi-cloud. 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.

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. A AWS publica os valores atualizados na página oficial de preços, com variação por região.

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. 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 com workloads simultâneos no Azure (consulte Azure Monitor) e no GCP (veja Google Cloud Operations) sofrem com a falta de uma visão única. 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. Quando um trace começa em uma aplicação on-premises, passa pela AWS e termina em um SaaS externo, o CloudWatch enxerga apenas o trecho dentro da AWS. 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 síntese, a combinação típica funciona assim. O CloudWatch atua como camada de coleta nativa. Adicionalmente, 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.

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.

Adicionalmente, 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. Da mesma forma, custom metrics duplicadas poderiam ser unificadas via dimensões.

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. Adicionalmente, integra-se a OpenTelemetry e suporta workloads on-premises.

Para times AWS-puros e operações pequenas, o CloudWatch nativo entrega a maior parte do que se precisa. À 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.