Bedrock tá caro e ninguém sabe de quem? Separe o custo de IA por time com Inference Profiles

O problema que ninguém te conta sobre Bedrock compartilhado

Você liberou o Amazon Bedrock pra empresa toda. RH usa pra tirar dúvida de política interna. Financeiro joga PDF pra análise. TI pede pra debugar CloudFormation. Todo mundo feliz — até chegar a fatura.

Uma linha só. Um modelo. Três times. O financeiro não consegue fazer chargeback, ninguém consegue definir budget, e ninguém sabe quem tá queimando token às 3 da manhã.

Esse é o clássico problema de atribuição de custo em ambiente multi-tenant. A solução ingênua é criar um IAM role por time e passar a identidade do usuário pro AWS. Funciona, mas você arrasta gerenciamento de sessão e plumbing de identidade pro meio da sua aplicação. Não vale a pena.

Tem um caminho mais limpo: Amazon Bedrock application inference profiles. São wrappers com tag em volta de um foundation model. Você atribui custo por workload, não por identidade de quem chamou. Mesmo modelo, mesmo preço por token, mas agora cada departamento cai numa linha própria do Cost Explorer.

Se você curte a parte econômica de IA em cloud, dá uma olhada no nosso deep dive sobre como o Maia 200 da Microsoft muda a curva de custo de inferência.

O modelo mental é simples: sua aplicação autentica o usuário, descobre o departamento dele, e roteia a chamada Bedrock pro ARN do inference profile correspondente. O Bedrock registra o uso contra a tag Team daquele profile. O Cost Explorer agrupa por tag. Pronto.

Mão na massa: profiles, tags e um roteador em Python

Passo 1 — Crie um inference profile por departamento

No console do Bedrock: Inference profiles → aba Application → Create inference profile. Aponte cada um pro mesmo foundation model (tipo Anthropic Claude), mas com uma tag Team única:

O status vira Active na hora. Se você tem dezenas de times, esquece o console e usa o recurso AWS::Bedrock::ApplicationInferenceProfile no CloudFormation.

Passo 2 — Ative a tag de alocação de custo

Tag não aparece no Cost Explorer até você ativar. Vai em Billing and Cost Management → Cost allocation tags, busca Team, seleciona e clica em Activate.

Dois detalhes que pegam todo mundo:

• Case-sensitive. Team ≠ team.
• Demora de 24 a 48 horas pro custo aparecer.

Se você usa AWS Organizations, ativa na conta de management (payer) pra consolidar o uso das contas membro.

Passo 3 — Roteie as invocações pelo ARN do profile

A chamada da API não muda. Você só troca o modelId do ID do foundation model pro ARN do inference profile:

# Roteia uma invocação do Bedrock pro inference profile do departamento correto.
# O ARN do profile vai como modelId — o formato da API é idêntico a uma chamada direta.
import boto3

bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")

# Mapeia cada departamento pro ARN do seu inference profile com tag.
# Troque 111122223333 pelo ID da sua conta AWS.
DEPARTMENT_PROFILES = {
    "HR": "arn:aws:bedrock:us-east-1:111122223333:application-inference-profile/hr-profile-id",
    "Accounting": "arn:aws:bedrock:us-east-1:111122223333:application-inference-profile/acct-profile-id",
    "IT": "arn:aws:bedrock:us-east-1:111122223333:application-inference-profile/it-profile-id",
}

def invoke_for_department(department: str, prompt: str) -> str:
    """Invoca o Bedrock via inference profile do departamento pra atribuir custo."""
    if department not in DEPARTMENT_PROFILES:
        raise ValueError(f"Departamento desconhecido: {department}")

    response = bedrock.invoke_model(
        modelId=DEPARTMENT_PROFILES[department],  # <-- a única coisa que muda
        body={"anthropic_version": "bedrock-2023-05-31",
              "max_tokens": 512,
              "messages": [{"role": "user", "content": prompt}]},
    )
    return response["body"].read().decode("utf-8")

# Exemplo: RH pergunta sobre política interna
print(invoke_for_department("HR", "Resuma a política de licença parental."))

Passo 4 — Dê permissão no profile e no modelo pro IAM role

Um único IAM role serve todos os departamentos. A policy precisa do ARN do profile e do foundation model por baixo — invocar via profile exige permissão nos dois:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:us-east-1:111122223333:application-inference-profile/*",
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-*"
      ]
    }
  ]
}

Em produção, troca o wildcard * pelos ARNs explícitos — senão qualquer profile futuro herda permissão de invocação automaticamente.

Passo 5 — Leia o breakdown no Cost Explorer

Cost Explorer → Group by → Tag → Team, escolhe granularidade Diária ou Mensal, e seleciona um período depois das invocações. Você vê HR, Accounting e IT como segmentos coloridos separados com valores exatos na tabela abaixo.

Onde essa abordagem quebra

Inference profiles são elegantes, mas não são bala de prata. Conhece as bordas antes de subir pra produção:

1. O lag da tag é real. 24 a 48 horas entre invocação e visibilidade de custo. Se você precisa de gasto por time em tempo real, essa não é a ferramenta — combina com métricas de token no CloudWatch pra sinal quase em tempo real.

2. Tag é fronteira lógica, não de segurança. Um bug no roteamento pode atribuir tráfego do RH silenciosamente pro profile do TI. Nada no Bedrock impede isso. Seu código de roteamento precisa ser testado como uma checagem de auth.

3. Case sensitivity vai te queimar. Team, team e TEAM são três tags diferentes pro AWS. Padroniza um casing num arquivo de constantes compartilhado.

4. Deletar um profile quebra app em produção na hora. O ARN muda na recriação, então qualquer referência hardcoded morre. Trata ARN de profile como connection string de banco — config, não código.

5. Atribuição de custo ≠ controle de custo. Profiles te dizem quem gastou o quê. Não limitam nada. Coloca AWS Budgets por time e Cost Anomaly Detection pro momento "por que o TI tá queimando 10x hoje".

Próximos passos

Com a atribuição por time funcionando, as extensões naturais são:

• AWS Budgets — teto mensal por valor da tag Team com alerta em 80%.
• Cost Anomaly Detection — deixa o AWS aprender o baseline de cada time e te avisar em outliers.
• Métricas de token no CloudWatch — contagem de input/output por profile pra capacity planning.
• Knowledge Bases (RAG) — referencia o mesmo ARN do profile pra custo de retrieval cair no mesmo time, não só invocações diretas.

Se você tá montando uma plataforma de IA em cima do Bedrock, a mesma disciplina de custo aparece na camada de silício também — dá uma olhada na análise do IGX Thor da NVIDIA e trade-offs de IA na edge pra ver como escolha de hardware respinga na fatura.

Resumindo

Se vários times compartilham um foundation model no Bedrock, você tem três opções:

1. Não fazer nada — engolir a linha única e brigar todo mês.
2. Atribuição por IAM role — precisa de plumbing de sessão por usuário.
3. Application inference profiles — mesmo preço por token, atribuição por tag, mudança mínima no código.

A opção 3 ganha pra maioria dos times. São ~30 minutos de console + uma mudança de roteamento no app. O retorno é uma visão no Cost Explorer onde cada departamento vê o próprio número — e o financeiro para de mandar mensagem passivo-agressiva no Slack.

Começa com um departamento. Prova que a tag flui até o Cost Explorer. Depois escala com CloudFormation e budgets por time.

Fonte: Este walkthrough é baseado no post do AWS Architecture Blog sobre rastreamento de custos de IA generativa com Amazon Bedrock inference profiles — leia o original aqui.