Bedrock vs API direta: quando usar cada um

Pense em três portas para o mesmo modelo. A primeira é o Amazon Bedrock: você fala com o modelo via AWS (IAM, VPC), e ele é operado pela AWS — o que a gente chama de partner-operated. A segunda é a API direta do provedor: você fala com a Anthropic/OpenAI diretamente, com a API key deles. A terceira, mais nova, é o Claude Platform on AWS: a Anthropic opera o modelo, mas dentro da AWS, com auth SigV4/IAM e billing pela Marketplace. A tabela abaixo é o mapa; o resto do módulo é o detalhe de cada eixo.

O primeiro eixo é controle de acesso. Na API direta, autenticação é uma API key de terceiro: um segredo a mais para criar, rotacionar, vazar e auditar fora do seu perímetro AWS. No Bedrock, a chamada é autorizada por IAM — a ação é bedrock:InvokeModel (a mesma que a Converse usa por baixo). Você amarra a permissão por Resource (o ARN do foundation model ou do inference profile) e por condition keys: aws:RequestedRegion para prender a inferência a uma região, e o ARN do inference profile para restringir qual roteamento é permitido. Zero API key de terceiro no jogo.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "InvokeClaudeSomenteUsEast1",
      "Effect": "Allow",
      "Action": "bedrock:InvokeModel",
      "Resource": [
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-opus-4-8",
        "arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.anthropic.claude-opus-4-8"
      ],
      "Condition": {
        "StringEquals": { "aws:RequestedRegion": "us-east-1" }
      }
    }
  ]
}

O segundo eixo é onde o pacote trafega. Com a API direta, o request sai pela internet pública (egress TLS) para o provedor. Com o Bedrock, você cria um VPC interface endpoint (PrivateLink): a inferência acontece sem tocar a internet pública, e você enxerga o tráfego nos VPC Flow Logs. Em repouso, o que precisar ficar cifrado (custom models, Knowledge Bases, jobs) usa a sua KMS CMK; toda chamada de controle e de dados aparece no CloudTrail para auditoria. E há um isolamento estrutural: cada provedor roda numa Model Deployment Account operada pela AWS, separando o código do provedor dos seus dados.

O terceiro eixo é lock-in. Na API direta, você fala o dialeto de um provedor: trocar de vendor é reescrever a camada de request/response. No Bedrock, a Converse API é um contrato único de mensagens que serve Claude, Nova, Llama, Mistral e outros — trocar de modelo é, no melhor caso, mudar a string do modelId. Um detalhe operacional importante mora justamente nesse modelId:

import boto3

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

# No Bedrock, o modelId da Claude leva o prefixo "anthropic."
# (ou o prefixo do inference profile: "us.anthropic.")
resp = bedrock.converse(
    modelId="anthropic.claude-opus-4-8",
    messages=[{"role": "user", "content": [{"text": "Explique MVCC em uma frase."}]}],
    inferenceConfig={"maxTokens": 512, "temperature": 0.2},
    requestMetadata={"team": "plataforma", "feature": "resumo"},  # vira cost allocation
)
print(resp["output"]["message"]["content"][0]["text"])

# Trocar de vendor = mudar so o modelId; o resto do codigo nao muda:
#   Claude  -> "anthropic.claude-opus-4-8"
#   Nova    -> "amazon.nova-pro-v1:0"
#   Llama   -> "meta.llama3-3-70b-instruct-v1:0"
#   Mistral -> "mistral.mistral-large-2407-v1:0"

Além da inferência, o Bedrock traz uma vizinhança pronta: Guardrails (filtros de conteúdo e PII), Knowledge Bases (RAG gerenciado), Agents / AgentCore, processamento em batch (~50% de desconto) e provisioned throughput. Do lado financeiro, tudo cai numa fatura AWS, e o campo requestMetadata da Converse vira cost allocation tag — você atribui gasto por time/feature sem instrumentar nada por fora. Some a isso o model invocation logging para observabilidade. E há o eixo que decide compra em empresa regulada:

• HIPAA-eligible — cargas com PHI sob BAA da AWS
• SOC 1/2/3 e ISO 27001/27017/27018/42001 (gestão de IA)
• CSA STAR e conformidade com GDPR
• FedRAMP High (e ILs para workloads gov) em regiões elegíveis

A régua é simples: o que a Anthropic e a OpenAI lançam sai primeiro na API first-party delas. O Bedrock clássico é partner-operated — a AWS empacota e opera o modelo dentro da própria stack de serving, e recursos que rodam server-side no provedor (ferramentas que o próprio provedor executa) chegam com atraso, quando chegam. Em meados de 2026, o mapa é este:

Em 2026 surge uma terceira porta que dissolve o falso dilema. O Claude Platform on AWS é Anthropic-operated: a própria Anthropic opera o modelo, mas dentro da AWS. Isso te dá paridade same-day com a API first-party (o recurso novo aparece no dia do lançamento), com IDs sem prefixo (claude-opus-4-8), e ao mesmo tempo mantém a governança AWS: auth SigV4/IAM e billing pela AWS Marketplace. É a resposta para quem quer o mais novo E o controle da AWS. Compare as duas portas para a Claude:

Não existe vencedor absoluto — existe o eixo em que você está otimizando. O Bedrock te dá governança AWS-nativa, multi-vendor por uma API só, rede privada e compliance, tudo numa fatura — ao custo de defasagem de features (partner-operated). A API direta te dá bleeding edge e a superfície completa de um provedor — ao custo de gerir credencial, rede e billing por provedor. E, quando o requisito é 'os dois ao mesmo tempo' para a Claude, o Claude Platform on AWS é a ponte.