Para controlar os custos do Amazon Bedrock, equipes de FinOps e engenharia de plataforma precisam identificar quem gera cada gasto, acompanhar o consumo operacional, escolher como agir ao atingir um orçamento e revisar os resultados. A AWS organiza esse trabalho em cinco etapas: atribuir, observar, impor limites, otimizar e operar. Cada uma responde a uma pergunta diferente sobre os custos.
Um ciclo de gestão para FinOps e plataforma
No guia publicado em 30 de outubro de 2026, a AWS propõe um ciclo conjunto: FinOps cuida da atribuição, dos orçamentos e da revisão de custos; a engenharia de plataforma atua em registros, metadados, controles e padrões de roteamento. A equipe precisa ligar essas frentes para que os dados de consumo ajudem tanto a entender a fatura quanto a decidir quando interromper chamadas.
Como atribuir custos a usuários e aplicações
O primeiro passo é associar as chamadas a uma identidade ou carga de trabalho. A AWS descreve a inclusão de dados do principal do IAM no CUR 2.0, o Cost and Usage Report da AWS. O campo line_item_iam_principal identifica o principal associado à linha de custo. Tags de negócio também podem ser ativadas para alocação de custos; na descrição da AWS, as tags ligadas ao principal usam o prefixo iamPrincipal/.
Uma função IAM compartilhada em um gateway pode atribuir o gasto ao próprio gateway, em vez de distinguir cada pessoa. Para recuperar essa separação, a AWS recomenda assumir uma função de invocação por usuário: o nome da sessão identifica a pessoa, e as tags da sessão registram dimensões de negócio, como equipe ou aplicação.
Para aplicações com agrupamentos estáveis, a AWS descreve application inference profiles por aplicação, modelo e região da AWS; as chamadas usam o ARN do perfil. Já os Projects são destinados, na descrição da AWS, a cargas elegíveis em bedrock-mantle que usam a Responses API ou a Chat Completions API. Um Project pode abranger vários modelos.
Como acompanhar o consumo antes dos dados de faturamento
O CUR e os registros de invocação atendem a necessidades diferentes. A AWS descreve uma defasagem de cerca de 24 horas na atribuição do CUR. Em um exemplo separado, CloudWatch com OpenTelemetry alimenta um painel que pode mostrar gastos por desenvolvedor em minutos. Esse painel operacional permite acompanhar o uso mais cedo; não substitui os dados de faturamento.
A AWS recomenda enviar registros de invocação ao CloudWatch Logs, ao Amazon S3 ou a ambos. O CloudWatch serve a consultas operacionais, enquanto o S3 combinado com o Athena atende análises de longo prazo. Os registros podem incluir dados da solicitação, da resposta e metadados.
Metadados ajudam a identificar aplicação, fluxo de trabalho, locatário ou agente, mas o Bedrock não impõe um esquema consistente para esses campos. Definir nomes e valores padronizados é uma decisão da equipe; sem essa convenção, os dados podem não se agrupar de forma útil entre aplicações.
Qual controle aplicar ao atingir o orçamento
A opção adequada depende de duas escolhas: se basta receber um alerta ou se uma chamada precisa ser bloqueada, e se os clientes podem encaminhar solicitações por um gateway. A AWS descreve três abordagens:
| Controle | O que acontece ao atingir o orçamento | Aplicação | Requisito operacional |
| Alertas do AWS Budgets | A equipe recebe um alerta, mas as chamadas não são bloqueadas automaticamente. | Exige análise e ação da equipe. | Adequado quando a intervenção humana é aceitável. |
| Restrição por IAM | Uma política pode negar acesso; a atualização é assíncrona e pode levar segundos ou minutos. Retirar credenciais tem efeito na próxima renovação. | Não bloqueia necessariamente a chamada que ultrapassa o limite. | Permite controle sem inserir um gateway no caminho da inferência. |
| Bloqueio por gateway | O gateway pode aplicar o limite de forma síncrona e responder com HTTP 429. | A AWS descreve a aplicação em menos de um segundo. | Os clientes precisam passar pelo gateway, que deve ser implantado, dimensionado e revisado quanto à segurança. |
Alertas servem para observar e decidir, não para impor um teto rígido. A restrição por IAM pode limitar o acesso sem mudar o caminho das chamadas, mas sua aplicação é assíncrona. O gateway é a opção descrita pela AWS para bloquear uma solicitação no momento do limite; em contrapartida, acrescenta um componente ao caminho de inferência e exige que os clientes sejam configurados para usá-lo.
Como avaliar roteamento de modelos e prompt caching
A AWS recomenda testar a qualidade de modelos mais baratos na carga de trabalho antes de direcionar tarefas para eles. Uma taxa de roteamento não deve ser tratada como meta universal: o resultado depende de o modelo escolhido atender ao uso pretendido.
As taxas de cache descritas pela AWS em outubro de 2026 se referem a Anthropic Claude na região US East (N. Virginia). A gravação em cache equivale a 1,25× a taxa-base de entrada com TTL de cinco minutos, ou a 2× com TTL de uma hora. Para leituras, a AWS informa 0,1× da taxa-base para Claude Sonnet 4.6 e Claude Haiku 4.5, e 0,05× para Claude Sonnet 5.5 e Claude Opus 5.5.
O cálculo para dez chamadas supõe o mesmo prefixo de entrada em todas elas, com uma gravação inicial e nove leituras de igual volume. Com uma gravação a 1,25× e leituras a 0,1×, a conta é (1,25 + 9 × 0,1) / 10 = 21,5% do custo de entrada sem cache para esse prefixo. Com leituras a 0,05×, fica (1,25 + 9 × 0,05) / 10 = 17%.
Esses percentuais dizem respeito apenas às cobranças dos tokens de entrada do prefixo considerado. Não incluem tokens de saída nem outras cobranças do serviço, e dependem da reutilização do prefixo nas nove leituras. Se uma gravação não for seguida por reutilizações, não há leituras que compensem o custo maior da gravação.
Como transformar métricas em uma revisão periódica
A AWS sugere acompanhar gasto diário por desenvolvedor, participação de solicitações encaminhadas a modelos mais econômicos, taxa de acerto de leitura do cache e custo por resultado bem-sucedido. A empresa trata as faixas do scorecard como pontos de partida a calibrar para cada operação.
Para manter a revisão em dia, a AWS sugere uma frequência semanal para grupos de alta velocidade e quinzenal nos demais casos. A equipe pode usar esse encontro para ajustar os limites e verificar se atribuição, telemetria e controles continuam alinhados às cargas de trabalho.
