Um application inference profile é um wrapper com tags em torno de um ARN de modelo, e é a única coisa entre você e uma fatura do Bedrock que mostra um único número para a empresa inteira. Você cria um profile que aponta para um modelo, anexa tags de alocação de custo, e invoca o ARN do profile em vez do ID do modelo. As tags acompanham até o Cost Explorer e o Cost and Usage Report. É esse o mecanismo inteiro, e leva uma tarde.

A tarde não é o problema. O problema é que um esquema de tags é um compromisso organizacional, e a maioria dos times escolhe um em dez minutos e convive com ele por dois anos. Então a API vale vinte minutos deste post e o design das tags vale o resto.

O problema que ele resolve

Sem profiles, o uso do Bedrock aparece como uso do Bedrock. Você recebe gasto por modelo e por região, o que diz que o Claude Sonnet custou muito no mês passado e nada sobre qual das suas nove aplicações causou isso. O relatório padrão não consegue responder a única pergunta que o financeiro sempre faz, que é de qual orçamento isso sai. Escrevi sobre o formato mais amplo disso em Your LLM Bill Is an Observability Problem. Profiles são o controle específico para a metade de atribuição.

Como funciona

Crie um profile apontando para um foundation model ou um profile cross-region definido pelo sistema, com tags:

aws bedrock create-inference-profile \
  --inference-profile-name "support-assistant-prod" \
  --model-source copyFrom=arn:aws:bedrock:eu-central-1::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0 \
  --tags key=team,value=support key=app,value=assistant key=env,value=prod

Depois invoque o ARN do profile onde antes você passava um ID de modelo:

response = client.converse(
    modelId="arn:aws:bedrock:eu-central-1:123456789012:application-inference-profile/abc123",
    messages=messages,
)

Três detalhes operacionais fáceis de passar batido:

  • Profiles são específicos por modelo. Um profile envolve um modelo. Seis aplicações vezes quatro modelos são vinte e quatro profiles. Essa multiplicação é o motivo pelo qual seu design de tags importa mais do que parece: você não está nomeando um recurso, está definindo uma grade.
  • Tags não são retroativas. Ativar uma tag de alocação de custo no console de Billing marca gastos a partir daquele ponto em diante. Nada do que você fez no mês passado é rotulado. Ative as chaves de tag antes de precisar dos dados, não quando alguém perguntar.
  • A granularidade é diária, por tipo de uso. Profiles te dão dólares faturados no Cost Explorer e no CUR com granularidade de dia. Eles não te dão custo por requisição. Se você quer economia por requisição, isso é logging de tokens do lado da aplicação, um sistema diferente com um dono diferente.

Projetando o esquema de tags

A armadilha é marcar o que é fácil de ver em vez do que alguém pode agir sobre. Toda chave de tag deve responder a uma pergunta que uma pessoa real faz numa reunião real.

Quatro chaves carregam a maioria das organizações:

  • team: quem paga. Combine com a taxonomia de centro de custo que já existe. Se o financeiro chama de cc-4471, não invente platform-eng; você vai passar o ano seguinte mantendo uma tabela de tradução em que ninguém confia.
  • app: qual carga de trabalho. A unidade que você de fato desligaria.
  • env: prod, staging, dev. Essa é a que se paga mais rápido, porque o primeiro número genuinamente surpreendente na maioria das faturas do Bedrock é quanto o dev custa.
  • feature: opcional, para aplicações onde uma funcionalidade pode dominar o gasto. Use com moderação. Toda chave extra multiplica sua contagem de profiles.

Deliberadamente fora da lista: tags por usuário. Não crie um profile por usuário. Você vai bater em limites de recurso, e a manutenção é sem fim. Para atribuição no nível de identidade, o Bedrock suporta atribuição de custo baseada em principal do IAM, que atribui gasto à identidade que fez a chamada sem um profile por pessoa. Use profiles para a granularidade de time e aplicação, e atribuição por principal do IAM quando precisar saber qual humano ou papel de serviço causou o pico. Elas se combinam.

Torne isso estrutural

Um esquema de tags que depende de disciplina apodrece. Dois controles fazem com que ele se sustente.

Primeiro, crie profiles no seu IaC, ao lado da aplicação que os usa, e puxe os valores de tag das mesmas variáveis que marcam os outros recursos daquela aplicação. Um profile criado à mão no console é um profile que vai ficar marcado como test para sempre.

Segundo, feche o caminho direto. Uma vez que os profiles existem, uma aplicação que chama um ID de modelo bruto produz gasto sem tag, e gasto sem tag é exatamente o item de linha que ninguém reivindica. Uma política de IAM que nega bedrock:InvokeModel e bedrock:Converse em ARNs de foundation model, permitindo-os em ARNs de application-inference-profile, torna o caminho com tag o único caminho. É o mesmo instinto de delimitar um papel a uma tarefa, e não vou repetir o argumento de IAM for LLM Apps: Least Privilege When the Caller Is a Model, só observar que ele se aplica tanto à sua fatura quanto ao seu raio de impacto.

Faça isso no dia um. Retrofit de uma política de negação em seis aplicações que já chamam IDs de modelo é uma migração com change-freeze anexado.

O que você ganha, e o que ainda não vai ter

Depois de um mês de dados com tags você consegue agrupar o Cost Explorer por team e ver a divisão, filtrar por env=dev e encontrar o job em lote que alguém deixou rodando, e consultar o CUR por custo por aplicação por dia e colocar isso num dashboard ao lado do volume de requisições. A detecção de anomalias também fica útil, porque um alerta de orçamento numa aplicação é sinal onde um alerta no gasto total do Bedrock é ruído.

O que você ainda não vai ter: custo por requisição, custo por cliente numa aplicação multi-tenant, e nenhuma ideia se o gasto valeu a pena. O primeiro é logging de tokens. O segundo precisa de contexto de tenant que o sistema de billing nunca vê, e é por isso que atribuição multi-tenant continua sendo um problema de aplicação. O terceiro não é sequer uma pergunta de billing. Profiles te dizem para onde o dinheiro foi. Eles não têm opinião sobre se deveria ter ido.

A conclusão

Application inference profiles transformam uma fatura do Bedrock impossível de atribuir em linhas por time, por aplicação, pelo custo de envolver um ARN de modelo. Ative as chaves de tag antes de precisar do histórico, mantenha o esquema em poucas chaves que combinem com como sua organização de fato orça, crie profiles no IaC, e negue o caminho sem tag com IAM para que a atribuição não dependa de ninguém se lembrar. A API é uma tarde. O design das tags sobrevive às pessoas que o escolheram.

Leia isto a seguir

A disciplina geral de alocação de custo da qual isso se origina, estratégia de tags em toda uma conta AWS, está nas notas de campo em ercan.cloud. O hub está em ercanermis.com.