O CloudWatch é os olhos e ouvidos da sua conta: coleta métricas (CPU, memória, requisições), guarda logs e dispara alarmes quando algo sai do normal. Se a AWS é a sua infraestrutura, o CloudWatch é o painel que mostra se ela está saudável.
Saber o que está acontecendo sem ficar olhando: receber um alerta quando a CPU passa de 80%, juntar os logs de uma aplicação num lugar só, ver um gráfico de erros ao longo do tempo. É o que separa "o site caiu e ninguém viu" de "fomos avisados antes".
Cada um deles roda de verdade no terminal do CLImb, com a mesma saída e as mesmas mensagens de erro que a AWS devolve.
aws logs create-log-groupaws logs create-log-group
aws logs create-log-group --log-group-name /climb/app
aws cloudwatch put-metric-alarmaws cloudwatch put-metric-alarm
aws cloudwatch put-metric-alarm --alarm-name <nome> --metric-name CPUUtilization --namespace AWS/EC2 --threshold 80 --comparison-operator GreaterThanThreshold
aws cloudwatch describe-alarmsaws cloudwatch describe-alarms
aws cloudwatch describe-alarms
aws cloudwatch list-metricsaws cloudwatch list-metrics
aws cloudwatch list-metrics
aws cloudwatch delete-alarmsaws cloudwatch delete-alarms
aws cloudwatch delete-alarms --alarm-names <nome> [<nome2> ...]
aws logs describe-log-groupsaws logs describe-log-groups
aws logs describe-log-groups
aws logs delete-log-groupaws logs delete-log-group
aws logs delete-log-group --log-group-name /climb/app
aws cloudwatch put-metric-dataaws cloudwatch put-metric-data
aws cloudwatch put-metric-data --namespace Loja/Pedidos \ --metric-name PedidosPorMinuto --value 42 [--unit Count] \ [--dimensions Name=Produto,Value=Camiseta]
aws cloudwatch get-metric-statisticsaws cloudwatch get-metric-statistics
aws cloudwatch get-metric-statistics --namespace Loja/Pedidos \ --metric-name PedidosPorMinuto \ --start-time 2026-07-29T00:00:00Z --end-time 2026-07-30T00:00:00Z \ --period 3600 --statistics Sum
aws cloudwatch put-dashboardaws cloudwatch put-dashboard
aws cloudwatch put-dashboard --dashboard-name loja-visao-geral \
--dashboard-body '{"widgets":[
{"type":"metric","properties":{
"metrics":[["Loja/Pedidos","PedidosPorMinuto"]],
"title":"Pedidos por minuto"}},
{"type":"text","properties":{"markdown":"## Plantao"}}
]}'
aws cloudwatch list-dashboardsaws cloudwatch list-dashboards
aws cloudwatch list-dashboards
aws cloudwatch get-dashboardaws cloudwatch get-dashboard
aws cloudwatch get-dashboard --dashboard-name loja-visao-geral
aws cloudwatch delete-dashboardsaws cloudwatch delete-dashboards
aws cloudwatch delete-dashboards --dashboard-names loja-visao-geral aws cloudwatch delete-dashboards --dashboard-names painel-a painel-b
aws logs filter-log-eventsaws logs filter-log-events
aws logs filter-log-events --log-group-name /climb/app \ [--filter-pattern ERROR]
aws logs start-queryaws logs start-query (CloudWatch Logs Insights)
aws logs start-query --log-group-name /climb/app \ --start-time 0 --end-time 9999999999 \ --query-string 'fields @timestamp, @message | filter level = "ERROR" | limit 20'
aws logs get-query-resultsaws logs get-query-results
aws logs get-query-results --query-id <id-do-start-query>
aws logs stop-queryaws logs stop-query
aws logs stop-query --query-id <id>
Cada atividade é um pedido de trabalho, do jeito que ele chega no dia a dia — você resolve digitando os comandos, não escolhendo alternativa.
No CloudWatch Logs, crie um grupo chamado /climb/app (onde os logs vão parar).
O nginx vai mandar logs pra um grupo. Crie o grupo /nginx/acessos.
Separe os erros da API num grupo próprio. Crie /api/erros.
Crie um alarme chamado cpu-alta na métrica CPUUtilization com limite (--threshold) 80.
Avise quando o disco passar de 85%. Crie o alarme disco-cheio (DiskSpaceUtilization, limite 85).
Se a latência passar de 1000ms, você quer saber. Crie o alarme latencia-api (Latency, limite 1000).
Liste os alarmes configurados.
Liste as métricas disponíveis.
Crie um alarme mem-alta na métrica MemoryUtilization com limite 90.
Crie o alarme temp-alarme e apague ele.
Crie o grupo /app/prod e liste os grupos de logs.
Crie um grupo de logs /app/lambda (onde a função vai escrever).
Crie o grupo /app/temp e apague ele.
A AWS mede CPU e memória sozinha, mas não tem como saber quantos pedidos a sua loja fez. Essa métrica só existe se a aplicação publicar. Publique a métrica PedidosPorMinuto no namespace Loja/Pedidos com o valor 42.
Liste as métricas do namespace Loja/Pedidos e confirme que a sua está lá, lado a lado com as da AWS.
Uma métrica com um ponto só não mostra tendência. Publique outro valor em PedidosPorMinuto — dessa vez 58, e marcando a unidade como Count.
Agora consulte a soma dos pedidos. O CloudWatch agrega por período: você diz o intervalo (--start-time e --end-time), o tamanho da janela em segundos (--period) e qual estatística quer (--statistics Sum).
O melhor da métrica personalizada: dá pra alarmar nela igual a qualquer métrica da AWS. Crie um alarme pedidos-caindo que dispara quando PedidosPorMinuto (namespace Loja/Pedidos) ficar abaixo de 10.
Alarme avisa quando quebra; painel é o que alguém olha de manhã pra ver se está tudo bem. Crie um painel loja-visao-geral com um widget de gráfico da métrica PedidosPorMinuto (namespace Loja/Pedidos). <small>(o corpo é um JSON com a lista widgets)</small>
Liste os painéis da conta. <small>(repare no tamanho de cada um — os 3 primeiros painéis são grátis, depois a AWS cobra por painel)</small>
Não existe "adicionar um widget": o put-dashboard substitui o painel inteiro. Reenvie o loja-visao-geral com dois widgets — o gráfico que já tinha e um novo do tipo text com um recado em markdown.
Busque o painel loja-visao-geral e repare como o corpo dele volta: é uma string com JSON dentro, não um objeto. É assim que se edita painel por script — lê, altera, manda de volta.
Apague o painel loja-visao-geral. <small>(o parâmetro é plural — aceita vários nomes de uma vez)</small>
Antes do jeito sofisticado, o jeito simples: filter-log-events procura um pedaço de texto no log. Busque as linhas que contêm ERROR no grupo /climb/app. <small>(o grupo é o que você criou na primeira atividade da trilha)</small>
Agora o Logs Insights, que tem linguagem de consulta. Inicie uma consulta no /climb/app pedindo os campos @timestamp e @message, com limit 10. <small>(--start-time e --end-time são obrigatórios; use 0 e 9999999999 pra pegar tudo)</small>
A consulta é assíncrona: o start-query só devolveu um queryId. Pegue o resultado com ele. <small>(copie o queryId que apareceu na resposta anterior)</small>
Num plantão você não quer ver tudo — quer o que quebrou. Rode uma consulta no /climb/app filtrando level = "ERROR".
A pergunta que o log solto não responde: quantas linhas de cada nível? Use stats count() by level — é o "GROUP BY" do Insights.
A consulta que ganha o plantão: a latência média por rota, da pior pra melhor. Combine stats avg(latencia) by rota com sort decrescente. <small>(descubra qual endpoint está segurando a loja)</small>
Inicie uma consulta no /climb/app e interrompa ela. <small>(no Insights você paga pelo volume escaneado — parar cedo economiza de verdade)</small>
Ler explica. Digitar fixa. No CLImb você roda os comandos de verdade num terminal AWS simulado — o estado persiste entre eles, como na nuvem real.
As 3 primeiras atividades desta trilha são abertas; o resto faz parte do plano Pro.
Começar — 3 atividades grátis