A AWS publicou em 30 de outubro de 2026, no blog de machine learning da companhia, um guia operacional para um problema que cresce junto com a adoção de IA generativa: controlar a conta do Amazon Bedrock. O texto, intitulado Managing Amazon Bedrock costs end to end: A playbook for FinOps and platform teams, propõe um modelo de cinco estágios — atribuir, observar, impor, otimizar e operar, executado como um ciclo contínuo, e não como uma ação pontual de redução de gastos.
A tese central é que comparar preços por token entre modelos e pedir aos times de aplicação que encurtem prompts ajuda, mas não responde às perguntas que finanças e lideranças de engenharia fazem quando o uso escala: qual time gastou, em qual workload e se aquele gasto estava dentro de um orçamento aprovado. Para os autores, o ajuste não vem de um modelo mais barato ou de um prompt menor, e sim de um modelo operacional repetível.
Cinco estágios com papéis divididos
O playbook distribui as etapas entre dois públicos. Praticantes de FinOps lideram o primeiro e o quinto estágios, responsáveis por atribuição, chargeback, orçamentos e revisão de anomalias.
As equipes de engenharia de plataforma conduzem do segundo ao quarto, cuidando de logging, metadados de requisição, enforcement e padrões de roteamento. A revisão é conjunta.
A ordem é deliberada: cada estágio depende dos anteriores. Segundo o texto, times que pulam direto para a otimização, sem atribuição e observabilidade, estão apenas adivinhando onde cortar.
Na prática, os cinco estágios são: atribuir cada dólar a um dono; tornar cada requisição observável; dar dentes aos orçamentos; otimizar os padrões de plataforma; e operar uma cadência de revisão que transforme dados em decisões.
Atribuição: cada dólar com um dono
O ponto de partida é o recurso de atribuição granular de custos do Amazon Bedrock. Segundo a AWS, o serviço atribui automaticamente os custos de inferência ao principal do AWS Identity and Access Management (IAM) que fez a chamada, em todos os modelos, sem recursos adicionais para administrar.
O ARN do chamador aparece na coluna line_item_iam_principal do AWS Cost and Usage Report (CUR) 2.0, com cobertura para usuários IAM, roles, identidades federadas e chaves de API.
O roteiro sugerido começa por habilitar os dados de principal IAM na exportação do CUR 2.0. Em seguida, é preciso marcar os principals com dimensões de negócio, como time, aplicação e centro de custo; no caso de acesso federado, o identity provider deve repassar nomes de sessão e tags por meio de claims OIDC ou SAML.
Depois, essas tags precisam ser ativadas como tags de alocação de custo no AWS Billing, pelo console ou pela API UpdateCostAllocationTagsStatus, para então analisá-las.
Por que workloads agênticos mudam a conta
O material dedica atenção especial a cargas agênticas, que tornam a questão mais urgente. Um assistente conversacional normalmente faz uma invocação de modelo por turno do usuário.
Já um fluxo agêntico, como um assistente de programação que planeja uma alteração, lê arquivos, chama ferramentas e itera, faz muitas invocações por tarefa e carrega um contexto maior em cada uma delas.
Com isso, o consumo de tokens passa a escalar com o grau de autonomia concedido ao fluxo e com o tamanho do contexto transportado, e não com o número de interações do usuário. Como o consumo é função de como o workload é projetado e operado, a gestão de custos de IA generativa se torna uma disciplina de arquitetura e de operação.
A orientação é evitar médias publicadas e trabalhar com os próprios números, usando o AWS Pricing Calculator e a página de preços do Amazon Bedrock para modelar tarifas, além de medir o consumo real de cada workload.
Enforcement, otimização e cadência
Com a atribuição e a observabilidade no lugar, o playbook avança para o controle. No estágio de enforcement, os orçamentos ganham consequência: no mínimo alertas, e bloqueios rígidos onde o risco exigir, com o objetivo de conter o excesso antes que ele se acumule.
Na otimização, o foco são os padrões de plataforma, roteamento de modelos, caching e limites de tokens, capazes de eliminar desperdício de forma centralizada, em vez de pedir que cada time tenha cuidado individualmente.
O ciclo se fecha com a operação: um scorecard pequeno e uma cadência regular de revisão transformam os dados em decisões. A mensagem final é que a conta do Bedrock não é um problema de tabela de preços, mas de responsabilidade compartilhada entre quem constrói as aplicações e quem responde pelo gasto em nuvem.
Fontes e links
- AWS
- Atribuição granular de custos para Amazon Bedrock
- Amazon Bedrock pricing
- AWS Cost and Usage Report 2.0
