FinOps e ROI: controlar custo e provar retorno
- ⬜💰 Preços e cobrança: como o Bedrock cobra de você(AWS Bedrock — GenAI em Produção)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Toda conta de Bedrock que assusta tem a mesma raiz: o time mediu tarde e não conseguia dizer quem gastou o quê. FinOps aqui não é planilha no fim do mês — é instrumentar o custo por app/squad no dia 1, provar ROI com uma fórmula, e conhecer os poucos erros que multiplicam a fatura por 10. Os preços citados aqui são de meados de 2026; confirme os números atuais no pricing da AWS antes de fechar qualquer conta. A ordem de grandeza, essa, não muda.
Medir e controlar: as ferramentas que a AWS te dá
Não dá para controlar o que você não mede, e não dá para fazer chargeback do que você não consegue atribuir. Existem seis ferramentas nativas — cada uma resolve uma parte do problema, e a combinação delas te dá visibilidade por request, por modelo e por squad.
Application Inference Profiles = chargeback por squad
Este é o mecanismo canônico para atribuir custo por app/time no Bedrock. Crie um inference profile por squad/feature, aplique cost allocation tags nele, e roteie as invocações daquele time pelo ARN do profile (ele entra no lugar do modelId). No Cost Explorer, ative a tag e o gasto se quebra por squad — sem contas AWS separadas, sem planilha manual, sem heurística de rateio.
import boto3
bedrock = boto3.client("bedrock")
# 1) Um inference profile por squad/app/feature — a chave do chargeback.
resp = bedrock.create_inference_profile(
inferenceProfileName="squad-checkout-nova-lite",
description="Invocacoes de LLM do time de Checkout",
modelSource={
# copia de um system-defined inference profile (modelo + regiao)
"copyFrom": "arn:aws:bedrock:us-east-1:123456789012:"
"inference-profile/us.amazon.nova-lite-v1:0"
},
tags=[
{"key": "squad", "value": "checkout"},
{"key": "cost-center", "value": "cc-4021"},
{"key": "env", "value": "prod"},
],
)
profile_arn = resp["inferenceProfileArn"]
# 2) Toda invocacao desse time passa o profile ARN como modelId:
rt = boto3.client("bedrock-runtime")
rt.converse(
modelId=profile_arn,
messages=[{"role": "user", "content": [{"text": "Resuma este pedido."}]}],
)
# 3) No Cost Explorer, ative a cost allocation tag "squad" e filtre por
# squad=checkout -> custo atribuido, sem rateio manual.Ligue um Budget no dia 1
Um AWS Budget mensal no serviço Bedrock com alertas em 50/80/100% é a rede de segurança mais barata que existe. É ele que te avisa da OCU idle e do contexto que inchou ANTES de o mês fechar. Sem budget, o primeiro sinal de que algo deu errado é a fatura — tarde demais para agir.
- → cada app invoca pelo SEU profile
- → a etiqueta é o que separa o custo por squad
- → cruzar com métrica de negócio
- Compute
- IA e machine learning
- Gestão e governança
- Fora da AWS
Tudo nesta figura existe para responder uma pergunta: quanto o time de crédito gastou mês passado? Sem o inference profile etiquetado no passo 1, a fatura é uma linha só e nenhuma das outras caixas ajuda.
- Um profile por app — o passo que não retroage. Etiqueta criada hoje não separa o gasto de ontem. Se este passo não existir no dia 1, os meses anteriores ficam indivisíveis para sempre.
- O custo chega separado. O relatório de custo filtra pela etiqueta e entrega o gasto por squad, sem nenhuma contabilidade caseira.
- Métrica técnica ao lado da financeira. Tokens, razão de cache e latência por app. É o que explica POR QUE o custo mudou — a fatura só diz que mudou.
- Controle preventivo e detectivo. Orçamento com ação é a rede de segurança; a detecção de variação diária é o que pega o laço descontrolado enquanto ainda dá para interromper.
- A métrica que vai ao comitê. Custo por resultado de negócio: por ticket resolvido, documento processado, funcionário ativo. É a única unidade comparável com o processo anterior.
A fórmula do custo por request
Controlar custo sem entender de onde ele vem é chutar no escuro. O custo de uma request de LLM tem uma fórmula simples e previsível — e é ela que diz exatamente onde caçar economia. Sem cache, você paga entrada e saída cheias em todo request:
Prompt caching: a alavanca de ~90%
Se o mesmo system prompt + docs se repetem em todo request, o prompt caching guarda esse prefixo e cobra o cache read a ~10% do preço de entrada. Em RAG com contexto grande e estável, é a diferença entre pagar o contexto UMA vez ou milhares de vezes. Confirme os preços de cache write/read no pricing — o cache write cobra um pouco mais no primeiro request, e paga-se sozinho já no segundo hit.
Bedrock vs API direta vs self-hosted
A pergunta que todo diretor faz é: não sai mais barato hospedar o modelo a gente mesmo? A resposta honesta é uma tabela de trade-offs — e um número de sanity check que costuma encerrar a discussão.
| Opção | Ganha quando | Perde quando |
|---|---|---|
| Bedrock on-demand | Volume variável; precisa de governança AWS (IAM/VPC/KMS); quer trocar de modelo sem reescrever; quer zero ops e um bill único. | Você precisa do recurso do provedor no dia do lançamento, ou tem volume gigante e constante de um único modelo aberto. |
| API direta do provedor | Quer o recurso mais novo no dia 0; prototipagem rápida fora da AWS; não precisa de VPC/PrivateLink. | Precisa de rede privada, KMS, trilha de auditoria unificada e um único bill AWS — governança que o Bedrock já entrega. |
| Self-hosted (EC2 GPU) | Volume ENORME e 24/7 de um modelo aberto, com time de MLOps para manter a GPU saturada. | Volume variável ou baixo/médio: a GPU ociosa te cobra US$/hora independente de uso, e o TCO estoura. |
Sanity check: a g5.12xlarge custa US$4.140/mês parada
Uma g5.12xlarge (4× A10G) on-demand custa ~US$5,67/hora ≈ US$4.140/mês rodando 24/7 — e ela te cobra isso INDEPENDENTE de você mandar 1 ou 1 milhão de requests. Para bater os ~US$102/mês que um Nova Lite gastaria no mesmo tráfego, self-hosting só fecha a conta com throughput altíssimo e sustentado. Confirme os preços atuais no pricing da EC2/Bedrock — mas a ordem de grandeza é essa: capacidade fixa vs. custo proporcional ao uso.
Traduzindo para a realidade de um time BR: a menos que você tenha tráfego de big tech e um time de MLOps dedicado, Bedrock on-demand com Nova ou Haiku ganha em custo TOTAL — porque o custo total inclui as horas de engenharia que você NÃO gasta operando GPU, fazendo upgrade de modelo e ficando de on-call às 3 da manhã. Zero ops é uma linha de custo real, só que ela não aparece na fatura da EC2.
Você precisa fazer chargeback do custo do Bedrock por squad — cada time paga o que gastou. O Cost Explorer filtrado por 'Amazon Bedrock' mostra o total, mas não separa por time. Qual é o mecanismo canônico para atribuir custo por app/squad?
Os 8 erros que explodem a conta
Quase toda fatura de Bedrock que assusta cai em um destes oito padrões. Conheça todos — o primeiro, sozinho, já pagou o custo de ler este módulo.
O erro #1: OpenSearch Serverless OCU idle
Uma Knowledge Base cria uma coleção do OpenSearch Serverless que cobra OCUs (OpenSearch Compute Units) 24/7 — na faixa de ~US$350–700/mês MESMO sem nenhuma query. E aqui está a pegadinha que estoura orçamento: deletar a Knowledge Base NÃO deleta a coleção. A OCU continua rodando (e cobrando) até você apagar a coleção manualmente no console do OpenSearch. Audite coleções órfãs primeiro, antes de qualquer outra otimização. Confirme os valores atuais no pricing.
As duas alavancas grátis
Antes de qualquer otimização heroica: (1) ligue prompt caching no contexto repetido e (2) mande toda carga não-interativa pelo Batch (50% off). Duas configurações, zero refatoração de arquitetura, e juntas cortam boa parte da conta. Só depois disso vale investir em rightsizing de modelo e engenharia de prompt.
📋 Tenho um LLM em produção e quero saber se vale a pena parar de pagar Bedrock on-demand e hospedar o modelo eu mesmo numa GPU para economizar.
Self-host só vira ROI positivo com volume na casa de milhões de requests/dia, constante e 24/7, mais um time de MLOps para saturar a GPU. Uma g5.12xlarge sozinha já é ~US$4.140/mês fixos, independentemente do uso — você precisa de tráfego brutal e estável para diluir esse custo abaixo do on-demand. Some o custo humano (ops, on-call, upgrades de modelo, segurança) e o break-even sobe ainda mais.
Alt: Provisioned Throughput no Bedrock — Meio-termo: capacidade dedicada sem operar GPU, mas só ganha se você saturar a model unit quase 24/7 — senão são ~US$15k/mês parados.
Alt: Self-host em EC2 GPU — Só fecha com volume ENORME e constante + time de MLOps. Abaixo disso, a GPU ociosa cobra por hora e o custo total (TCO) estoura.
Qual é o erro que mais comumente explode a conta de Bedrock de forma silenciosa — inclusive continuando a cobrar depois que o recurso 'foi deletado'?
Em que cenário self-hosting um modelo aberto em EC2 GPU realmente ganha do Bedrock on-demand em custo total?
Próximo passo
Você já sabe medir, controlar e provar ROI. O fechamento da trilha é ver tudo isso junto em sistemas reais — Arquiteturas de referência e cases reais: RAG em produção, agentes com guardrails, e as decisões de custo por trás de cada uma.
Perguntas frequentes
❓ Como medir o custo por requisição?
❓ Como atribuir custo de IA por aplicação?
❓ Como provar retorno de um projeto de IA?
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…