Observabilidade de agentes de IA: CloudWatch e CloudTrail no Amazon Bedrock AgentCore

Um agente de IA em produção é, na prática, um sistema distribuído com um componente extra de imprevisibilidade: o próprio modelo decide, em tempo de execução, quais ferramentas chamar e em que ordem. Isso torna a observabilidade ainda mais importante do que em uma API tradicional, porque o comportamento do sistema não é totalmente determinístico.

Sem visibilidade adequada, um agente com problema de performance ou custo pode passar semanas silenciosamente consumindo mais sessões, mais chamadas de ferramenta e mais orçamento do que deveria, até que alguém perceba a fatura ou reclame da lentidão.

O AgentCore expõe métricas nativas via CloudWatch e trilhas de auditoria via CloudTrail, o que permite montar uma camada de observabilidade sem depender de instrumentação manual dentro do código do agente.

Por que observabilidade é diferente em sistemas agênticos

Em uma API tradicional, cada requisição segue um caminho previsível. Em um agente, uma única tarefa pode disparar zero, uma ou várias chamadas de ferramenta, dependendo da decisão do modelo naquele momento. Isso muda o tipo de pergunta que a observabilidade precisa responder:

• Quantas sessões estão ativas agora, e isso está dentro da capacidade esperada?
• Uma tarefa específica está gerando chamadas de ferramenta em excesso, indicando um loop ou uma decisão de modelo ineficiente?
• Houve algum acesso negado por política de autorização que merece investigação?

Métricas nativas do AgentCore no CloudWatch

O AgentCore publica métricas diretamente no namespace AWS/Bedrock AgentCore da conta, sem necessidade de configuração adicional. Uma das mais relevantes é ActiveSessionCount, um indicador em tempo real de quantas sessões estão ativas, publicado uma vez por minuto.

Essa métrica pode ser filtrada pela dimensão Service, com valores como AgentCore.Runtime, AgentCore.CodeInterpreter ou AgentCore.Browser, o que permite separar o consumo por tipo de carga de trabalho em vez de olhar para um número agregado sem contexto.

Um exemplo de consulta via AWS CLI para consultar essa métrica:

bash

aws cloudwatch get metric statistics \
  --namespace "AWS/Bedrock AgentCore" \
  --metric name "ActiveSessionCount" \
  --dimensions Name=Service,Value=AgentCore.Runtime \
  --start time 2026 07 30T00:00:00Z \
  --end time 2026 07 30T23:59:59Z \
  --period 300 \
  --statistics Average Maximum

Criando alarmes de uso anômalo

O caso de uso mais direto para ActiveSessionCount é detectar picos inesperados de sessões, seja por um problema de loop no agente, seja por um aumento genuíno de demanda que precisa de atenção de capacidade.

Um alarme simples via Terraform:

hcl

resource "aws_cloudwatch_metric_alarm" "sessoes_ativas_alta" {
  alarm_name          = "agentcore-sessoes-ativas-acima-do-esperado"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 3
  metric_name         = "ActiveSessionCount"
  namespace           = "AWS/Bedrock-AgentCore"
  period              = 300
  statistic           = "Average"
  threshold           = 500
  dimensions = {
    Service = "AgentCore.Runtime"
  }
  alarm_actions = [aws_sns_topic.alertas_ia.arn]
}

Vale começar com um limite conservador, observar o comportamento normal do agente por uma ou duas semanas, e ajustar o valor a partir dos dados reais em vez de um número arbitrário.

Rastreando consumo de quota

Além de indicar problemas de comportamento, ActiveSessionCount também serve para acompanhar consumo de quota de sessões simultâneas. Times que rodam múltiplos agentes na mesma conta se beneficiam de um dashboard que separa esse consumo por serviço, para identificar rapidamente qual carga de trabalho está mais próxima do limite antes que isso vire um erro de capacidade em produção.

CloudTrail para auditoria e troubleshooting

Enquanto o CloudWatch responde “quanto” e “quando”, o CloudTrail responde “quem fez o quê”. Toda chamada de API relacionada ao AgentCore, incluindo criação e alteração de Gateway, de targets e de políticas de autorização, fica registrada no CloudTrail.

Isso é especialmente útil em dois cenários:

1. Investigação de incidente: quando uma ferramenta que funcionava parou de funcionar, o CloudTrail mostra se alguma configuração foi alterada recentemente, por quem e em que momento.
2. Auditoria de conformidade: em ambientes regulados, ter um histórico completo de mudanças de política de autorização é frequentemente um requisito, não um nice to have.

Montando um dashboard básico

Um ponto de partida razoável para um dashboard de observabilidade de agentes reúne:

• ActiveSessionCount por serviço, para visão de capacidade.
• Latência e taxa de erro por ferramenta, vindas das métricas do Gateway.
• Volume de chamadas de tradução e composição, para acompanhar tendência de custo.
• Um widget de eventos recentes do CloudTrail filtrado para o namespace do AgentCore, para correlacionar mudanças de configuração com variações de comportamento.

Conclusão

Tratar um agente de IA como uma caixa preta funciona até o primeiro incidente em produção. As métricas nativas do AgentCore no CloudWatch, combinadas com o histórico de auditoria do CloudTrail, dão a visibilidade mínima necessária para operar um sistema agêntico com a mesma disciplina que qualquer outro serviço crítico já recebe. O investimento de montar esse dashboard antes do primeiro pico de tráfego custa muito menos do que investigar um incidente sem dados históricos disponíveis.