Preços e cobrança: como o Bedrock cobra de você
- ⬜🪨 O que é o Amazon Bedrock (e por que ele existe)(AWS Bedrock — GenAI em Produção)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
"O Bedrock é caro ou barato?" é a pergunta errada. A resposta honesta é: depende de três escolhas suas — qual modelo, qual modo de cobrança e se você usa prompt caching. A mesma carga de trabalho pode custar US$ 60 ou US$ 10.000 por mês só mexendo nessas três alavancas. Este módulo mostra como o Bedrock cobra e onde está o dinheiro que a maioria dos times deixa vazar.
Os modos de cobrança
O Bedrock não tem taxa de plataforma nem mínimo mensal: você paga pela inferência. O que muda é o modo. São três formas principais de pagar, mais uma otimização de roteamento que sai de graça:
| Modo | Como cobra | Quando usar |
|---|---|---|
| On-demand | Por token, input e output cobrados separadamente. Sem mínimo, sem commit. Throughput limitado pela quota da região. | Baseline. Tráfego variável, dev, volume baixo/médio. Comece aqui. |
| Batch | Mesma tabela de preços, em jobs assíncronos (até ~24h). ~50% de desconto. | Cargas não-interativas: embeddings em massa, classificação offline, enriquecimento de dados. |
| Provisioned Throughput | Por model unit (MU)/hora, com commit de 1 ou 6 meses. Capacidade dedicada. | Throughput alto e constante, latência garantida, ou modelos customizados. |
| Cross-region inference (inference profiles) | SEM taxa extra: cobra a tabela da região de origem. Variante Global CRIS ~10% mais barata. | Ligado por padrão em muitos modelos. Ganha resiliência e quota efetiva sem pagar mais. |
Cross-region inference (os inference profiles) roteia sua chamada para a região com capacidade disponível dentro de uma geografia. Não há taxa extra: você paga a tabela da região de origem do perfil. A variante Global CRIS pode rotear para qualquer região e costuma sair ~10% mais barata. É resiliência e mais quota efetiva sem custo adicional — por isso muitos modelos já vêm com o inference profile ligado por padrão.
Provisioned Throughput só ganha se você satura a MU quase 24/7
Provisioned Throughput cobra por model unit/hora, com commit de 1 ou 6 meses. Exemplo: Llama 3.3 70B fica em ~US$ 24/MU-hora sem commit (~US$ 17.520/mês) e ~US$ 13/hora no commit de 6 meses (~US$ 9.548/mês). Só compensa se a MU roda perto de 100% quase o dia inteiro; abaixo disso, on-demand é mais barato porque você só paga o que usa. Confirme em aws.amazon.com/bedrock/pricing — preços mudam e variam por região.
Quanto custa cada modelo
Toda cobrança on-demand parte da mesma ideia: input e output são cobrados separadamente, por 1 milhão de tokens. Guarde este padrão antes de olhar a tabela — nos modelos Claude e Nova, o output custa 4 a 5 vezes o input. Ou seja, a resposta pesa muito mais que a pergunta.
| Modelo | Input / 1M tokens | Output / 1M tokens |
|---|---|---|
| Claude Opus 4.8 | $ 5,00 | $ 25,00 |
| Claude Sonnet 5 | $ 3,00 (intro $ 2,00*) | $ 15,00 (intro $ 10,00*) |
| Claude Haiku 4.5 | $ 1,00 | $ 5,00 |
| Amazon Nova Micro | $ 0,035 | $ 0,14 |
| Amazon Nova Lite | $ 0,06 | $ 0,24 |
| Amazon Nova Pro | $ 0,80 | $ 3,20 |
| Amazon Nova Premier | ~$ 2,50 | ~$ 12,50 |
| Meta Llama 3.3 70B | ~$ 0,72 | ~$ 0,72 |
| DeepSeek-R1 | ~$ 1,35 | $ 5,40 |
Embeddings, imagem e o preço promocional do Sonnet 5
* Sonnet 5 tem preço de introdução ($ 2 input / $ 10 output por 1M) até 31/ago/2026; depois volta a $ 3 / $ 15. Embeddings são muito mais baratos: Titan Text Embeddings V2 ~$ 0,02 por 1M tokens; Cohere Embed ~$ 0,10 por 1M. Geração de imagem cobra por imagem: Nova Canvas ~$ 0,04–0,08 por imagem, conforme resolução/qualidade. Confirme em aws.amazon.com/bedrock/pricing — preços mudam e variam por região.
Estes números são referência, não contrato
Todos os valores aqui são de meados de 2026, região us-east-1, em USD, e servem para ordem de grandeza. Preços mudam com frequência e variam por região — sempre confirme em aws.amazon.com/bedrock/pricing antes de fechar qualquer estimativa ou budget.
Prompt caching — a alavanca #1 de custo
Se existe uma única alavanca que muda a fatura de um app de GenAI, é o prompt caching. A ideia: você marca um prefixo estável do prompt (instruções, few-shot, contexto fixo) e o Bedrock guarda o estado interno do modelo para aquele prefixo. Nas próximas chamadas, ler o cache custa uma fração de reprocessar tudo de novo.
A matemática do cache
Cache READ custa ~0,1× o preço normal do input (≈90% de desconto no que estava cacheado). Cache WRITE custa 1,25× (TTL de 5 min) ou 2× (TTL de 1h, no Claude) o input normal. Alguns modelos, como o Nova, não cobram a taxa de write. Break-even com TTL de 5 min: cerca de 2 requests que reaproveitam o prefixo já pagam o write. A partir daí, é lucro. Confirme em aws.amazon.com/bedrock/pricing — preços mudam e variam por região.
Duas regras operacionais fazem ou quebram o cache. Primeira: é prefix match exato — o cache vale do começo do prompt até o cachePoint, e 1 byte diferente antes desse ponto invalida tudo o que vem depois. A ordem canônica do prefixo é tools → system → messages, então mantenha o conteúdo volátil (a pergunta do usuário, dados dinâmicos) o mais para o fim possível. Segunda: meça. A resposta traz cacheReadInputTokens e cacheWriteInputTokens no bloco usage; se em requests repetidos o read vier zero, há um invalidador silencioso no prefixo — quase sempre um timestamp, UUID ou data injetados no system prompt.
Cache é prefix match: 1 byte invalida tudo depois
Nunca coloque nada variável antes do cachePoint. Um 'Hoje é 2026-07-25' ou um request_id no topo do system prompt reescreve o prefixo a cada chamada e zera o cache — você paga write toda vez e nunca lê. Se cacheReadInputTokens vier 0 em chamadas repetidas, é quase sempre isso. Volátil vai para o fim, sempre.
import boto3
client = boto3.client("bedrock-runtime", region_name="us-east-1")
# Prefixo ESTÁVEL: 20k tokens de instruções + few-shot que não mudam entre requests
SYSTEM_PROMPT = load_system_prompt() # sem timestamp/UUID no topo!
resp = client.converse(
modelId="us.anthropic.claude-sonnet-5-20260514-v1:0",
system=[
{"text": SYSTEM_PROMPT},
{"cachePoint": {"type": "default"}}, # marca o fim do prefixo cacheavel
],
messages=[
# a parte volatil (pergunta do usuario) vem DEPOIS do cachePoint
{"role": "user", "content": [{"text": pergunta_do_usuario}]},
],
)
usage = resp["usage"]
print("in:", usage["inputTokens"], "out:", usage["outputTokens"])
# Se, ao repetir, cacheReadInputTokens vier 0 -> ha um invalidador no prefixo
print("cache read:", usage.get("cacheReadInputTokens"))
print("cache write:", usage.get("cacheWriteInputTokens"))Exemplo: ~89% de economia só no prefixo
System prompt de 20.000 tokens, 100 requests/hora no Sonnet 5. SEM cache: 100 × 20.000 tokens de input por hora ≈ US$ 6/hora só para reprocessar o prefixo. COM cache (TTL 5 min): você escreve o prefixo uma vez e lê a ~0,1× nas demais chamadas → ~US$ 0,67/hora. São ~89% de economia sobre a parte fixa do prompt, sem tocar na qualidade da resposta. Confirme os preços em aws.amazon.com/bedrock/pricing — mudam e variam por região.
Você tem 1 milhão de documentos para gerar embeddings, sem pressa de resposta em tempo real. Qual modo de cobrança corta o custo pela metade?
A escolha de modelo muda o custo em ~170×
Nenhuma otimização de cache ou modo bate a decisão mais barata de todas: escolher o modelo certo para a tarefa. Veja a mesma carga — 1 milhão de requests/mês, 500 tokens de entrada e 300 de saída cada — em quatro modelos:
| Modelo | Custo estimado/mês |
|---|---|
| Amazon Nova Micro | ~US$ 59,50 |
| Claude Haiku 4.5 | ~US$ 2.000 |
| Claude Sonnet 5 (std) | ~US$ 6.000 |
| Claude Opus 4.8 | ~US$ 10.000 |
O output é o lado caro — controle-o
Repare que a conta acima usa 300 tokens de saída. Como o output custa 4–5× o input em Claude e Nova, cada token gerado a mais empurra a fatura para cima muito mais rápido que um prompt maior. Limite max_tokens, peça respostas concisas e prefira formatos estruturados enxutos. Números de referência — confirme em aws.amazon.com/bedrock/pricing, que muda e varia por região.
📋 Preciso classificar 1 milhão de tickets de suporte por mês (saída curta: uma categoria). Latência não é crítica.
Saída curtíssima e tarefa simples de classificação não precisam de um modelo de fronteira. Nova Micro sai por ~US$ 60/mês on-demand contra ~US$ 10.000 do Opus para a mesma carga — e o Batch ainda corta ~50%.
Alt: Claude Haiku 4.5 — ~US$ 2.000/mês: melhor raciocínio, mas overkill para rotular uma categoria — cerca de 30× o custo do Nova Micro.
Alt: Claude Sonnet 5 — ~US$ 6.000/mês: reserve para tarefas que exigem raciocínio real, não classificação trivial.
Onde o custo vaza na prática
Na prática, quase toda fatura inflada do Bedrock cai em um destes seis buracos. Vale como checklist antes de subir para produção:
- System prompt gigante repetido a cada request sem prompt caching — a fatura infla no prefixo, não na pergunta.
- max_tokens alto demais: o modelo enche a resposta e você paga output a 4–5× o input.
- Modelo de fronteira (Opus) para tarefa trivial — 100–170× mais caro que um Nova/Haiku que resolveria igual.
- Provisioned Throughput comprado 'por garantia' e ocioso — MU parada é dinheiro queimado; só compensa se satura ~24/7.
- Contexto RAG mal filtrado: enfiar 50 chunks quando 5 bastam multiplica tokens_in em toda chamada.
- Ignorar o Batch em cargas offline que topam esperar horas — deixa ~50% de desconto na mesa.
Seu app usa prompt caching, mas cacheReadInputTokens vem sempre 0 em requests repetidos. Qual é o suspeito número um?
No Claude e no Nova, por que controlar o tamanho da resposta (max_tokens) impacta a fatura mais do que encurtar o prompt de entrada?
Próximo passo
Você já sabe COMO o Bedrock cobra e onde o dinheiro vaza. O passo seguinte é transformar isso em disciplina: alocar custo por tag, medir custo por request, definir budgets e alertas, e provar o retorno de cada modelo. É o próximo módulo — FinOps e ROI: controlar custo e provar retorno.
Perguntas frequentes
❓ Como o Bedrock cobra exatamente?
❓ Capacidade provisionada compensa?
❓ Por que a minha conta veio maior do que eu estimei?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…