Custo de IA generativa na AWS: como estimar, alocar e limitar o gasto de inferência no próprio código

O custo de IA generativa na AWS é a soma dos tokens de entrada e de saída de cada chamada, multiplicados pelo preço do modelo e pelo volume de chamadas. Para governar esse custo, defina uma unidade de negócio (documento, conversa, tarefa), meça os tokens reais que a API devolve, aloque o gasto por aplicação com application inference profiles e imponha o orçamento no código, antes de chamar o modelo. Alertas de fatura informam o que já aconteceu; o limite no código impede que aconteça.

A fatura do fim do mês responde quanto saiu. Ela não responde quanto custa processar um documento, qual aplicação causou o pico de terça-feira ou qual cliente consome muito acima da média. Essas perguntas são de unit economics, uma das capacidades do FinOps Framework da FinOps Foundation, e é nesse nível que a IA generativa precisa ser tratada desde o primeiro deploy.

O roteiro abaixo vale para aplicações que chamam modelos pelo Amazon Bedrock: como a AWS cobra, como chegar ao custo por unidade, como separar o gasto por aplicação, como travar o consumo no código e quais alavancas de otimização trazem qual risco. No fim, o mesmo raciocínio aplicado ao custo da IA que o time usa para desenvolver.

Como o Amazon Bedrock cobra a inferência

A página de preços do Amazon Bedrock organiza a cobrança de inferência em quatro modalidades que importam para FinOps:

• Sob demanda: cobrança por token de entrada e por token de saída, com preço diferente por modelo e por Região. É o ponto de partida de quase toda aplicação. Dentro dela há camadas de serviço: Standard (padrão), Priority (resposta mais rápida, com preço 75% acima do Standard) e Flex (processamento mais lento, com preço 50% abaixo do Standard), percentuais informados na página de preços.
• Inferência em lote: você grava as entradas em arquivos no Amazon S3, envia um job e recebe as saídas no S3, de forma assíncrona (documentação de batch inference). Para os modelos que oferecem a modalidade, a página de preços indica preço 50% menor que o sob demanda.
• Provisioned Throughput: capacidade dedicada cobrada por unidade de modelo por hora, sob demanda ou com compromisso de 1 ou 6 meses, segundo a página de preços. A documentação de camadas de serviço descreve ainda a camada Reserved, com capacidade reservada em tokens por minuto por 1 ou 3 meses e mínimo de 100.000 tokens de entrada e 10.000 de saída por minuto.
• Prompt caching: conforme a documentação de prompt caching, tokens lidos do cache são cobrados na taxa de leitura de cache do modelo, tokens fora do cache na taxa padrão de entrada e, dependendo do modelo, a escrita no cache pode custar mais que a entrada padrão. Nos modelos GPT-5.6 e posteriores, por exemplo, a mesma página informa escrita a 1,25 vez a taxa de entrada sem cache.

Para tornar isso concreto, a tabela traz dois modelos da família Amazon Nova, nas modalidades sob demanda (Standard) e em lote.

Dados atualizados em 15/10/2026: valores da Região us-east-1, em dólar, revisados na atualização deste artigo a partir do arquivo de oferta do Amazon Bedrock da AWS Price List API (versão de 14/10/2026); confira também a página de preços do Amazon Bedrock. A AWS publica os valores por 1.000 tokens; a tabela converte para 1 milhão. Preço de modelo muda: confira antes de usar.

Duas leituras saltam da tabela. A primeira: no Amazon Nova 2 Lite, o token de saída custa cerca de 8,3 vezes o de entrada (US$ 2,75 contra US$ 0,33), então o tamanho da resposta pesa mais na conta do que o tamanho da pergunta. A segunda: nesses dois modelos a escrita de cache aparece a US$ 0,00, enquanto em outras famílias ela pode custar mais que a entrada. A regra de cache é por modelo, nunca geral.

A conta por unidade: custo por documento e por conversa

Custo unitário é o custo de todas as chamadas que produzem uma unidade de valor, dividido por essa unidade. A fórmula, com os campos que a Converse API devolve em usage:

# preços em US$ por 1 milhão de tokens, do modelo e da Região usados
custo_chamada = ( inputTokens           x preço_entrada
                + cacheReadInputTokens  x preço_leitura_cache
                + cacheWriteInputTokens x preço_escrita_cache
                + outputTokens          x preço_saída ) / 1.000.000

custo_unidade = soma de custo_chamada de todas as chamadas da unidade
                (tentativas repetidas, validações e passos de agente incluídos)

custo_mensal  = custo_unidade x volume + custos fora do modelo

Um detalhe da documentação de prompt caching muda a conta: com cache ativo, inputTokens traz só os tokens que não foram lidos nem escritos no cache. O total de entrada enviado é inputTokens + cacheReadInputTokens + cacheWriteInputTokens. Quem soma só inputTokens subestima o volume e superestima o ganho do cache.

Meça na própria chamada e grave junto da unidade de negócio:

// Node.js 22, AWS SDK for JavaScript v3
const { usage, stopReason } = await bedrock.send(new ConverseCommand(parametros));

const entradaTotal = usage.inputTokens
  + (usage.cacheReadInputTokens ?? 0)
  + (usage.cacheWriteInputTokens ?? 0);   // fórmula da documentação de prompt caching

registrarUnidade({
  unidade: "documento", idUnidade, aplicacao: "resumo-documentos",
  entradaTotal, cacheLido: usage.cacheReadInputTokens ?? 0,
  saida: usage.outputTokens, stopReason   // "max_tokens" indica resposta cortada
});

O stopReason merece alarme próprio. Quando ele volta como max_tokens, a resposta foi cortada pelo limite de saída, e resposta cortada costuma virar nova tentativa, que dobra o custo daquela unidade sem aparecer como erro. Para estimar a entrada antes da chamada, a API CountTokens devolve a contagem que seria cobrada, sem custo, nos modelos que a suportam.

Em conversa, a unidade se comporta diferente. Cada turno reenvia o histórico, então a entrada do turno 10 carrega os nove anteriores e o custo da conversa cresce mais rápido que o número de turnos. Duas consequências práticas: o custo por conversa precisa de teto de turnos ou de janela de histórico, e o prefixo estável (instruções e ferramentas) é o candidato natural a prompt caching.

Exemplo resolvido: documento de 5 páginas, 500 por mês

As contagens de token abaixo são premissas declaradas do exemplo, não medição: a contagem real depende do tokenizador do modelo e do conteúdo, e deve ser substituída pelos valores de usage das primeiras chamadas do seu caso.

• Unidade: um documento de 5 páginas resumido, com campos extraídos em JSON.
• Premissas por documento: 1.500 tokens de instruções fixas, 3.500 tokens do conteúdo do documento e 500 tokens de resposta.
• Volume: 500 documentos por mês.
• Modelo e preço: Amazon Nova 2 Lite, us-east-1, valores da tabela anterior.
• Câmbio (dado da atualização de 15/10/2026): PTAX de venda de 14/10/2026, R$ 5,0441 por dólar, do Banco Central do Brasil.

Como ler o resultado. O cenário B supõe que toda chamada encontre o prefixo no cache, e essa é a premissa mais frágil da tabela. A documentação de prompt caching dá ao Amazon Nova 2 Lite um cache com TTL de 5 minutos, renovado a cada acerto, e checkpoint mínimo de 1K tokens. As 1.500 instruções passam do mínimo, mas o cache só se paga quando as chamadas chegam em rajada, com menos de 5 minutos entre uma e outra. Com 500 documentos por mês espalhados ao longo dos dias, perto de 16 por dia, o cache expira entre as chamadas na maior parte das vezes e o resultado real fica perto do cenário A. O cenário B é o teto do ganho, não a estimativa; a decisão de usar cache vem da medição de cacheReadInputTokens nas primeiras semanas, e a documentação lembra que acerto de cache nunca é garantido. O cenário C só serve a trabalho que tolera resposta assíncrona, e a documentação registra que prompt caching não funciona com a API de lote, então cache e lote não se somam. Preços e câmbio do exemplo foram revisados na atualização de 15/10/2026; refaça a conta com a tabela e o câmbio do dia antes de usar.

O ponto mais importante: a linha do modelo raramente é o que muda a ordem de grandeza da conta. O que muda é o número de chamadas por unidade (tentativas, validações, passos de um agente), o tamanho da resposta, a troca para um modelo maior e o crescimento de contexto em conversas. Some ainda os custos fora do modelo: AWS Lambda, logs de invocação, embeddings e vector store quando houver RAG, e, na conversão para real, o câmbio do dia e os tributos da fatura. Sobre a exposição ao dólar, vale ler o post sobre pagar a AWS em reais pelo parceiro de distribuição; para o restante da arquitetura, a calculadora AWS da RFX e a tabela de preços da AWS em São Paulo.

Um cuidado de FinOps com créditos promocionais: calcule o custo unitário sobre o preço de lista, não sobre o valor faturado depois dos créditos. No esquema FOCUS isso é a diferença entre ListCost e BilledCost. Crédito reduz a fatura por um período, não o custo da unidade; quando ele acaba, o custo real já precisa estar no orçamento. Os caminhos de apoio da AWS para quem está começando estão no post sobre apoio da AWS para cloud e IA.

Alocação por aplicação: showback com application inference profiles

Sem alocação, todo o gasto de inferência cai numa linha só do Amazon Bedrock. O mecanismo da AWS para separar é o application inference profile, com suporte a tags de alocação de custo anunciado em novembro de 2024. O perfil é um recurso que referencia um modelo específico; você aplica as tags no perfil e usa o ARN dele no lugar do model ID nas chamadas de InvokeModel e Converse. As tags seguem para o Cost Explorer e para o CUR, clássico e 2.0.

# 1. Perfil de inferência da aplicação, já com as tags de alocação
#    MODELO_ARN: ARN do modelo de base (uma Região) ou de um perfil entre Regiões
aws bedrock create-inference-profile \
  --inference-profile-name resumo-documentos-prod \
  --model-source copyFrom="$MODELO_ARN" \
  --tags key=aplicacao,value=resumo-documentos \
         key=centro-de-custo,value=operacoes \
         key=ambiente,value=prod

# A resposta traz o inferenceProfileArn: é ele que vai no modelId

# 2. Ativar as chaves como tags de alocação de custo (Billing and Cost Management)
aws ce update-cost-allocation-tags-status \
  --cost-allocation-tags-status TagKey=aplicacao,Status=Active \
                                TagKey=centro-de-custo,Status=Active

Três regras da documentação que definem o desenho:

• Ativação não é retroativa. Só o custo incorrido depois da ativação recebe a tag, e ela pode levar até 24 horas para aparecer no Cost Explorer e no CUR. Ative no dia em que criar o perfil, junto com o deploy da aplicação.
• A granularidade é agregada. O perfil entrega custo por tipo de uso por dia, não por chamada. Para detalhe por chamada, use o campo requestMetadata da Converse API com os logs de invocação: o custo sai dos tokens multiplicados por uma tabela de preço que você mantém, e é reconciliado com o CUR no nível de modelo e tipo de uso. Esses metadados não viram tag de custo, e a AWS recomenda não colocar dado pessoal neles.
• Um perfil por combinação de modelo e conjunto de tags. Trocar de modelo exige perfil novo, então a quantidade cresce rápido. A documentação recomenda taguear por time ou centro de custo, não por usuário, e aponta a atribuição por principal IAM para custo por identidade. Para as APIs Responses e Chat Completions no endpoint bedrock-mantle, o mecanismo indicado é Projects, porque essas APIs rejeitam perfis de aplicação.

Alocação só é confiável quando ninguém consegue escapar dela. A documentação de pré-requisitos de inference profiles mostra como restringir o modelo para que só seja invocado através do perfil, com a chave de condição bedrock:InferenceProfileArn:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SomentePeloPerfilDaAplicacao",
      "Effect": "Allow",
      "Action": "bedrock:InvokeModel",
      "Resource": "arn:aws:bedrock:us-east-1:111122223333:application-inference-profile/exemplo123"
    },
    {
      "Sid": "ModeloApenasViaPerfil",
      "Effect": "Allow",
      "Action": "bedrock:InvokeModel",
      "Resource": "arn:aws:bedrock:us-east-1::foundation-model/amazon.nova-2-lite-v1:0",
      "Condition": {
        "StringEquals": {
          "bedrock:InferenceProfileArn": "arn:aws:bedrock:us-east-1:111122223333:application-inference-profile/exemplo123"
        }
      }
    }
  ]
}

Com essa política na role da função, chamada sem perfil é negada, e todo token gasto por aquela aplicação chega tagueado. Se o perfil apontar para um perfil entre Regiões, a documentação exige listar o modelo em cada Região associada.

Com o gasto separado, vale usar os termos no sentido correto. Showback é mostrar a cada time ou produto quanto ele consumiu, sem cobrança interna; é o primeiro passo e cria responsabilidade sobre o próprio gasto. Chargeback é debitar o valor do orçamento de quem consumiu; exige tagueamento confiável e regra de rateio para custos compartilhados. Em IA generativa, comece por showback por aplicação, como detalhado no post sobre FinOps na AWS.

O padrão de dados também evoluiu. A AWS disponibilizou em novembro de 2025 o export no esquema FOCUS 1.2, versão da especificação que estende o esquema a cenários de SaaS e PaaS, com suporte a moedas virtuais (créditos e tokens de plataforma) e conciliação com a fatura. Isso importa para IA porque parte do gasto chega como créditos de ferramenta, e o FOCUS 1.2 permite colocar esses créditos no mesmo esquema do consumo de nuvem. A FinOps Foundation publicou a versão 1.3 em dezembro de 2025, com colunas para rateio de custos compartilhados e um conjunto de dados de compromissos contratuais. Um detalhe de faturamento: modelos de terceiros no Amazon Bedrock aparecem na fatura sob a entidade de cobrança AWS Marketplace, segundo a documentação do Cost Anomaly Detection. Filtros e relatórios precisam incluí-la.

Limites no código: orçamento antes da chamada

O controle que de fato impede o gasto mora entre a solicitação do usuário e a chamada ao modelo. O padrão é em camadas, ordenadas do portão mais barato ao mais caro, para que nenhum token seja gasto antes de todos os portões passarem:

1. Limite de saída por integração. Cada funcionalidade tem seu maxTokens, definido no servidor. Ele é o teto de custo de saída por chamada. Há um efeito colateral pouco lembrado: a cota de tokens por minuto reserva entrada mais max_tokens no início da chamada, segundo a documentação de métricas, então um teto folgado demais consome cota sem consumir dinheiro.
2. Limite de entrada. Truncar, resumir ou recusar entrada acima do tamanho previsto; em conversa, janela de histórico ou resumo dos turnos antigos.
3. Contador atômico por período e por tenant. Antes da chamada, reserva-se o custo estimado no pior caso; depois, ajusta-se pelo custo real lido em usage.
4. Kill-switch. Uma flag global lida antes da chamada, com cache curto em memória, que um operador ou um alarme pode virar. É ela que transforma alerta em limite.
5. Quota por cliente e teto físico. O plano de cada cliente define a quota do contador; a concorrência reservada da função AWS Lambda limita quantas chamadas acontecem ao mesmo tempo.

// Portões em ordem de custo: nenhum token é gasto antes do último
export async function handler(evento) {
  const tenant = await autenticar(evento);                // quem responde pelo gasto
  if (await killSwitchAtivo()) return indisponivel();     // flag com cache curto

  const texto = limitarEntrada(evento.texto, LIMITE_ENTRADA);   // trunca ou resume
  const estimativa = piorCasoEmMicrodolares(texto, MAX_SAIDA, PRECOS);

  const reservou = await reservarOrcamento(tenant.id, periodoAtual(), estimativa, tenant.quota);
  if (!reservou) return quotaEsgotada(tenant);            // 429 com mensagem clara

  let resposta;
  try {
    resposta = await bedrock.send(new ConverseCommand({
      modelId: PERFIL_DA_APLICACAO_ARN,                   // nunca vem do cliente
      system: [{ text: INSTRUCOES_FIXAS }, { cachePoint: { type: "default" } }],
      messages: [{ role: "user", content: [{ text: texto }] }],
      inferenceConfig: { maxTokens: MAX_SAIDA },
      requestMetadata: { tenant: tenant.id, funcionalidade: "resumo-documento" }
    }));
  } catch (erro) {
    if (RECUSADA_PELO_SERVICO.has(erro.name)) {           // ex.: ThrottlingException, ValidationException
      await ajustarOrcamento(tenant.id, periodoAtual(), -estimativa);   // devolve a reserva inteira
    }                                                     // timeout: a reserva fica, o modelo pode ter processado
    throw erro;
  }

  const real = custoEmMicrodolares(resposta.usage, PRECOS);
  await ajustarOrcamento(tenant.id, periodoAtual(), real - estimativa);   // devolve a sobra
  registrarUnidade({ tenant: tenant.id, custo: real, usage: resposta.usage,
                     stopReason: resposta.stopReason });
  return resposta.output;
}

A reserva no Amazon DynamoDB usa uma atualização condicional, que é atômica por item. Como a expressão de condição compara valores mas não faz soma, o teto chega pronto, já descontada a estimativa. Valores em microdólares inteiros evitam erro de arredondamento:

// Reserva atômica: só soma se o gasto do período continuar dentro da quota
export async function reservarOrcamento(tenantId, periodo, estimativa, quota) {
  if (estimativa > quota) return false;
  try {
    await ddb.send(new UpdateItemCommand({
      TableName: "orcamento-ia",
      Key: { pk: { S: `TENANT#${tenantId}` }, sk: { S: `PERIODO#${periodo}` } },
      UpdateExpression: "SET expira_em = if_not_exists(expira_em, :ttl) ADD gasto :estimativa",
      ConditionExpression: "attribute_not_exists(gasto) OR gasto <= :teto",
      ExpressionAttributeValues: {
        ":estimativa": { N: String(estimativa) },
        ":teto": { N: String(quota - estimativa) },        // a condição não soma: o teto vem pronto
        ":ttl": { N: String(expiracaoDoPeriodo(periodo)) } // TTL limpa períodos antigos
      }
    }));
    return true;
  } catch (erro) {
    if (erro.name === "ConditionalCheckFailedException") return false;   // quota esgotada
    throw erro;   // falha de infraestrutura: a chamada ao modelo não acontece
  }
}

Duas decisões de arquitetura ficam explícitas nesse trecho. A primeira é reservar pelo pior caso (entrada medida mais o teto de saída) e devolver a sobra depois: o contador nunca fica abaixo do gasto real, ao custo de bloquear um pouco antes do limite exato. A segunda é falhar fechado: se o DynamoDB não responde, a chamada ao modelo não acontece. Para uma funcionalidade crítica ao negócio, a alternativa é falhar aberto com teto local por instância, aceitando um gasto limitado fora do contador. É escolha de produto, e precisa estar escrita.

Há uma armadilha na reserva antecipada: se a chamada ao modelo falha depois da reserva e nada devolve a estimativa, o contador drena a quota do tenant sem nenhum token gasto, e o cliente passa a receber quota esgotada por causa de erros. O catch do handler trata os dois casos de forma diferente. Quando o serviço recusou a solicitação (throttling, validação), a reserva volta inteira. Em timeout do lado do cliente, a reserva fica, porque o modelo pode ter processado e cobrado a resposta; a diferença se resolve na reconciliação com os logs de invocação. Repare também que o AWS SDK repete chamadas com throttling antes de lançar o erro, então o tempo de reserva inclui as novas tentativas.

É o padrão que a RFX aplica em seus próprios backends serverless: portões baratos primeiro, contador no DynamoDB e kill-switch verificados antes de chamar o Amazon Bedrock, parâmetros de custo como modelo, instruções e limite de saída definidos só no servidor, e campos equivalentes enviados pelo cliente ignorados.

Alavancas de otimização e o trade-off de cada uma

Toda alavanca de custo troca dinheiro por alguma outra coisa: latência, qualidade, complexidade ou risco operacional. A tabela resume quando cada uma ajuda e o que ela cobra em troca.

Uma armadilha adicional: alguns modelos têm tarifa de contexto longo acima de um tamanho de solicitação, e a métrica do Amazon CloudWatch ganha a dimensão ContextWindow nessas chamadas, conforme a documentação de métricas. Se a sua aplicação envia contextos grandes, verifique na página de preços se o modelo escolhido tem essa faixa.

Alerta de conta x limite de código

Alertas e limites resolvem problemas diferentes, e a documentação deixa a diferença clara:

• AWS Budgets atualiza os dados até três vezes por dia, normalmente de 8 a 12 horas após a atualização anterior. A própria AWS registra que o gasto pode passar do limite antes da notificação. As ações de orçamento podem aplicar uma política IAM restritiva, mas continuam presas ao mesmo atraso.
• AWS Cost Anomaly Detection roda aproximadamente três vezes por dia sobre dados do Cost Explorer, que têm atraso de até 24 horas; uma anomalia pode levar até 24 horas para ser detectada, e um serviço novo precisa de 10 dias de histórico.
• Métricas do Amazon Bedrock no Amazon CloudWatch (InputTokenCount, OutputTokenCount, CacheReadInputTokenCount, CacheWriteInputTokenCount, no namespace AWS/Bedrock) medem consumo, não dinheiro, e servem como camada intermediária entre o código e a fatura.

Configuração mínima recomendada para cada aplicação de IA generativa em produção:

1. Orçamento mensal no AWS Budgets filtrado pela tag da aplicação, com notificação de gasto real e de gasto previsto.
2. Monitor do Cost Anomaly Detection por tag de alocação de custo ou por serviço, com alerta individual em tópico do Amazon SNS ligado ao canal do time.
3. Alarme do CloudWatch sobre tokens de saída por hora, ligado a uma automação que vira o kill-switch.
4. Limites no código, como na seção anterior, que funcionam mesmo se tudo acima atrasar.

# Alarme de consumo: soma de tokens de saída na conta e Região, por hora.
# Sem dimensão, a métrica cobre todas as chamadas, inclusive as que falharam
# antes de o modelo ser identificado. O limite vem da sua conta por unidade.
aws cloudwatch put-metric-alarm \
  --alarm-name bedrock-tokens-saida-hora \
  --namespace AWS/Bedrock \
  --metric-name OutputTokenCount \
  --statistic Sum --period 3600 --evaluation-periods 1 \
  --threshold "$LIMITE_TOKENS_SAIDA_HORA" \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions "$TOPICO_SNS_KILL_SWITCH"

Budgets e anomalia continuam indispensáveis: eles pegam o que o código não vê, como um serviço novo, um ambiente esquecido ou um modelo de terceiro faturado por outra entidade. Mas quem segura o gasto em tempo real é o código.

E o custo da IA para desenvolver: créditos do Kiro

A mesma disciplina vale para a IA que o time usa para escrever software. O Kiro, a IA agêntica da AWS para desenvolvimento de software, cobra por plano e mede o uso em créditos. Segundo a página de preços do Kiro, com valores revisados na atualização de 15/10/2026:

• Planos por usuário por mês: Free com 50 créditos; Pro, US$ 20, com 1.000; Pro+, US$ 40, com 2.000; Pro Max, US$ 100, com 5.000; Power, US$ 200, com 10.000; Enterprise sob consulta.
• O que é um crédito: uma unidade de trabalho em resposta a prompts, medida com duas casas decimais e mínimo de 0,01 por tarefa. Um prompt simples pode consumir menos de 1 crédito, trabalho complexo como executar uma tarefa de spec costuma consumir mais de 1, e modelos diferentes consomem créditos em taxas diferentes. A página dá o exemplo de referência: uma tarefa que consome X créditos no modo Auto custa 1,3X créditos quando executada com o Claude Sonnet 4.6. O uso de créditos é atualizado pelo menos a cada 5 minutos.
• Crédito adicional: US$ 0,04 cada. Nos planos individuais pagos, o pacote é cobrado na compra; no Enterprise, o excedente vem desligado por padrão, depende de um administrador habilitá-lo no console do Kiro e é cobrado no fim do mês.
• Acúmulo: créditos mensais não passam para o mês seguinte; créditos adicionais acumulam e expiram 12 meses após a compra.

A documentação de notificações de uso informa um aviso ao atingir 80% dos créditos mensais, ativo por padrão e desligável na paleta de comandos da IDE. Mantenha o aviso ligado: ele leva o sinal ao desenvolvedor antes do limite, sem depender de alguém abrir o painel de uso da assinatura.

Lista de preços não é governança. Com assinatura gerenciada por um administrador, quatro decisões resolvem a maior parte do problema: qual plano para cada perfil, como o consumo vira showback por time, quem libera excedente e com qual teto, e como a medição por tarefa orienta a escolha de modelo. Créditos de ferramenta são exatamente a moeda virtual que o FOCUS 1.2 passou a acomodar, então o destino natural desses dados é o mesmo relatório do consumo de nuvem.

1. Plano por perfil de uso, revisado com dado

A documentação de cobrança do Kiro para empresas define que cada usuário é assinado individualmente em um plano, que upgrades valem na hora e downgrades só no mês seguinte. Por isso, a regra prática é começar no plano menor que atende o perfil e subir quando o dado mostrar necessidade: subir é imediato, descer custa um mês.

Planos e cotas da página de preços do Kiro, revisados na atualização de 15/10/2026. Os limiares de "encostando na cota" e "muito abaixo" são parâmetros da sua política; defina-os por escrito antes de olhar o primeiro relatório.

Uma armadilha de cobrança documentada: o usuário assinado em dois grupos do mesmo perfil do Kiro é cobrado pelo plano mais alto entre eles. Quem organiza assinaturas por grupo do IAM Identity Center precisa conferir sobreposição entre grupos antes de fechar o mês.

2. Showback por time a partir do relatório por usuário

O dado de showback vem dos relatórios de atividade por usuário. O administrador ativa a opção Collect granular metrics per user em Settings no console do Kiro e informa um prefixo de bucket no Amazon S3, na mesma Região do perfil do Kiro e na conta em que os usuários estão assinados. A política do bucket precisa permitir s3:PutObject ao principal de serviço q.amazonaws.com. O Kiro grava um CSV por dia, às 02:00 UTC, para cada tipo de cliente (IDE, CLI e Plugin), com colunas como UserId, Subscription_Tier, Credits_Used, Overage_Enabled, Overage_Cap, Overage_Credits_Used e uma coluna de mensagens por modelo.

Catalogados no AWS Glue, esses arquivos viram uma tabela no Amazon Athena. O que falta é o mapa de pessoa para time, que a engenharia mantém a partir dos grupos do IAM Identity Center, e a tabela de preço por plano do seu contrato:

-- Showback mensal do Kiro por time, no Amazon Athena
-- kiro_user_report: CSVs diários do relatório por usuário, catalogados no AWS Glue
-- mapa_times (user_id, time): mantida pela engenharia, a partir dos grupos de acesso
-- precos_kiro (subscription_tier, preco_usd): preço por usuário do seu contrato
WITH por_usuario AS (
  SELECT userid,
         max_by(subscription_tier, "date")          AS plano,
         sum(CAST(credits_used AS double))          AS creditos_plano,
         max(CAST(overage_credits_used AS double))  AS creditos_excedentes
         -- a documentação descreve o campo como total do usuário: reconcilie com a fatura
  FROM kiro_user_report
  WHERE "date" BETWEEN ? AND ?                      -- mês de referência
  GROUP BY userid
)
SELECT m.time,
       count(*)                                     AS usuarios,
       sum(p.preco_usd)                             AS assinaturas_usd,
       sum(u.creditos_plano)                        AS creditos_plano,
       sum(u.creditos_excedentes) * 0.04            AS excedente_usd
FROM por_usuario u
JOIN mapa_times  m ON m.user_id = u.userid
JOIN precos_kiro p ON p.subscription_tier = u.plano
GROUP BY m.time
ORDER BY excedente_usd DESC;

Três cuidados de desenho. Primeiro, reconcilie a soma com a fatura do mês antes de usar o número em chargeback: o relatório é telemetria, a fatura é a fonte de verdade. Segundo, o relatório traz User_Email, então é dado pessoal de colaborador; a própria documentação recomenda criptografia no bucket e um bucket separado do usado para log de prompts, e o showback publicado deve sair agregado por time, sem ranking individual. Terceiro, o valor de US$ 0,04 por crédito excedente é o da página de preços; se o contrato Enterprise tiver outro valor, ele entra na tabela de preços, não no código.

3. Política de excedente com teto e dono

No Enterprise, o excedente vem desligado e depende de um administrador. Desde 02/07/2026, segundo o changelog do Kiro, o teto do excedente é definido no AWS Service Quotas, na cota Maximum allowed overage per Kiro profile, acessível também pelo link Manage ao lado da configuração Overages no console do Kiro. O teto vale para todos os usuários do perfil, então a diferenciação entre times fica na política, não na cota. Uma política que cabe em meia página:

• Padrão: excedente desligado, que já é o comportamento de fábrica.
• Dono: uma pessoa nomeada, normalmente quem responde pelo orçamento de engenharia, aprova a habilitação e o valor do teto no Service Quotas.
• Solicitação registrada: quem precisa, por quê e até quando. Excedente sem data de término vira custo fixo sem dono.
• Revisão mensal: usuários com Overage_Enabled verdadeiro no relatório e sem solicitação vigente voltam ao padrão; excedente recorrente na mesma pessoa vira revisão de plano (seção 1), não exceção permanente.
• Planos individuais: o pacote de créditos adicionais é pré-pago e consumido de um saldo visível, o que funciona como teto natural para consultores e desenvolvedores fora da assinatura corporativa.

4. Medição por tarefa de spec e escolha de modelo

A página de preços estabelece duas regras que orientam a escolha de modelo: créditos são medidos por tarefa com duas casas decimais, e cada modelo consome créditos em taxa própria, com o modo Auto como referência. O método é o mesmo da unidade de custo da aplicação, aplicado ao desenvolvimento:

1. Defina a unidade: a tarefa de spec concluída e aceita, não a mensagem. Tarefa reexecutada conta duas vezes, como a nova tentativa por resposta cortada na aplicação.
2. Comece em Auto: é a referência de taxa da própria página de preços. Modelo específico entra por tipo de tarefa, quando o time verificou ganho de resultado que justifique a taxa maior.
3. Leia o mix no relatório: as colunas de mensagens por modelo, cruzadas com Credits_Used, mostram que times usam modelo específico como padrão e quanto isso pesa na cota.
4. Ataque o retrabalho primeiro: tarefa de spec pequena, com critério de aceite verificável e contexto de projeto em arquivos de steering, reduz reexecução. O detalhe está nos posts sobre specs no Kiro e steering no Kiro.

O controle de créditos em pipeline está no post sobre Kiro CLI no pipeline, e como medir o retorno do uso, em como medir a adoção de IA no time. Para estruturar planos, showback e política de excedente junto com steering e specs, a RFX conduz a adoção do Kiro com o time.

Checklist FinOps de IA generativa

1. Custo unitário definido: a unidade de negócio (documento, conversa, tarefa) e a fórmula estão escritas, com dono.
2. Perfil de inferência por aplicação: toda chamada usa o ARN de um application inference profile, e a política IAM impede chamada direta ao modelo.
3. Tags ativadas: as chaves de alocação estão ativas no Billing and Cost Management desde o primeiro dia.
4. Limite de saída: cada funcionalidade tem maxTokens no servidor, com alarme sobre stopReason igual a max_tokens.
5. Contador por tenant: reserva atômica no DynamoDB antes da chamada e ajuste pelo custo real depois.
6. Kill-switch: flag verificada antes de toda chamada, acionável por operador e por alarme, testada.
7. Budget e anomalia: orçamento por tag e monitor de anomalia configurados, incluindo a entidade AWS Marketplace quando houver modelo de terceiro.
8. Revisão mensal de preço: a tabela de preços usada no código é conferida contra a fonte oficial, com data.
9. Cache medido: o ganho de prompt caching é lido em cacheReadInputTokens, não presumido.
10. Dono do custo: cada aplicação tem um responsável que recebe o showback e decide sobre modelo, limite e quota.
11. Créditos do Kiro governados: plano por perfil, relatório por usuário ativo no S3, showback agregado por time, excedente desligado por padrão e teto no Service Quotas com dono nomeado.

Custo de IA generativa é decisão de arquitetura, no mesmo nível de latência e segurança, tanto na aplicação que chama o Amazon Bedrock quanto na ferramenta que o time usa para escrever código. É esse desenho que a RFX revisa com o time: a unidade de custo, a alocação por aplicação, os limites no código e a governança de créditos do Kiro, antes de o volume chegar. A prática completa de custo está no pilar FinOps e custos na AWS.

Perguntas frequentes

Como calcular o custo de uma chamada ao Amazon Bedrock?

Leia o campo usage da resposta da Converse API e multiplique cada contagem pelo preço correspondente do modelo: inputTokens pelo preço de entrada, cacheReadInputTokens pelo preço de leitura de cache, cacheWriteInputTokens pelo preço de escrita de cache e outputTokens pelo preço de saída. Com prompt caching ativo, inputTokens traz só a parte não cacheada; o total de entrada é a soma dos três campos de entrada, conforme a documentação da AWS. O custo da unidade de negócio (documento, conversa, tarefa) é a soma das chamadas que a produzem.

Qual a diferença entre showback e chargeback no custo de IA generativa?

Showback é mostrar a cada time ou aplicação quanto ela consumiu, sem cobrança interna. Chargeback é debitar esse valor do orçamento de quem consumiu. No Amazon Bedrock, o caminho para os dois é usar um application inference profile por aplicação, com tags de alocação de custo ativadas no Billing and Cost Management, para que o gasto apareça separado no Cost Explorer e no CUR 2.0.

O AWS Budgets bloqueia o gasto com IA generativa?

O AWS Budgets avisa e pode disparar ações, mas trabalha sobre dados de faturamento atualizados até três vezes por dia, e a própria documentação registra que o gasto pode passar do limite antes da notificação. O AWS Cost Anomaly Detection pode levar até 24 horas para detectar uma anomalia. Para impedir o gasto, o limite precisa estar no código: teto de tokens de saída, contador de orçamento por cliente e kill-switch verificados antes de cada chamada ao modelo.

Prompt caching sempre reduz o custo?

Depende do modelo e do padrão de uso. Tokens lidos do cache são cobrados na taxa de leitura de cache, mas, dependendo do modelo, a escrita no cache pode custar mais que a entrada padrão, e a documentação afirma que suporte a cache não garante acerto. O ganho aparece quando um prefixo estável e longo é reutilizado dentro do tempo de vida do cache. Confira o resultado real nos campos cacheReadInputTokens e cacheWriteInputTokens da resposta.

Como os créditos do Kiro entram na gestão de custo de IA?

O Kiro, a IA agêntica da AWS para desenvolvimento de software, cobra por plano com uma cota mensal de créditos que não acumula para o mês seguinte. Créditos adicionais custam US$ 0,04 cada e, no plano Enterprise, o excedente vem desligado por padrão e depende de um administrador para ser habilitado, conforme a página de preços do Kiro (valores revisados na atualização de 15/10/2026). O teto do excedente é definido no AWS Service Quotas e vale para todos os usuários do perfil do Kiro. Trate o crédito como uma moeda virtual de ferramenta, com dono, showback por time a partir do relatório de atividade por usuário e regra explícita para o excedente.

Sobre o autor

Rodrigo Araújo

Arquiteto de Soluções, IA e Cloud | RFX Tecnologia

Arquiteto de Soluções, IA e Cloud na RFX Tecnologia, lidera projetos de migração, FinOps e IA aplicada na nuvem para empresas do Nordeste e de todo o Brasil. É também o idealizador da Jornada de Inovação AWS em João Pessoa, encontro que aproxima donos de negócio da região das aplicações reais de cloud e inteligência artificial.