Visibilidade para o Codex no Amazon Bedrock com OpenTelemetry e Amazon CloudWatch

De experimento a adoção governada

Quando uma organização começa a escalar o uso de agentes de codificação como o Codex, a pergunta da liderança muda de natureza. Não basta mais saber se a ferramenta ajuda um desenvolvedor individualmente. O desafio passa a ser: como entender a adoção, controlar o consumo, manter a confiabilidade e expandir o acesso de forma responsável?

Para responder a essa pergunta, a AWS publicou um padrão de referência que combina as métricas OpenTelemetry (OTel) emitidas pelo Codex com o Amazon CloudWatch, usando autenticação via AWS IAM Identity Center. O resultado é uma visibilidade nativa AWS do uso do Codex, sem precisar adicionar nenhum proxy centralizado ao caminho de inferência dos modelos. Toda a implementação está documentada no repositório de orientação do Codex na AWS.

Como a arquitetura funciona

A lógica central do padrão é simples e elegante: o desenvolvedor continua usando o Codex localmente, sem nenhuma mudança perceptível no seu fluxo de trabalho. O que acontece nos bastidores é o seguinte:

• O Codex emite métricas OTel para um coletor que escuta apenas em 127.0.0.1 (ou seja, somente na máquina local).
• Esse coletor enriquece as métricas com atributos organizacionais — como user.id, user.email, departamento, time, centro de custo e organização.
• O coletor então agrupa as métricas em lotes e as envia ao endpoint regional do CloudWatch usando o protocolo OpenTelemetry Protocol (OTLP), autenticado com AWS Signature Version 4 (SigV4).

Esse design garante que o coletor nunca interfere no caminho de inferência do Amazon Bedrock. Não há criação de serviços centralizados como um Amazon Elastic Container Service (ECS), balanceador de carga, Virtual Private Cloud (VPC) ou endpoint público de ingestão. O que é implantado é apenas um dashboard no CloudWatch.

Transformando telemetria em decisões de negócio

O dashboard CodexOnBedrock incluído no padrão de referência exibe totais acumulados em 24 horas para usuários ativos, turnos de conversa, requisições de API e uso de tokens. Também oferece visões segmentadas por modelo, tipo de token, usuário, departamento, time, centro de custo, organização e origem da sessão.

Esses sinais ajudam líderes de tecnologia a distinguir adoção ampla de experimentação isolada. Por exemplo, um aumento de usuários ativos em vários times indica uma necessidade de capacitação diferente de um alto consumo concentrado em um grupo pequeno. A tabela abaixo, presente no artigo original, resume as perguntas executivas que o padrão ajuda a responder:

• A adoção do Codex está crescendo? → Usuários ativos, threads, turnos e requisições de API informam se é hora de expandir o piloto ou focar no onboarding.
• Onde o consumo está concentrado? → Tokens por usuário, modelo, departamento, time e centro de custo orientam showback, revisão de uso ou ajuste de capacitação.
• Os times estão usando capacidades agênticas? → Volume de chamadas de ferramentas e origem da sessão indicam onde guias de workflow ou investimentos em sistema podem ajudar.
• A experiência do desenvolvedor é confiável? → Status de API, duração de requisições e duração de turno ponta a ponta sinalizam se há algo a investigar em acesso ao modelo, rede ou comportamento do cliente.
• Qual foi o custo do serviço? → AWS Cost and Usage Reports (CUR) 2.0 com dados de principal IAM fornecem relatórios financeiros e alocação de custos em nível de faturamento.

Um ponto importante destacado no artigo: as métricas OTel do CloudWatch mostram volume de uso e comportamento operacional, mas não são um ledger de faturamento. Estimativas de preço de tabela podem divergir dos custos reais por conta de mudanças de preço, descontos, créditos e ajustes de cobrança. Para o gasto realizado, a recomendação é usar o CUR 2.0 ou os relatórios de gestão de custos do Amazon Bedrock.

Implementando o padrão de referência

O quickstart de acesso nativo AWS contém todos os comandos e templates necessários. A implementação se divide em cinco etapas:

1. Habilitar as capacidades OTel do CloudWatch

O primeiro passo é ativar o enriquecimento OTel e as tags de recurso para telemetria na região desejada:

aws cloudwatch start-otel-enrichment --region us-west-2
aws observabilityadmin start-telemetry-enrichment --region us-west-2
aws cloudwatch get-otel-enrichment --region us-west-2

A operação start-otel-enrichment habilita o enriquecimento e o acesso via Prometheus Query Language (PromQL) para métricas fornecidas pela AWS. A operação start-telemetry-enrichment habilita o enriquecimento com tags de recurso. A documentação OTel do CloudWatch descreve a ingestão nativa via OTLP e as consultas PromQL em detalhes. Antes de alterar qualquer configuração, é importante confirmar quais configurações de nível de conta já estão ativas.

2. Implantar o dashboard e compilar o coletor

Após clonar o repositório, o dashboard é implantado e o binário do coletor é obtido com:

deployment/scripts/deploy-otel-stack.sh --region us-west-2
deployment/scripts/build-local-collector.sh --all

O stack do AWS CloudFormation implanta o dashboard CodexOnBedrock. Como o coletor roda nas estações de trabalho dos desenvolvedores, essa etapa não cria infraestrutura centralizada de computação ou rede para o coletor.

3. Gerar a configuração por desenvolvedor

A configuração do coletor é gerada a partir do perfil AWS autenticado do desenvolvedor:

deployment/scripts/generate-sidecar-config.sh \
  --region us-west-2 \
  --profile codex-bedrock \
  --auto-lookup

Com o flag --auto-lookup, o script pode ler atributos organizacionais diretamente do identity store do IAM Identity Center. Valores explícitos via linha de comando podem sobrescrever os valores descobertos. Se um atributo opcional não estiver disponível, o bloco de configuração correspondente deve ser omitido — nunca envie strings de placeholder como dimensões, pois isso cria séries de baixo valor e compromete a qualidade dos relatórios.

4. Configurar o Codex e conceder acesso com privilégio mínimo

O exportador de métricas do Codex deve ser apontado para o coletor local. É necessário incluir o caminho completo /v1/metrics porque o Codex não o adiciona automaticamente:

[otel]
environment = "production"
log_user_prompt = false

[otel.metrics_exporter]
otlp-http = { endpoint = "http://127.0.0.1:4318/v1/metrics", protocol = "binary" }

O coletor encaminha as métricas para o endpoint regional de métricas OTLP do CloudWatch, como https://monitoring.us-west-2.amazonaws.com/v1/metrics. O SigV4 é o método de autenticação recomendado para credenciais AWS de curta duração. A identidade de publicação requer apenas a permissão cloudwatch:PutMetricData — nenhuma permissão de log-group ou ECS é necessária para esse caminho de métricas.

A configuração log_user_prompt = false deve ser mantida. Esse padrão foi projetado para medir sinais operacionais e de adoção, não para coletar código-fonte ou conteúdo de prompts.

5. Validar o fluxo completo

Inicie o coletor com a configuração gerada, execute uma tarefa no Codex e abra o dashboard CodexOnBedrock no console do CloudWatch. Também é possível usar o CloudWatch Query Studio ou o script check-otel-pipeline.sh do repositório para confirmar que a métrica codex.turn.token_usage está chegando.

As métricas do Codex são enviadas periodicamente e ao encerramento limpo do processo. O runbook de referência documenta um intervalo de 60 segundos e sugere OTEL_METRIC_EXPORT_INTERVAL=1000 como salvaguarda opcional para caminhos de erro que possam pular o flush de saída. Se nenhuma métrica aparecer, também é importante verificar se a configuração gerenciada não definiu [analytics] enabled = false, pois essa configuração desabilita o pipeline de métricas do Codex.

Operando com governança em mente

As mesmas dimensões que tornam o dashboard útil podem criar preocupações de privacidade e governança se expostas de forma muito ampla. Algumas recomendações do padrão de referência:

• Use visões agregadas por time, departamento e centro de custo para relatórios executivos.
• Restrinja dashboards por usuário a funções aprovadas de sistemas, operações, segurança ou finanças, alinhando o acesso com as políticas de monitoramento de funcionários e retenção de dados.
• Controle a cardinalidade das métricas à medida que escala: padronize nomes e valores de atributos, omita campos que não suportem uma decisão definida e evite adicionar nomes de projetos ou identificadores efêmeros sem um plano de retenção e consulta.

Do ponto de vista de custos, as métricas OTel do CloudWatch usam precificação por gigabyte ingerido, e as consultas PromQL são cobradas por amostras escaneadas. É recomendado revisar a documentação de preços do CloudWatch OTel e os preços do Amazon CloudWatch antes de uma implantação ampla.

Vale destacar uma limitação importante: esse padrão fornece visibilidade e controles suaves. É possível usar alarmes do CloudWatch e notificações do Amazon Simple Notification Service (SNS) para alertar quando um usuário ou time ultrapassa um limite de uso definido. No entanto, como o IAM Identity Center emite credenciais temporárias diretamente, esse caminho de telemetria local não consegue bloquear sincronamente uma requisição ao Amazon Bedrock com base em um orçamento de tokens. Se for necessário controle rígido, a recomendação é usar um gateway no caminho da requisição com controles de orçamento.

Estratégia de implantação em fases

O artigo original recomenda uma abordagem gradual:

• Fase 1: Comece com um único grupo de engenharia cujos líderes e desenvolvedores concordam com o propósito da telemetria. Valide que a atribuição de identidade está correta, que o dashboard responde perguntas reais de operação e que os controles de acesso refletem a política de governança.
• Fase 2: Adicione um conjunto pequeno de dimensões organizacionais controladas e defina alertas para condições que exigem ação.
• Fase 3: Expanda via configuração gerenciada de workstations somente após o ciclo de vida do coletor, as atualizações de identidade e o processo de suporte estarem repetíveis.
• Fase 4: Combine a telemetria de uso do CloudWatch com os relatórios do CUR 2.0 para que os líderes possam revisar adoção e comportamento operacional ao lado dos custos reais de faturamento.

Limpeza do ambiente

Para remover o padrão de monitoramento, basta parar o coletor nas estações de trabalho e excluir o stack do dashboard:

aws cloudformation delete-stack \
  --stack-name codex-otel-dashboard \
  --region us-west-2

aws cloudformation wait stack-delete-complete \
  --stack-name codex-otel-dashboard \
  --region us-west-2

Se nenhuma outra carga de trabalho depender dos recursos de enriquecimento no nível de conta, é possível avaliar a desativação com aws cloudwatch stop-otel-enrichment e aws observabilityadmin stop-telemetry-enrichment. Confirme as dependências antes, pois essas configurações podem suportar outros casos de uso de observabilidade do CloudWatch na conta.

Conclusão

Escalar o Codex não é apenas uma decisão de acesso — é uma decisão de modelo operacional que conecta capacitação de desenvolvedores, confiabilidade de sistemas, governança e responsabilidade financeira. Ao combinar métricas OTel do Codex, atributos do IAM Identity Center, um coletor local e o Amazon CloudWatch, as organizações conseguem construir visibilidade orientada a decisões sem inserir um novo serviço centralizado no caminho de inferência.

O CloudWatch mostra como o Codex está sendo usado. O CUR 2.0 fornece a fonte da verdade financeira. Juntos, eles suportam um caminho estruturado do piloto à adoção governada. Use o quickstart de acesso nativo AWS do Codex para iniciar um piloto e, em seguida, adapte as dimensões, o modelo de acesso e a cadência de relatórios às decisões que a sua organização precisa tomar.

Fonte

Build visibility for Codex on Amazon Bedrock with OpenTelemetry and Amazon CloudWatch (https://aws.amazon.com/blogs/machine-learning/build-visibility-for-codex-on-amazon-bedrock-with-opentelemetry-and-amazon-cloudwatch/)