Claude na AWS: os quatro caminhos e onde cada um encaixa
- ⬜🏛️ A arquitetura de referência de IA corporativa sobre Bedrock(AWS Bedrock — GenAI em Produção)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Na maioria das arquiteturas corporativas de IA na AWS, o modelo que ocupa a camada de inferência é o Claude. Mas "usar Claude na AWS" não é uma coisa só — são quatro caminhos diferentes, com governança, features e faturamento distintos. Escolher errado não dá erro: dá um projeto que seis meses depois descobre que a feature que precisava não existe naquele caminho. Este módulo mapeia os quatro, o que cada um habilita, e — a parte que quase nenhum material cobre — o que o Bedrock não tem.
Os quatro caminhos
Todos os quatro rodam sobre infraestrutura AWS e todos usam IAM. A diferença está em quem opera o serviço — AWS ou Anthropic — porque é isso que determina o ritmo de chegada de features e o conjunto disponível.
| Caminho | O que é | Use quando |
|---|---|---|
| Bedrock — Converse API | A API unificada do Bedrock; troca de modelo por string | Padrão corporativo: você quer poder trocar Claude por Nova sem reescrever |
| Bedrock — cliente Mantle | A Messages API da Anthropic falada dentro do Bedrock | Você quer o dialeto nativo do Claude sem sair da governança do Bedrock |
| Claude Platform on AWS | Plataforma da Anthropic operada por ela, com auth AWS e billing via Marketplace | Você quer paridade de features no dia do lançamento, mantendo IAM e fatura AWS |
| Claude Code / Agent SDK sobre Bedrock | As ferramentas de agente da Anthropic apontando para o seu Bedrock | Produtividade de engenharia sem API key pessoal e com trilha de auditoria da empresa |
Claude Platform on AWS NÃO é o Amazon Bedrock
Os nomes se parecem e a confusão é cara. O Bedrock é operado pela AWS: catálogo multi-provedor, subconjunto de features, IDs de modelo com prefixo do provedor. O Claude Platform on AWS é operado pela Anthropic sobre infraestrutura AWS: paridade de features com a API de primeira mão, IDs de modelo sem prefixo, autenticação SigV4 e cobrança pelo AWS Marketplace. São ofertas que coexistem — e a escolha entre elas é de arquitetura, não de sabor.
- → caminho padrão de plataforma multi-modelo
- → quando o app vive de recursos do Claude
- → quando precisa de paridade de features no lançamento
- → produtividade de engenharia sem API key pessoal
- Compute
- Fora da AWS
- Segurança e identidade
- Rede e entrega
- Gestão e governança
- IA e machine learning
Os quatro rodam sobre infraestrutura AWS e usam IAM. O que muda é quem opera o serviço — e é isso que determina o conjunto de features disponível e o ritmo com que os novos chegam.
- Converse API — o denominador comum. Uma API para muitos modelos: trocar de família é trocar o modelId. É o caminho padrão quando a plataforma expõe tiers.
- Mantle — dialeto nativo dentro do Bedrock. Messages API da Anthropic com autenticação AWS, rede da sua VPC e fatura AWS. Model ID leva prefixo do provedor.
- Claude Platform on AWS. Operado pela Anthropic sobre infraestrutura AWS: paridade no dia do lançamento, SigV4, Marketplace — e model ID sem prefixo.
- Claude Code e Agent SDK sobre o seu Bedrock. Sem API key pessoal: acesso revogável por role, chamadas no mesmo CloudTrail e custo atribuído por inference profile.
- O que decide é quem opera, não o modelo. Os quatro caminhos chegam ao mesmo Claude. A escolha se faz por três critérios que nada têm a ver com qualidade de resposta: com que rapidez um recurso novo aparece, em qual fatura a chamada cai, e qual trilha de auditoria a registra. Escolher por "qual é melhor" é responder à pergunta errada.
Caminho 1: Converse API — o denominador comum
É o caminho que a arquitetura de referência assume por padrão, e por um motivo: o modelId é o único ponto de acoplamento. Trocar de família de modelo é trocar uma string — o resto do código (mensagens, tool use, streaming, guardrail) permanece. Numa plataforma que expõe tiers em vez de modelos, isso é o que torna a troca uma decisão de configuração.
import boto3
br = boto3.client("bedrock-runtime", region_name="us-east-1")
# Copie o ID exato do console: inference profiles regionais prefixam a regiao
# (us. / eu. / apac.) e costumam carregar versao. Nao digite de memoria.
MODEL_ID = "<inference-profile-ou-model-id-do-console>"
resp = br.converse(
modelId=MODEL_ID,
system=[
{"text": SYSTEM_PROMPT}, # prefixo estavel primeiro
{"cachePoint": {"type": "default"}}, # tudo acima entra no prompt cache
],
messages=[{"role": "user", "content": [{"text": pergunta}]}],
inferenceConfig={"maxTokens": 800},
toolConfig={"tools": TOOLS}, # mesmo shape para qualquer modelo
)
print(resp["output"]["message"]["content"][0]["text"])
u = resp["usage"]
print(u["inputTokens"], u["outputTokens"], u.get("cacheReadInputTokens", 0))
O preço da portabilidade
A Converse é o mínimo múltiplo comum entre provedores. Recursos que só existem em um deles ficam de fora do shape padrão e entram por additionalModelRequestFields — o que funciona, mas quebra a promessa de portabilidade exatamente no ponto em que você mais depende dela. Se o seu app vive de features específicas do Claude, o caminho 2 é mais honesto.
Caminho 2: o cliente Mantle — Messages API dentro do Bedrock
O Bedrock expõe um endpoint que fala o dialeto nativo do provedor. Para o Claude, isso significa a Messages API da Anthropic — mesmo shape de request, mesmos nomes de campo, mesmo SDK — mas com autenticação AWS, rede da sua VPC e fatura da AWS. Nos SDKs da Anthropic esse é o cliente Mantle (o cliente antigo, sem Mantle, aponta para o caminho legado de InvokeModel).
from anthropic import AnthropicBedrockMantle
# Autentica pela cadeia padrao de credenciais AWS — nada de API key da Anthropic.
client = AnthropicBedrockMantle(aws_region="us-east-1")
msg = client.messages.create(
model="anthropic.claude-opus-5", # no Bedrock o ID leva prefixo do provedor
max_tokens=4096,
thinking={"type": "adaptive"}, # thinking adaptativo, sem budget_tokens
system=[{
"type": "text",
"text": SYSTEM_PROMPT,
"cache_control": {"type": "ephemeral"},
}],
messages=[{"role": "user", "content": pergunta}],
)
print(msg.content[0].text)
print(msg.usage.cache_read_input_tokens)
| Aspecto | Converse API | Cliente Mantle |
|---|---|---|
| Shape do request | Padronizado entre provedores | Nativo da Anthropic (Messages API) |
| Trocar de família de modelo | Trocar uma string | Reescrever a chamada |
| Features específicas do Claude | Via additionalModelRequestFields | Nativas, com o nome de campo da doc |
| Reuso de código da API direta | Baixo — precisa traduzir | Alto — normalmente troca só o cliente |
| Governança AWS (IAM, VPC, CloudTrail) | Completa | Completa |
| Melhor para | Plataforma multi-modelo com tiers | App que vive de recursos do Claude |
Padrão híbrido que funciona bem
Muita empresa madura usa os dois: Converse no tier de volume (classificação, roteamento, extração — onde trocar de modelo por preço é rotina) e Mantle no tier de raciocínio (onde o app depende de recursos do Claude). O gateway esconde a diferença dos squads: eles continuam pedindo um tier.
Caminho 3: Claude Platform on AWS
É a plataforma da Anthropic entregue por dentro da AWS: você autentica com credenciais AWS (SigV4), controla acesso por IAM e é cobrado pelo AWS Marketplace — mas o serviço é operado pela Anthropic, com paridade de API no mesmo dia do lançamento. É a resposta para o time que quer os recursos novos sem abrir mão do controle corporativo.
O erro clássico: prefixo trocado
No Bedrock o ID leva prefixo do provedor. No Claude Platform on AWS o ID é o nome puro. Trocar os dois é o erro mais comum de quem migra entre os caminhos, e o sintoma engana: dá erro de modelo inexistente, e o time passa horas investigando permissão de IAM. Antes de depurar acesso, confira o formato do ID contra o caminho que você está usando.
Preço: não misture as tabelas
Claude no Amazon Bedrock é operado pela AWS e tem tabela de preços própria — consulte o pricing do Bedrock. Claude Platform on AWS segue a tabela da Anthropic, cobrada via Marketplace. Escrever a proposta de custo com os números do caminho errado é um jeito silencioso de errar o business case em dezenas de por cento.
Um time migrou o código do Claude Platform on AWS para o Bedrock e passou a receber erro de modelo inexistente. As permissões de IAM foram revisadas e estão corretas. Qual é o suspeito número um?
Caminho 4: Claude Code e Agent SDK sobre o seu Bedrock
Este caminho não serve o produto — serve quem constrói o produto. O Claude Code (a ferramenta de engenharia no terminal e na IDE) e o Claude Agent SDK podem ser apontados para o Bedrock da própria empresa. Do ponto de vista corporativo, é o que transforma "cada dev com sua API key pessoal no cartão de crédito" em uma capacidade governada.
# Aponta a ferramenta para o Bedrock da empresa em vez da API direta.
# Confirme os nomes das variaveis na doc oficial da versao que voce usa —
# elas evoluem, e um nome errado faz a ferramenta cair silenciosamente
# de volta para o caminho padrao.
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-east-1
export AWS_PROFILE=engenharia-ia # role corporativa, sem API key pessoal
export ANTHROPIC_MODEL="<id-do-modelo-no-bedrock>"
# Validacao: a chamada tem que aparecer no CloudTrail da conta da empresa.
# Se nao aparecer, a ferramenta nao esta usando o Bedrock — reveja as variaveis.
aws sts get-caller-identity
Duas ferramentas com nomes parecidos
Claude Agent SDK e o "tool runner" do SDK da API são coisas diferentes. O Agent SDK é o harness completo de agente (ferramentas de arquivo, bash, busca, subagentes) empacotado como biblioteca — é o que você usa para construir um agente de engenharia. O tool runner é um utilitário do SDK da API que só dirige o laço de chamadas das ferramentas que você mesmo define. Nos dois casos, o deploy é seu.
O que o Bedrock NÃO tem (e onde isso dói)
Esta é a tabela que decide arquitetura e quase nunca aparece em apresentação. O Bedrock cobre o núcleo com folga, mas não é o conjunto completo de recursos da plataforma Anthropic. Descobrir isso no meio do projeto é caro; descobrir agora é uma linha no desenho.
| Recurso | No Bedrock | Se você precisa dele |
|---|---|---|
| Mensagens, streaming, tool use | Sim | Nada a fazer — é o núcleo |
| Prompt caching (5 min e 1 h) | Sim | Sua principal alavanca de custo funciona normalmente |
| Caching automático (sem marcar ponto) | Não | Marque o cache point explicitamente — é o que a Converse já pede |
| Thinking adaptativo e effort | Sim | Disponível; budget_tokens fixo saiu nos modelos atuais |
| PDF, citações, structured outputs, contagem de tokens | Sim | Sem restrição relevante |
| Busca na web e busca de páginas como ferramenta do modelo | Não | Implemente a busca você mesmo como tool, ou use outro caminho |
| Execução de código gerenciada pelo provedor | Não | AgentCore Code Interpreter ou sandbox própria |
| Conector MCP gerenciado pela API | Não | AgentCore Gateway ou hospede o servidor MCP você mesmo |
| Agents gerenciados pela Anthropic | Não | AgentCore Runtime é o equivalente do lado AWS |
| Files API / Models API / Batches da Anthropic | Não | Use S3 e o batch inference nativo do Bedrock — que existe e dá ~50% de desconto |
| Mensagens de sistema no meio da conversa | Não | Reconstrua o system prompt (e assuma a invalidação de cache) ou injete no turno do usuário |
"Batches: não" não quer dizer "sem batch"
Essa linha confunde todo mundo. O que não existe no Bedrock é o endpoint de Message Batches da Anthropic. O Bedrock tem o próprio batch inference, com o mesmo benefício econômico (~50% de desconto) — só que com outra API e outro fluxo, via S3. Se o seu plano de custo depende de batch, ele continua de pé; só muda a implementação.
Gotcha do Bedrock com tool_choice forçado
No Bedrock, forçar uma ferramenta específica (tool_choice apontando para uma tool, ou exigindo qualquer uma) exige desabilitar o thinking explicitamente em alguns modelos atuais. Na API de primeira mão isso não é necessário. É o tipo de diferença que só aparece quando o request volta 400 em produção — vale um teste de integração cobrindo o caminho de tool forçada.
Como escolher
📋 Uma seguradora vai construir a plataforma interna de IA. Quer trocar de modelo por custo conforme a tarefa, precisa de RAG gerenciado sobre documentos internos e tem exigência de tráfego privado e trilha de auditoria completa.
Multi-modelo com troca por string é requisito explícito, RAG gerenciado e Guardrails já vêm no serviço, e PrivateLink, KMS e CloudTrail resolvem rede e auditoria sem construção adicional. O subconjunto de features do Bedrock cobre esse caso de uso inteiro.
Alt: Claude Platform on AWS — Ganha em paridade de features, mas não entrega o catálogo multi-modelo nem o RAG gerenciado que essa arquitetura pediu.
Alt: API direta da Anthropic — Fora da governança AWS: outra credencial para rotacionar, outra fatura e nenhuma integração nativa com VPC e CloudTrail.
Alt: Self-host de modelo aberto — Exige time de MLOps e GPU paga por hora ociosa; só se justifica em volume muito alto e constante.
O roadmap do produto prevê que o agente faça buscas na web durante a conversa. A arquitetura hoje está toda no Bedrock. Qual é a leitura correta?
Por que uma empresa apontaria o Claude Code dos seus engenheiros para o Bedrock corporativo em vez de deixar cada um usar sua própria assinatura?
Próximo passo
Blueprint desenhado, caminho de acesso escolhido. Agora os três arquétipos que cobrem quase toda IA corporativa — front-office, back-office e uso interno — desenhados camada a camada, com baseline, decisões, erros e números. O primeiro é atendimento.
Perguntas frequentes
❓ Quais são os caminhos para usar Claude na AWS?
❓ Todo recurso da API direta existe no Bedrock?
❓ Como escolher entre os caminhos?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…