AWS publica template de data lake para o Bedrock: dá para ver cada prompt, token e seu custo

É uma situação conhecida: no fim do mês chega a fatura do Bedrock, o valor subiu e ninguém consegue responder "quem gastou e por quê". O total aparece, mas o conteúdo das chamadas não. Não dá para saber qual prompt foi enviado, o que o modelo devolveu e quantos tokens consumiu. A AWS propõe uma solução pronta: um data lake central para todas as chamadas do Bedrock na organização. Os templates do CloudFormation, o código da Lambda e as consultas SQL estão no repositório AWS Sample Bedrock Invocation Data Lake.

O que existe de fábrica e o que falta

O Bedrock tem o model invocation logging, que grava o registro completo de requisições e respostas no S3 ou no CloudWatch. Mas o recurso precisa ser ativado separadamente em cada conta, e os dados ficam onde foram gerados. Com uma dezena de contas, o resultado é uma dezena de ilhas isoladas. Fica difícil comparar equipes, encontrar um prompt dispendioso ou investigar um pico de gastos por equipe.

Como funciona o pipeline

O caminho de cada chamada tem cinco etapas:

• O Bedrock, na conta de origem, grava o log em um grupo do CloudWatch.
• O subscription filter funciona como uma regra permanente de encaminhamento: cada novo evento segue para um CloudWatch Logs destination na conta central. As contas de origem não recebem permissões sobre o pipeline central; elas apenas enviam os eventos.
• Uma Lambda pequena descompacta os pacotes do CloudWatch, que chegam comprimidos e codificados. Ela descarta ruídos de serviço, como a mensagem "Permissions are correctly set", e sobe para o nível superior o campo aninhado com a identidade de quem fez a chamada.
• O Amazon Data Firehose armazena os registros em buffer, converte o JSON em Parquet e os grava no S3 particionados por data (year/month/day).
• A tabela do Glue ensina o Athena a ler esses arquivos, e a partir daí basta usar SQL comum.

No fim, cada chamada tem em uma única tabela o prompt, a resposta, o número de tokens de entrada e de saída, o modelo, o motivo da parada, a conta, o horário e a IAM role. Deixa de ser "gastamos X tokens" e passa a ser "foi isto que aconteceu em cada chamada".

O que fazer com isso na prática

Alguns cenários descritos no post:

• Depuração. Você recupera o prompt e a resposta exatos de uma chamada específica, sem vasculhar logs brutos.
• Eficiência. Você compara tokens de input e output por equipe e por modelo e descobre onde eles são desperdiçados.
• Engenharia de prompts. Você busca respostas com stop_reason = max_tokens: elas foram truncadas, então vale revisar o prompt ou a configuração.
• Custo. A tabela é cruzada com o AWS Cost and Usage Report 2.0 pelo IAM ARN, o que permite ver os gastos por equipe e por dia, além do custo das chamadas menos eficientes.

Para facilitar a visualização, há um dashboard no Quick Sight, instalado com o comando cid-cmd deploy. Nele é possível incluir metadados da organização, como os nomes das equipes.

Os autores relacionam tudo isso à tokenomics: segundo eles, na conferência da FinOps Foundation em 2026 ela foi anunciada como um domínio separado do FinOps. A lógica é simples: não se otimiza o que não foi medido. O data lake entrega justamente essa base.

Limitações e armadilhas

O principal risco é a segurança. Você reúne em um único bucket os prompts e as respostas completos de todas as equipes, e eles podem conter PII. O bucket é criptografado com KMS, mas o acesso a ele e aos resultados do Athena precisa ser restringido por você mesmo, com políticas IAM.

Há também detalhes operacionais:

• O logging do Bedrock é uma configuração no nível da conta, e não um recurso do CloudFormation. É preciso ativá-lo com uma chamada de API separada em cada conta de origem, e somente com entrega no CloudWatch.
• Os dados não aparecem instantaneamente: o Firehose descarrega o buffer cerca de um minuto depois, às vezes mais. Para investigações isso é aceitável; para alertas em tempo real, não.
• A view do Athena é criada manualmente: é preciso executar uma vez a consulta salva.
• O cruzamento com o custo é feito pelo IAM ARN. Se todas as equipes acessam o Bedrock com a mesma role, a divisão por equipe será apenas aproximada. Esta é uma conclusão nossa; o post não trata disso diretamente.
• Na hora de remover a stack, esvazie primeiro os buckets e exclua o workgroup do Athena manualmente.

Conclusão

Se você usa o Bedrock em várias contas e não sabe dizer qual equipe queima mais tokens, vale implantar o template. O conselho dos autores: não tente abranger tudo de uma vez. Comece por uma ou duas contas, aprenda a consultar a tabela e só depois expanda para a organização. Aproveite também para revisar as políticas IAM e o bucket enquanto ainda há pouco dado armazenado.