Escopo do projeto
Inventário das aplicações que chamam modelos (assistentes, agentes, extração, resumo) e de quem paga por cada uma. Perfis de inferência de aplicação (application inference profiles) do Amazon Bedrock com tags de alocação por aplicação, time e ambiente, para que o custo apareça separado no AWS Cost Explorer.
Kill-switch de custo: contador de gasto diário e mensal no Amazon DynamoDB, lido pela função AWS Lambda antes de cada invocação; ao atingir o teto, a aplicação responde com mensagem controlada e o modelo fica de fora da chamada. Orçamento no AWS Budgets por tag, monitor do AWS Cost Anomaly Detection por tag de aplicação, com o monitor de serviços da AWS avaliando o Bedrock separadamente, alarmes do Amazon CloudWatch sobre tokens de entrada e saída. Limite de turnos de ferramenta em agentes para evitar loop.
Cache de prompt e escolha de modelo por tarefa (modelo menor para classificação e respostas curtas, modelo maior só onde a qualidade exige). Registro de invocações (model invocation logging) para auditoria e para calcular custo por conversa. Termina com o relatório mensal de custo por aplicação e por modelo e os itens de IA na rotina.
Desafio e problemas de hoje
- O piloto de IA foi aprovado com um custo estimado e ninguém sabe se a estimativa se confirmou.
- O gasto com Bedrock aparece como uma linha só; separar o assistente de atendimento da extração de documentos ainda é impossível.
- Falta um teto: se a aplicação for abusada ou entrar em loop, o gasto só aparece na fatura.
- O modelo mais caro é usado para tudo, inclusive para tarefas simples.
- O financeiro pergunta "quanto custa cada conversa?" e a TI ainda procura o número.
O ambiente de partida (perfil típico deste exemplo)
| Item | O que costuma existir |
|---|---|
| Aplicações | De 1 a 4 aplicações chamando o Amazon Bedrock (assistente no site, resumo de documentos, agente interno), em piloto ou produção |
| Modelos | Um modelo para tudo, escolhido na demonstração; cache de prompt ainda por ativar |
| Controle de gasto | Nenhum teto; alerta de orçamento genérico ou inexistente |
| Alocação | Nenhum perfil de inferência por aplicação; nenhuma tag; custo do Bedrock numa linha só |
| Observabilidade | Métricas de tokens e registro de invocações ainda por ativar |
| Restrições | Time pequeno; pressão para lançar; receio de que o controle degrade a experiência |
Perfil típico, com faixas. O retrato real da sua conta é o primeiro entregável do diagnóstico FinOps.
Requisitos
- R1Teto de gasto diário e mensal aplicado antes da chamada ao modelo.
- R2Custo separado por aplicação, time e modelo, visível no faturamento.
- R3Alerta de orçamento e de anomalia específicos para o gasto com IA, com dono.
- R4Proteção contra loop de agente e contra abuso por volume.
- R5Modelo e cache escolhidos pelo custo da tarefa, mantendo a qualidade onde ela importa.
- R6Custo por conversa (ou por documento processado) calculável todo mês.
O que desenhamos para cada requisito
| Requisito | Decisão de arquitetura | Serviço AWS |
|---|---|---|
| R1 | Contador atômico de gasto por dia e por mês no DynamoDB; a Lambda lê o contador antes de invocar; ao atingir o teto responde mensagem controlada e preserva o orçamento; soma o custo da resposta após a invocação | AWS Lambda, Amazon DynamoDB, Amazon Bedrock |
| R2 | Perfis de inferência de aplicação com tags de alocação (aplicação, time, ambiente); tags ativadas no faturamento; Cost Categories para IA | Amazon Bedrock (application inference profiles), AWS Cost Explorer, AWS Cost Categories |
| R3 | Orçamento por tag de aplicação; monitor de anomalia por tag de aplicação (e o monitor de serviços da AWS cobrindo o Bedrock); alarmes do CloudWatch sobre tokens; notificação ao dono | AWS Budgets, AWS Cost Anomaly Detection, Amazon CloudWatch, Amazon SNS |
| R4 | Limite de turnos de ferramenta por conversa; limite de tamanho de entrada; limitação de taxa no Amazon API Gateway e quota por origem na própria aplicação (contador no Amazon DynamoDB); o teto de custo como última barreira | Amazon API Gateway, AWS Lambda, Amazon DynamoDB |
| R5 | Modelo menor para classificação, roteamento e respostas curtas; modelo maior só nas etapas que exigem; cache de prompt para o prefixo estável (persona, conhecimento, regras) | Amazon Bedrock (cache de prompt, escolha de modelo) |
| R6 | Registro de invocações com tokens por chamada; consulta mensal de custo por aplicação dividido pelo número de conversas | Amazon Bedrock (model invocation logging), Amazon S3 ou Amazon CloudWatch Logs, Amazon Athena |
Arquitetura
Componentes e fluxos deste diagrama
- Nuvem AWS, conta do cliente: Amazon API Gateway (limite de taxa), AWS Lambda (teto antes da chamada), Amazon DynamoDB (gasto do dia e do mês), Amazon Bedrock (perfil de inferência por aplicação), Amazon CloudWatch (tokens e alarmes), AWS Budgets (por tag), AWS Cost Explorer e Cost Anomaly Detection.
- Usuário para Amazon API Gateway; Amazon API Gateway para AWS Lambda.
- AWS Lambda para Amazon DynamoDB: lê e soma o gasto.
- AWS Lambda para Amazon Bedrock: só abaixo do teto.
- Amazon Bedrock para Amazon CloudWatch, tracejado: métricas.
- Amazon Bedrock para AWS Cost Explorer, tracejado: custo por tag.
- AWS Budgets e AWS Cost Explorer para a Equipe RFX: alertas e custo por aplicação.
- Fora da conta do cliente: Usuário e Equipe RFX.
Ganhos: o que medimos no projeto
| Indicador | Como medimos | O que muda |
|---|---|---|
| Custo mensal de IA por aplicação e por modelo | AWS Cost Explorer por tag do perfil de inferência | De uma linha só para custo por aplicação e por modelo |
| Custo por conversa ou por documento | Custo da aplicação no mês dividido pelo número de conversas ou documentos (registro de invocações) | De estimativa do piloto para número medido todo mês |
| Dias em que o teto foi atingido e chamadas bloqueadas | Métrica do kill-switch (contador no DynamoDB e logs da Lambda) | Teto visível; se bloquear com frequência, a decisão é subir o teto ou reduzir o custo por chamada, com dados |
| Tokens de entrada e saída por dia e taxa de leitura do cache | Métricas do Amazon CloudWatch e uso retornado pelo Bedrock | De desconhecido para acompanhado; cache medido |
| Anomalias e alertas de orçamento tratados | Cost Anomaly Detection e Budgets com resposta registrada | De surpresa na fatura para aviso no dia |
Indicadores de um projeto típico, medidos no próprio projeto: resultado típico, não garantia.
Escopo e entregáveis por fase
| Fase | O que acontece | Entregáveis | Duração |
|---|---|---|---|
| 1. Inventário | Aplicações, modelos, volumes, donos; leitura do custo atual do Bedrock | Mapa das aplicações de IA com custo atual e dono | Semana 1 |
| 2. Alocação e teto | Perfis de inferência com tags, kill-switch na aplicação, limites de turno e de taxa | Custo separado por aplicação; teto operando | Semanas 2 e 3 |
| 3. Controle e otimização | Orçamento, anomalia, alarmes de token, cache de prompt, revisão de modelo por tarefa | Alertas com dono; custo por chamada revisado | Semanas 4 e 5 |
| 4. Relatório e rotina | Registro de invocações, consulta de custo por conversa, entrega da rotina ao time do cliente | Relatório de custo por aplicação e por conversa; itens de IA na rotina | Semana 6 |
Durações típicas, em faixa. O plano do projeto fixa as datas reais.
Algo a mais: confira no assistente deste site
Teto, cache e orçamento já em operação
O assistente deste site opera com teto de gasto diário e mensal, aplicado antes de cada chamada ao modelo, com cache de prompt, limite de turnos e orçamento no AWS Budgets por tag de centro de custo, na conta da RFX. É o núcleo do desenho que entregamos na sua conta, que ganha ainda perfil de inferência por aplicação, monitor de anomalia e registro de invocações.
O AWS FinOps Agent, em preview em 07/10/2026, poderá responder "por que o gasto com IA subiu?" em linguagem natural; ele depende dos mesmos dados, tags e controles deste exemplo.
Perguntas frequentes deste exemplo
O teto é dimensionado com folga sobre o uso medido e tem alerta antes de ser atingido. Quando chega ao limite, a aplicação responde com mensagem controlada em vez de gerar fatura inesperada. Se isso acontecer, a decisão de subir o teto é tomada com dados, no mesmo dia.
Sim. Com perfil de inferência por aplicação e registro de invocações, o custo do mês dividido pelo número de conversas é um número medido.
Depende da tarefa. Classificar, rotear e responder perguntas curtas costuma funcionar bem em modelos menores; a decisão é testada por tarefa, com amostras, antes de mudar. Onde a qualidade exige, o modelo maior fica.
Vale e é mais importante: agente chama ferramentas em sequência e pode entrar em loop. Limite de turnos, limite de taxa e teto de custo são as três barreiras, nessa ordem.
Serviços AWS deste exemplo
- Amazon Bedrock
- AWS Lambda
- Amazon DynamoDB
- Amazon API Gateway
- AWS Budgets
- AWS Cost Anomaly Detection
- Amazon CloudWatch
- Amazon SNS
- AWS Cost Explorer
- AWS Cost Categories
- Amazon Athena
- Amazon S3
Incentivos AWS
A RFX busca para o projeto os programas de incentivo e créditos da AWS aplicáveis, sempre sujeitos a aprovação da AWS. Verbas de PoC fazem parte do pacote padrão da distribuição; os demais benefícios são avaliados por cliente e sujeitos a aprovação da AWS e da distribuição.