O Amazon Bedrock cobra por token de entrada e de saída processado, com custos que variam conforme o modelo, o modo de cobrança e o padrão dos workloads. O on-demand atende bem usos imprevisíveis ou de baixo volume; o provisioned throughput entrega capacidade garantida para workloads de produção consistentes e de alto volume; e o batch inference oferece até 50% de desconto em tarefas que não precisam rodar em tempo real. A customização e o fine-tuning de modelos têm cobranças separadas de treinamento, armazenamento e inferência. Como o custo de IA se comporta diferente do compute tradicional, os times de CloudOps precisam de visibilidade no nível do token e de controles automáticos de orçamento para manter o gasto com Bedrock previsível.
O orçamento de nuvem tradicional foi pensado em torno de unidades previsíveis: horas de instância, gigabytes de armazenamento, egresso de rede. O Amazon Bedrock não se encaixa nesse modelo. Sua fatura é função de quantas palavras seus usuários digitam, de quão prolixos são seus prompts, do foundation model escolhido e da frequência com que sua aplicação repete chamadas que falharam. Uma única decisão de arquitetura, como optar pelo Claude 3 Opus em vez do Claude 3 Haiku, pode mudar o custo em uma ordem de grandeza quando a operação ganha escala.
Isso não é uma crítica ao Bedrock. É uma realidade estrutural da precificação por inferência, sobre a qual a maioria dos times de CloudOps e FinOps nunca precisou pensar antes. Os engenheiros que criaram seus recursos de IA entendem de tokens. Quem aprova seu orçamento de nuvem provavelmente não. Fechar essa lacuna virou urgência: o relatório State of FinOps 2026, da FinOps Foundation, mostrou que 98% das organizações já gerenciam ativamente o gasto com IA — contra apenas 31% dois anos antes. Visibilidade de custo deixou de ser um diferencial. É o que viabiliza a conversa sobre crescimento em IA.
Este guia destrincha como funciona a precificação do Bedrock, como estimar custos antes que eles cheguem na sua fatura e como construir o monitoramento e os controles que tornam o gasto com IA defensável.
Como funciona a precificação do Amazon Bedrock?
O Amazon Bedrock cobra pela inferência: o processo de enviar um prompt a um foundation model e receber uma resposta. A unidade central de cobrança é o token, um pedaço de texto que equivale, em média, a quatro caracteres ou três quartos de uma palavra. Toda requisição tem tokens de entrada (seu prompt, mensagem de sistema e qualquer histórico de conversa) e tokens de saída (a resposta do modelo). Você paga pelos dois, com tarifas diferentes.
O que torna o custo do Bedrock mais difícil de prever do que o de compute é que tokens não são fixos. Um usuário que escreve uma pergunta de duas frases consome muito menos tokens de entrada do que outro que cola um documento de 3.000 palavras. Uma aplicação que pede ao modelo para "resumir brevemente" gera menos tokens de saída do que uma que pede uma análise detalhada. Multiplique essa variação por milhares de requisições diárias e a previsão de orçamento fica realmente difícil sem uma instrumentação adequada.
Dois fatores adicionais complicam o quadro. Primeiro, em muitos modelos os tokens de saída custam mais do que os de entrada, porque gerar texto exige mais computação do que processá-lo. Isso varia por provedor: alguns modelos cobram entrada e saída na mesma tarifa, enquanto outros cobram bem mais pela saída. Segundo, a escolha do modelo tem efeito drástico nas tarifas por token. Um modelo leve custa uma fração do que um modelo de fronteira da mesma família custa por milhão de tokens. O modelo certo para uma tarefa de classificação muitas vezes é o errado para uma tarefa de raciocínio complexo, e vice-versa. Selecionar só pela capacidade, sem considerar custo, é uma das fontes mais comuns de gasto desnecessário com Bedrock.
Modelos de precificação e estruturas de tarifa do Amazon Bedrock
O Bedrock oferece três modos principais de cobrança: on-demand, provisioned throughput e batch inference. Cada um atende a um perfil de workloads diferente. Entender os trade-offs entre eles é a base tanto do controle de custo quanto da confiabilidade operacional.
Modo de cobrança
Como você paga
Compromisso
Latência
Indicado para
On-demand
Por token processado
Nenhum
Variável; risco de throttling em picos
Workloads esporádicos, experimentais ou de baixo volume
Provisioned throughput
Tarifa fixa por hora por unidade de modelo
1 ou 6 meses
Garantida; sem throttling
Workloads consistentes e de alto volume; obrigatório para modelos customizados
Batch inference
Por token (até 50% de desconto vs. on-demand)
Nenhum
Assíncrono; não é em tempo real
Processamento de documentos, jobs noturnos, pipelines de enriquecimento assíncrono
Preço on-demand para foundation models
O on-demand é o padrão. Você paga por 1.000 tokens processados, sem compromisso prévio nem gasto mínimo. É ideal para workloads exploratórios, esporádicos ou ainda imprevisíveis demais para justificar reserva de capacidade.
O risco operacional do on-demand é o throttling. A AWS impõe limites de concorrência no acesso aos foundation models e, em períodos de pico, requisições podem entrar em fila ou falhar. Para ferramentas internas ou aplicações de baixo impacto, esse trade-off é aceitável. Para recursos voltados ao cliente final com requisitos de latência, não é.
As tarifas por token variam bastante conforme a família e a geração do modelo. Na linha Anthropic Claude no Bedrock, por exemplo, modelos mais leves podem custar uma ordem de grandeza a menos por milhão de tokens do que modelos de fronteira da mesma família. As tarifas também diferem entre tokens de entrada e de saída na maioria dos modelos, embora alguns provedores cobrem o mesmo valor. Escolher o modelo certo para a tarefa, e não apenas o mais capaz disponível, é a decisão de custo de maior alavancagem que um time pode tomar. Sempre confira as tarifas atuais na página de preços do AWS Bedrock antes de fechar uma estratégia de seleção de modelo, já que tarifas e versões disponíveis mudam com frequência.*
Opções de preço de provisioned throughput
O provisioned throughput funciona como uma instância reservada para inferência. Você compra unidades de modelo, cada uma garantindo uma taxa específica de tokens por minuto, e paga uma tarifa fixa por hora, use a capacidade ou não. Os compromissos são de um ou seis meses, e prazos mais longos rendem tarifas melhores.
O case financeiro do provisioned throughput depende da utilização. Se seu workload roda em volume consistente durante o horário comercial, a tarifa fixa por hora pode trazer economia relevante em relação ao on-demand para o mesmo throughput. Mas o compromisso é real. Capacidade provisionada e ociosa custa o mesmo que capacidade plenamente utilizada. Times que provisionam para o pico e operam com 30% de utilização média não economizam nada.
O provisioned throughput também é a única opção de inferência para modelos customizados e fine-tuned. Se seu time pretende implantar um foundation model adaptado a um domínio, isso obriga o uso de provisioned throughput, independentemente do volume.
Custos de customização e fine-tuning de modelos
Fazer fine-tuning de um foundation model no Bedrock gera três eventos de custo distintos: treinamento, armazenamento e inferência. Os custos de treinamento se baseiam no total de tokens processados em seu dataset e no número de épocas de treinamento. Após o treinamento, o modelo customizado fica em armazenamento com cobrança mensal. Servir o modelo fine-tuned exige provisioned throughput, com pelo menos uma unidade de modelo, sem compromisso de longo prazo.
Antes de partir para a customização, os times devem rodar uma prova de conceito em um dataset reduzido para validar se os ganhos de desempenho justificam a estrutura de custo extra. A destilação de modelos, que comprime as capacidades de um modelo grande em outro menor e mais rápido, pode reduzir custos de inferência no longo prazo. Mas modelos destilados têm seus próprios custos de treinamento e também exigem provisioned throughput para serem implantados.
Como calcular e estimar os custos do Amazon Bedrock
Estimar custos com precisão exige sair das suposições vagas e partir para volumes de tokens medidos. Times que projetam o gasto com Bedrock pelo "número de chamadas de API" vão errar. O número de tokens por chamada, e a proporção entre entrada e saída, importa muito mais do que a quantidade de chamadas.
Cálculo de tarifas de tokens de entrada e saída
A fórmula central é simples. O custo mensal é igual aos tokens de entrada multiplicados pela tarifa de tokens de entrada, mais os tokens de saída multiplicados pela tarifa de tokens de saída, ambos expressos por milhão de tokens. O desafio é estimar esses volumes de tokens com precisão antes de existirem dados de produção.
Comece pela arquitetura de prompts da sua aplicação. Um system prompt de 500 tokens é cobrado em cada requisição. Um setup de retrieval-augmented generation (RAG) que injeta 2.000 tokens de contexto por consulta multiplica esse custo em cada invocação. Audite seus templates de prompt e conte os tokens com o tokenizer do Bedrock ou um contador específico do modelo antes de subir para produção.
Para estimar a saída, analise o que sua aplicação pede ao modelo. Tarefas de classificação com resposta única geram bem menos tokens de saída do que respostas conversacionais ou conteúdo longo. Monte uma amostra representativa de requisições, meça as contagens reais de tokens de entrada e saída e use isso como linha de base. Depois, aplique um multiplicador para o volume esperado de requisições.
Um exemplo prático: uma aplicação que envia 100.000 requisições diárias a um foundation model de gama média, com média de 800 tokens de entrada e 400 tokens de saída, gera 80 milhões de tokens de entrada e 40 milhões de tokens de saída por dia. Dependendo do modelo e da tarifa de tokens de saída, o gasto diário total pode ir de dezenas a centenas de dólares e fechar o mês na casa dos cinco dígitos. O custo dos tokens de saída, geralmente maior que a tarifa de entrada do mesmo modelo, responde pela maior parte desse valor.* Para tarifas atuais de todos os foundation models disponíveis, consulte a página de preços do AWS Bedrock.
Ferramentas e métodos de estimativa de custo
A AWS oferece uma calculadora de preços do Bedrock e uma ferramenta de estimativa de tokens no console, ambas úteis para a modelagem inicial. Para visibilidade contínua, o AWS Cost Explorer mostra o gasto com Bedrock, mas não detalha custos por modelo, aplicação ou time sem tagueamento de recursos. Tags são essenciais. Marque cada invocação do Bedrock com identificadores de aplicação, time e ambiente que correspondam à sua estrutura de alocação de custos, antes que os workloads vão para produção.
O DoiT Cloud Intelligence vai além de tags e dashboards. Ele entrega visibilidade em tempo real do custo de IA em todo o seu uso do Bedrock, com análises que mostram como a escolha do modelo, padrões de prompt e picos de uso impulsionam o gasto em nível granular. Essa visibilidade conecta os dados de custo às decisões de engenharia de um jeito que relatórios estáticos não conseguem.
Em ambientes multimodelo, em que aplicações diferentes usam foundation models diferentes, defina orçamentos e limites de alerta separados para cada modelo. Um pico no custo de um modelo de fronteira é muito diferente de um pico em um modelo leve, e juntar tudo em uma única linha de orçamento dificulta a análise de causa raiz.
Estratégias de otimização de custo do Amazon Bedrock para times de CloudOps
Otimização no Bedrock não é uma auditoria pontual. É uma disciplina operacional. Workloads de IA evoluem rápido. Um prompt eficiente no lançamento pode ficar caro à medida que os casos de uso se expandem, as janelas de contexto crescem e os históricos de conversa se acumulam. Os times que controlam custos no Bedrock o tratam da mesma forma que tratam o right-sizing de compute: continuamente, com sinais automatizados puxando ações.
Right-sizing na escolha do modelo para os workloads
O right-sizing de modelo é a otimização de maior alavancagem disponível, e a maioria dos times investe pouco nela. O padrão é escolher o modelo mais capaz da família e implantá-lo em todos os casos de uso. A abordagem melhor é casar a capacidade do modelo com a complexidade da tarefa.
Classifique seus casos de uso pelo que eles realmente exigem. Tarefas simples de extração, classificação e sumarização não precisam de um modelo de fronteira. Um modelo menor e mais barato dá conta com precisão por uma fração do custo. Reserve modelos grandes para raciocínio complexo, resolução de problemas em múltiplas etapas e tarefas em que a qualidade da saída afeta materialmente os resultados de negócio.
Teste isso com rigor. Rode seus workloads reais contra um conjunto escalonado de modelos, meça a qualidade da saída pelos seus critérios de aceitação e calcule a diferença de custo. Em muitos casos, um patamar de qualidade de 90% é alcançável com um modelo que custa de 10 a 20 vezes menos do que a alternativa de topo. Não é um ganho marginal de eficiência. Em escala, é uma transformação de orçamento.
Considere também o batch inference para workloads que não exigem respostas em tempo real. O modo batch do Bedrock reduz o custo de tokens em até 50% nos modelos suportados. Processamento de documentos, jobs noturnos de análise e pipelines de enriquecimento assíncrono são fortes candidatos. O trade-off é a latência: jobs em batch rodam de forma assíncrona, então não servem para recursos voltados ao usuário que esperam resposta imediata.
Implementando monitoramento de uso e controles de orçamento
Monitorar o Bedrock sem telemetria no nível do token é como monitorar EC2 sem métricas de CPU. O AWS CloudWatch mostra contagens de invocações e erros do Bedrock. Adicione métricas customizadas para consumo de tokens por modelo, por aplicação e por ambiente. Configure alarmes em limites de tokens que disparem antes que os custos virem problema, e não depois que a fatura chegar.
O prompt caching reduz a cobrança de tokens de entrada para conteúdo repetido ou estático. System prompts, documentos de referência e contexto compartilhado que não mudam entre requisições podem ficar em cache. A parcela em cache é cobrada com tarifa reduzida, gerando economia real em aplicações em que o mesmo system prompt aparece em toda chamada. Habilite o prompt caching para qualquer conteúdo que se encaixe nesse padrão.
A inferência cross-region roteia requisições para a capacidade de modelo disponível em outras regiões da AWS quando sua região principal está com throttling ou no limite. Isso melhora a confiabilidade sob carga sem exigir compromissos separados de provisioned throughput. Avalie esse recurso para workloads de produção em que a tolerância a throttling é baixa.
Os controles do AWS Budgets podem alertar sobre o gasto com Bedrock, mas reagem a um gasto que já aconteceu. O controle mais forte é o rate limiting no nível da aplicação, que evita o uso descontrolado antes de chegar na fatura. Defina limites de tokens por usuário, por sessão e por aplicação na sua camada de aplicação e aplique-os antes que as requisições cheguem à API do Bedrock. Essa é a diferença entre um sinal de monitoramento e um guardrail de verdade.
O DoiT Cloud Intelligence oferece detecção automática de anomalias para gastos com IA, expondo desvios dos padrões de custo esperados em tempo real. Ou seja, os times de CloudOps ficam sabendo dos problemas de custo em horas, e não no fechamento do mês.
Torne os custos do Amazon Bedrock previsíveis e defensáveis
Gasto imprevisível com IA não é só um problema financeiro. É um problema de credibilidade. Quando líderes de engenharia não conseguem explicar o que provocou um aumento de 40% nos custos do Bedrock de um mês para o outro, isso gera atrito com finanças, freia decisões de investimento em IA e enfraquece o argumento para expandir iniciativas de IA. Visibilidade de custo não é overhead. É o que viabiliza a conversa sobre crescimento em IA.
Os times que acertam tratam a gestão de custos do Bedrock como prática de engenharia, e não como função financeira. Eles instrumentam o uso de tokens já no desenvolvimento, e não depois da primeira fatura inesperada. Validam a escolha do modelo contra trade-offs de custo e qualidade antes do lançamento. Constroem guardrails automáticos que aplicam limites de gasto sem exigir intervenção manual. E acompanham o custo por resultado, não só o custo por chamada, para demonstrar ROI em termos que tanto engenheiros quanto executivos entendem.
Essa é a maturidade operacional que transforma o Bedrock de risco de custo em capacidade sustentável.
A DoiT ajuda times de CloudOps e FinOps a fechar a lacuna entre dados de custo de IA e ação. O DoiT Cloud Intelligence expõe o gasto com Bedrock em tempo real por modelo, aplicação e time, com alertas e recomendações automáticas que não exigem um especialista em FinOps para serem interpretados. A DoiT possui a AWS Generative AI Competency e está disponível diretamente pelo AWS Marketplace, então os times podem implantar o Cloud Intelligence dentro do fluxo de Procurement AWS já existente, sem adicionar uma nova relação com fornecedor.
Conheça o DoiT Cloud Intelligence para gestão de custos de IA e veja como a visibilidade dos preços do Bedrock pode passar de reativa para preditiva.
Perguntas frequentes sobre os preços do Amazon Bedrock
Qual é a forma mais barata de usar o Amazon Bedrock?
A abordagem mais econômica combina right-sizing de modelo com batch inference sempre que possível. Usar um modelo menor e adequado à tarefa, em vez de um modelo de fronteira, pode reduzir o custo por token em 10x a 20x. Habilitar batch inference para workloads que não rodam em tempo real soma até 50% de economia em cima disso. O prompt caching para system prompts e contextos repetidos reduz ainda mais a cobrança de tokens de entrada. Comece auditando quais casos de uso realmente exigem um modelo grande e migre tudo o que não exigir para o menor modelo que atenda ao seu padrão de qualidade.
Como o provisioned throughput do Amazon Bedrock se compara ao preço on-demand?
O on-demand cobra por token processado, sem compromisso. O provisioned throughput reserva capacidade dedicada a uma tarifa fixa por hora, cobrada usando ou não. O provisioned se torna vantajoso em níveis de utilização altos e consistentes, normalmente quando os custos do on-demand passariam da tarifa do compromisso por hora. Para modelos customizados e fine-tuned, o provisioned throughput é obrigatório, independentemente do volume. O on-demand é o padrão certo para workloads variáveis, aplicações em estágio inicial e qualquer caso em que os padrões de uso ainda não sejam previsíveis.
Como tokens de entrada e tokens de saída afetam os custos do Amazon Bedrock?
Tokens de entrada e de saída têm preços separados, e os de saída costumam custar de três a cinco vezes mais por milhão do que os de entrada. Isso significa que a verbosidade da saída — ou seja, o quanto se pede ao modelo para produzir por requisição — tem impacto desproporcional na sua fatura. Aplicações que pedem explicações detalhadas, conteúdo longo ou saídas estruturadas verbosas vão pesar muito mais no custo de tokens de saída. Desenhar prompts que limitem o tamanho da saída sem sacrificar a qualidade é um controle direto de custo.
O Amazon Bedrock cobra por chamadas de API que falham?
O Bedrock cobra pelos tokens efetivamente processados. Requisições que falham antes do início da inferência, como erros de autenticação ou requisições com throttling, não geram cobrança de tokens. Mas retries em chamadas que chegam à inferência antes de falhar, por exemplo por violação de tamanho de contexto, podem gerar cobranças parciais. Monitorar taxas de retry e modos de falha faz parte de uma gestão de custo responsável.
Quais ferramentas ajudam a acompanhar e controlar os gastos com o Amazon Bedrock?
O AWS Cost Explorer mostra o gasto com Bedrock no nível do serviço, e o AWS Budgets pode alertar sobre limites de custo. O CloudWatch captura métricas de invocação. Para visibilidade no nível do token, é essencial registrar do lado da aplicação as contagens de tokens de entrada e saída por requisição. O tagueamento de recursos por aplicação, time e ambiente viabiliza a alocação de custo. Plataformas como o DoiT Cloud Intelligence oferecem analytics de custo de IA em tempo real e detecção automática de anomalias em todo o seu uso do Bedrock.