Amazon Bedrock — modelos, invocação e pricing

Sem Bedrock, usar um foundation model em produção na AWS significava: contratar o provedor, gerenciar credencial fora da AWS, tratar o tráfego saindo para a internet, reimplementar a integração a cada modelo novo, e resolver com o jurídico para onde o dado da empresa estava indo.

O valor do catálogo não é ter muitos modelos — é você poder trocar. Modelos diferentes têm perfis diferentes de custo, latência e capacidade, e a arquitetura madura usa mais de um.

Um detalhe prático que confunde quem vem da API da Anthropic: no Bedrock, os IDs de modelo da Anthropic levam o prefixo do provedor — anthropic.claude-opus-5 — enquanto na API direta da Anthropic o ID é claude-opus-5, sem prefixo. É a fonte número um de erro de "modelo não encontrado" em quem migra.

São duas APIs de inferência. A Converse API é a recomendada: ela normaliza o formato entre modelos, então o mesmo código serve para Claude, Llama ou Titan. A InvokeModel é a de baixo nível, em que o corpo da requisição segue o formato nativo de cada provedor — você a usa quando precisa de um campo que só aquele modelo tem.

import boto3

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

# Converse API: mesmo formato para qualquer modelo do catálogo.
# Trocar de modelo = trocar esta string, e mais nada.
resposta = bedrock.converse(
    modelId="anthropic.claude-opus-5",
    messages=[
        {
            "role": "user",
            "content": [{"text": "Resuma este ticket em uma frase: " + ticket}],
        }
    ],
    system=[{"text": "Você é um analista de suporte. Responda em português, sem saudação."}],
    inferenceConfig={
        "maxTokens": 200,       # teto de saída — controle direto de custo
        "temperature": 0.2,     # tarefa de extração pede consistência
    },
)

texto = resposta["output"]["message"]["content"][0]["text"]

# O uso vem na própria resposta: é daqui que sai o custo real, não de estimativa.
uso = resposta["usage"]
print(uso["inputTokens"], uso["outputTokens"], uso["totalTokens"])

Para resposta em streaming, existe converse_stream: o token aparece conforme é gerado. Não muda o custo, muda a latência percebida — e em interface de chat isso é a diferença entre parecer travado e parecer instantâneo.

A regra prática: comece on-demand. Provisioned Throughput só se paga com volume sustentado — e capacidade reservada ociosa é a forma mais rápida de queimar orçamento em projeto de IA. Já batch é dinheiro na mesa: se a tarefa tolera esperar, o desconto é significativo por nenhuma mudança de arquitetura.

Duas otimizações que aparecem em questão de custo e de disponibilidade.

Prompt caching guarda um prefixo do prompt já processado e cobra a leitura dele por uma fração do preço. Funciona por prefixo: só acerta se o começo do prompt for idêntico byte a byte. No Bedrock isso é explícito — você marca onde o cache termina, não é automático. A consequência de desenho é forte: ponha o que é estável (instrução, esquema de ferramenta, política) no começo, e o que varia (pergunta do usuário) no fim. Prompt montado na ordem inversa nunca acerta o cache.

Inferência entre regiões (cross-region inference) roteia a chamada automaticamente para outra região com capacidade, aumentando a resiliência a picos. Aparece em questão de disponibilidade — e tem implicação de conformidade: se o seu requisito é que o dado não saia de uma geografia, você precisa saber quais regiões o perfil de inferência abrange.

Esta seção existe porque material de terceiros erra muito aqui. Bedrock hospeda modelos e entrega inferência; ele não é a plataforma completa da Anthropic. Recursos que existem chamando a Anthropic direto não estão disponíveis via Bedrock.

Nada disso é defeito: é escopo. Se o seu requisito é inferência gerenciada dentro do perímetro da AWS, com IAM, VPC endpoint e cobrança consolidada, Bedrock é a resposta certa. Se você precisa dos recursos de plataforma mais recentes da Anthropic, o caminho é outro — e saber os dois é o que diferencia quem projeta de quem repete.