Claude Code no Amazon Bedrock deixou de ser apenas uma pergunta de setup. A parte difícil é operá-lo como infraestrutura de produção: credenciais AWS temporárias, acesso estreito a modelos, logging de invocação, controles de custo, política de workstation e uma fronteira clara entre evidência de auditoria no Bedrock e telemetria local do desenvolvedor.
Este guia foca nesse caminho de produção. Ele mostra como configurar Claude Code no Bedrock, onde o Claude Desktop 3P se encaixa, quando um caminho auto-hospedado justifica o trabalho extra e o que precisa ser travado antes que um assistente de código vire parte do modelo operacional de engenharia.
O Claude Code é o assistente de codificação com IA da Anthropic que vive no seu terminal, IDE ou navegador. Ele lê seu código-fonte, executa comandos, escreve e edita arquivos, e lida com tarefas complexas de engenharia — desde depuração até implementação de funcionalidades e refatoração — tudo guiado por instruções em linguagem natural.
Para organizações que operam na AWS, o Claude Code pode ser conectado diretamente ao Amazon Bedrock, o Claude Desktop pode usar o modo Cowork on third-party (3P) com Bedrock para as abas Cowork e Code, e modelos auto-hospedados ainda podem ser expostos dentro da sua própria VPC quando esse controle extra é necessário. Este guia percorre os caminhos de ponta a ponta: pré-requisitos, configuração, IAM, fixação de versões de modelos, rede, rollout enterprise e melhores práticas operacionais.
Resposta rápida: Claude Code no Amazon Bedrock
O Claude Code pode usar o Amazon Bedrock como caminho de modelo hospedado na AWS quando a equipe precisa de acesso ao Claude com IAM, controles regionais, faturamento AWS, desenho de rede e guardrails de rollout enterprise. O setup prático não é só trocar o modelo: valide acesso aos modelos no Bedrock, credenciais SSO, CLAUDE_CODE_USE_BEDROCK, AWS_REGION, modelos fixados, controles de repositório, logging de invocação e egresso de dados antes de ampliar o uso. Reserve ANTHROPIC_BASE_URL para caminhos com gateway ou modelos auto-hospedados.
Padrão recomendado para Bedrock na AWS
Para um rollout de produção do Claude Code na AWS, a variante recomendada não é uma chave de API pessoal nem um setup de desenvolvedor sem gestão. Use o Bedrock como plano de controle do modelo, autentique engenheiros com SSO, limite o IAM de runtime a perfis e ARNs de modelo aprovados, e trate o logging de invocação do Bedrock como baseline de auditoria.
- Fronteira de workload: execute Claude Code no Bedrock a partir de uma conta AWS dedicada ou uma conta de workload bem escopada, separada de infraestrutura de aplicação não relacionada.
- Acesso humano: use IAM Identity Center / AWS SSO e roles temporárias de runtime. Mantenha permissões de bootstrap, acesso a modelos, assinatura no Marketplace e configuração de logging fora da role diária dos engenheiros.
- IAM de runtime: permita apenas
bedrock:InvokeModel,bedrock:InvokeModelWithResponseStream, descoberta de modelos/perfis e métricas CloudWatch somente leitura. Restrinja recursos aos perfis de inferência aprovados e aos ARNs foundation-model do Claude nas Regiões para as quais o perfil pode rotear. - Negativas de runtime: negue chamadas fora da Região aprovada, negue
bedrock:CallWithBearerTokensalvo exceção estreita aprovada, e negue ações admin do Bedrock mais subscribe/unsubscribe do Marketplace em roles de runtime. - Modelos: fixe IDs de modelo/perfil para Sonnet, Haiku e Opus e valide disponibilidade na conta e Região alvo antes do rollout.
- Auditoria: habilite Bedrock invocation logging para CloudWatch Logs e S3 na Região aprovada. Trate objetos de log no S3 como dados sensíveis de produção porque prompts, respostas, imagens e documentos podem ser gravados ali.
- Operação: configure CloudTrail, KMS, retenção, alarmes de falha na entrega de logs, budgets do Bedrock, budget total da conta, Cost Anomaly Detection e backend Terraform versionado e criptografado com locking em DynamoDB.
- Guardrail organizacional: use SCP quando possível para bloquear modelos não aprovados, Regiões sem logging, acesso por bearer token, ações admin em runtime e assinatura no Marketplace por roles não administrativas.
Matriz de Decisão Rápida
| Você precisa de... | Escolha |
|---|---|
| Claude Code no terminal com faturamento e governança AWS | Bedrock direto |
| Claude Desktop com Cowork e Code roteando inferência pelo Bedrock | Cowork on 3P com Bedrock |
| Apps Claude prontos com gestão SaaS da Anthropic | Team / Enterprise |
| Modelos open-source na sua VPC | Auto-hospedado |
| Engenharia + negócios juntos | Híbrido |
Bedrock vs. Claude Team/Enterprise: Controle Nativo AWS ou Experiência SaaS
A escolha se resume a controle nativo AWS versus experiência de aplicativo Claude pronta para uso. A documentação oficial da Anthropic posiciona o Claude Team/Enterprise como a melhor experiência para a maioria das organizações, enquanto o Bedrock é o melhor encaixe para deployments nativos AWS.
Claude no Amazon Bedrock
O Bedrock é a escolha certa para organizações com deployments nativos AWS que desejam:
- Faturamento e governança AWS. O consumo do Bedrock é baseado em uso e aparece na sua fatura padrão da AWS. A AWS também oferece capacidade reservada, inferência em lote e outros modelos de preço além do sob demanda. O gasto com Bedrock pode descontar de um compromisso existente do AWS Enterprise Discount Program (EDP); confirme a elegibilidade com sua equipe de conta AWS, pois os termos variam.
- Controles de segurança ancorados na AWS. As requisições são governadas pelo AWS IAM, processadas dentro da região selecionada, criptografadas em repouso e em trânsito, e não compartilhadas com provedores de modelos. Conectividade opcional via PrivateLink e VPC fornecem isolamento adicional em nível de rede.
- Serviços de desenvolvimento de aplicações AWS. Além da invocação de modelos, o Bedrock oferece avaliação, fine-tuning, RAG (bases de conhecimento), agentes, guardrails e fluxos de trabalho colaborativos pelo SageMaker Unified Studio.
A ressalva importante agora é mais específica: o acesso direto ao Bedrock é um caminho de modelo/API, não uma assinatura do aplicativo Claude Team ou Enterprise. O Bedrock isolado não inclui os apps Claude padrão para web, iOS ou Android, a administração SaaS do plano Claude, histórico hospedado pela Anthropic, Projects, Artifacts ou conectores gerenciados pela Anthropic. O Claude Desktop agora pode rodar em modo Cowork on 3P com inferência pelo Bedrock, mas esse é um deployment Desktop configurado separadamente, com armazenamento local, políticas via MDM/sistema operacional e paridade de recursos/administração diferente da experiência SaaS padrão. Se você precisa do rollout gerenciado mais simples do aplicativo Claude, com colaboração e conectores de workspace prontos, compare Bedrock e Desktop 3P com Claude Team ou Enterprise.
Claude Team e Enterprise (SaaS por Assento)
Os planos Claude Team e Enterprise operam fora do ecossistema AWS com um modelo de assinatura por assento (níveis padrão e premium, com uso extra opcional e controles de gasto). O que entregam é a adoção mais rápida:
- Acesso nativo via web, iOS, Android e desktop ao Claude
- Projects, Artifacts e fluxos de trabalho colaborativos
- Conectores de workspace (Google Workspace disponível amplamente; conectores personalizados e de workspace também disponíveis além do Team)
- Claude Code e Claude Cowork inclusos
- Administração organizacional, faturamento centralizado e controles de segurança
- Enterprise adiciona SSO/SCIM, retenção expandida e controles de administração avançados
Qual Caminho é o Certo?
| Dimensão | Claude no Bedrock | Claude Team / Enterprise |
|---|---|---|
| Modelo de faturamento | Baseado em uso (sob demanda, reservado, lote); pode descontar do EDP | Assinatura por assento (padrão / premium) com uso extra opcional |
| Dados e segurança | IAM, processamento regional, criptografia, PrivateLink/VPC opcional | Infraestrutura gerenciada pela Anthropic com controles de plataforma |
| Experiência de aplicativo Claude | API de modelo + serviços AWS; Desktop 3P disponível como deployment local separado | Experiência SaaS gerenciada: apps web/mobile/desktop, Projects, Artifacts, conectores e administração |
| Serviços de desenvolvimento IA | Avaliação, fine-tuning, RAG, agentes, guardrails, SageMaker | Não aplicável — SaaS focado no usuário |
| Melhor para | Equipes de engenharia, integrações personalizadas, fluxos nativos AWS | Adoção organizacional ampla, valor imediato, usuários não técnicos |
Muitos de nossos clientes adotam ambos: Bedrock para equipes de engenharia e aplicações personalizadas, mais um plano Claude Team ou Enterprise para usuários de negócios. A Elevata pode ajudá-lo a projetar essa abordagem híbrida.
Cenário 1: Claude Code com Amazon Bedrock
O AWS Bedrock oferece acesso totalmente gerenciado aos modelos Claude da Anthropic sem hospedar ou escalar infraestrutura. Para equipes que já operam na AWS, este é o caminho mais direto para habilitar o Claude Code.
Pré-requisitos
- Uma conta AWS com acesso ao Bedrock habilitado
- Permissões AWS Marketplace necessárias (detalhadas abaixo)
- AWS CLI v2 instalado e configurado para o caminho recomendado com SSO. Ele é opcional apenas em experimentos estreitos com bearer token/chave de API.
Passo 1: Habilitar Acesso aos Modelos
Para usar o Claude pelo Amazon Bedrock, certifique-se de que sua conta tem as permissões AWS Marketplace necessárias e então complete o formulário de Primeiro Uso da Anthropic. Depois do formulário, o acesso é concedido imediatamente, embora a assinatura e configuração iniciais possam levar alguns minutos antes que as chamadas funcionem consistentemente.
- Navegue até o Amazon Bedrock no Console AWS.
- Acesse Model access e selecione os modelos Claude desejados.
- Complete o formulário de caso de uso da Anthropic (uma única vez por conta). O acesso é concedido imediatamente após o envio.
- Aguarde alguns minutos para que a assinatura inicial seja processada antes de fazer sua primeira chamada de API.
Passo 2: Solicitar Aumento de Cotas
As cotas padrão podem ser insuficientes para uso em equipe. Solicite aumentos proativamente:
| Cota | Padrão | Ação Recomendada |
|---|---|---|
| InvokeModel requisições/min | Varia por modelo | Aumento baseado no tamanho da equipe (est. 5–10 RPM por dev) |
| InvokeModelWithResponseStream | Varia por modelo | Aumento proporcional (Claude Code usa streaming) |
| Max tokens por requisição | Dependente do modelo | Verificar alinhamento com janela de contexto do Claude Code |
Passo 3: Configurar Permissões IAM
Separe a role de bootstrap/admin da role de runtime usada no dia a dia pelos engenheiros. O exemplo de setup da Anthropic inclui assinatura no Marketplace e permissões de acesso a modelos porque alguém precisa preparar a conta AWS. Isso não significa que desenvolvedores devam carregar essas permissões enquanto programam.
Role de bootstrap/admin. Use para setup inicial da conta, acesso a modelos, assinatura no Marketplace, configuração de model invocation logging, budgets e guardrails. Mantenha essa role com o time de plataforma ou cloud, não em cada workstation.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "BedrockAccountBootstrap",
"Effect": "Allow",
"Action": [
"bedrock:GetFoundationModel",
"bedrock:ListFoundationModels",
"bedrock:GetInferenceProfile",
"bedrock:ListInferenceProfiles",
"bedrock:PutUseCaseForModelAccess",
"bedrock:PutModelInvocationLoggingConfiguration",
"bedrock:GetModelInvocationLoggingConfiguration",
"bedrock:DeleteModelInvocationLoggingConfiguration"
],
"Resource": "*"
},
{
"Sid": "MarketplaceModelEnablement",
"Effect": "Allow",
"Action": [
"aws-marketplace:ViewSubscriptions",
"aws-marketplace:Subscribe"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:CalledViaLast": "bedrock.amazonaws.com"
}
}
}
]
}Role de runtime para engenheiros. Esta é a role que desenvolvedores devem usar no dia a dia. Ela invoca apenas recursos Claude aprovados, descobre metadados de modelos/perfis e lê métricas do CloudWatch. Substitua conta, Região e IDs pelos recursos validados na sua conta.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "InvokeApprovedClaudeProfilesOnly",
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": [
"arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.anthropic.claude-sonnet-4-6",
"arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.anthropic.claude-haiku-4-5-20251001-v1:0",
"arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.anthropic.claude-opus-4-8",
"arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4-6*",
"arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-sonnet-4-6*",
"arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-haiku-4-5*",
"arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-haiku-4-5*",
"arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-opus-4-8*",
"arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-opus-4-8*"
]
},
{
"Sid": "DiscoverApprovedProfiles",
"Effect": "Allow",
"Action": [
"bedrock:GetFoundationModel",
"bedrock:ListFoundationModels",
"bedrock:GetInferenceProfile",
"bedrock:ListInferenceProfiles"
],
"Resource": "*"
},
{
"Sid": "ReadOnlyBedrockMetrics",
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricData",
"cloudwatch:GetMetricStatistics",
"cloudwatch:ListMetrics"
],
"Resource": "*"
},
{
"Sid": "DenyOutsideApprovedRegion",
"Effect": "Deny",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": "us-east-1"
}
}
},
{
"Sid": "DenyBearerTokenRuntimeAccess",
"Effect": "Deny",
"Action": "bedrock:CallWithBearerToken",
"Resource": "*"
},
{
"Sid": "DenyRuntimeAdministration",
"Effect": "Deny",
"Action": [
"bedrock:Create*",
"bedrock:Put*",
"bedrock:Update*",
"bedrock:Delete*",
"aws-marketplace:Subscribe",
"aws-marketplace:Unsubscribe"
],
"Resource": "*"
}
]
}Recursos amplos como foundation-model/* e inference-profile/* fazem sentido em um tutorial inicial. Em produção, comece por uma allowlist de modelos e application inference profiles habilitados, testados, orçados e registrados. Quando você permitir inference profiles cross-region, inclua os ARNs dos foundation models de suporte em cada Região para a qual o perfil pode rotear; caso contrário, engenheiros podem receber erros AccessDenied confusos mesmo quando o ARN do perfil está permitido. Considere uma SCP no AWS Organizations para negar chamadas Bedrock fora das Regiões aprovadas, negar bedrock:CallWithBearerToken, negar modelos não aprovados e bloquear ações de Marketplace nas roles de runtime.
Passo 4: Configurar Variáveis de Ambiente
Mantenha a Região explícita mesmo que versões atuais do Claude Code consigam resolvê-la a partir da configuração AWS. Variáveis explícitas tornam rollouts scriptados mais determinísticos e evitam divergência entre acesso a modelos, logging de invocação, budgets e dashboards CloudWatch.
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_PROFILE=your-bedrock-profile
export AWS_REGION=us-east-1
export ANTHROPIC_DEFAULT_SONNET_MODEL=us.anthropic.claude-sonnet-4-6
export ANTHROPIC_DEFAULT_HAIKU_MODEL=us.anthropic.claude-haiku-4-5-20251001-v1:0
export ANTHROPIC_DEFAULT_OPUS_MODEL=us.anthropic.claude-opus-4-8Segundo a documentação do Claude Code no Amazon Bedrock, a partir do Claude Code v2.1.172 a Região do Bedrock é resolvida por AWS_REGION, depois AWS_DEFAULT_REGION, depois pela Região do perfil AWS ativo nos arquivos compartilhados de credenciais/configuração, e por fim us-east-1. Versões mais antigas dependiam mais estritamente de AWS_REGION. Use /status para confirmar a Região resolvida antes do rollout.
Passo 5: Configurar Autenticação AWS
| Método | Melhor para | Postura de produção |
|---|---|---|
| AWS SSO / IAM Identity Center | Engenheiros com identidade centralizada | Padrão recomendado. Execute aws sso login --profile=<profile> e defina AWS_PROFILE. |
| Credenciais temporárias de role | Cloud workstations, CI ou acesso intermediado | Recomendado quando as credenciais são temporárias, escopadas e auditáveis. |
| Chaves de acesso IAM | Casos legados ou contas de serviço estreitas | Evite em workstations humanas quando houver alternativa. |
| Chaves de API Bedrock | Exploração e prototipagem | Não use como baseline enterprise. Negue bedrock:CallWithBearerToken em roles de runtime. |
Para SSO com renovação de credenciais, adicione awsAuthRefresh na configuração do Claude Code:
{
"awsAuthRefresh": "aws sso login --profile your-bedrock-profile",
"env": {
"AWS_PROFILE": "your-bedrock-profile",
"AWS_REGION": "us-east-1"
}
}Chaves de API Bedrock são úteis para exploração rápida porque evitam setup completo de credenciais AWS. Elas também são credenciais bearer. Para uma postura enterprise segura, prefira SSO ou credenciais AWS temporárias, mantenha a política de runtime estreita e negue explicitamente invocação via bearer token nas roles de desenvolvedores.
Passo 6: Fixar Versões de Modelos
Crítico para estabilidade em produção. Fixe os IDs de modelo ou inference profile do Bedrock que foram validados na sua conta. Os IDs de exemplo abaixo refletem uma visão validada em uma conta us-east-1 em 30 de junho de 2026. Disponibilidade de modelos muda por Região, conta, endpoint e timing de lançamento, então não assuma que um ID de exemplo está habilitado antes de confirmar na AWS. Para contexto de seleção de modelo, use o guia de benchmark do Claude Opus 4.8; mantenha este guia focado nos controles de rollout no Bedrock.
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_PROFILE=your-bedrock-profile
export AWS_REGION=us-east-1
export ANTHROPIC_DEFAULT_SONNET_MODEL=us.anthropic.claude-sonnet-4-6
export ANTHROPIC_DEFAULT_HAIKU_MODEL=us.anthropic.claude-haiku-4-5-20251001-v1:0
export ANTHROPIC_DEFAULT_OPUS_MODEL=us.anthropic.claude-opus-4-8Valide a disponibilidade atual antes do rollout:
aws bedrock list-foundation-models --region us-east-1 --by-provider Anthropic
aws bedrock list-inference-profiles --region us-east-1Em produção, roteie famílias de modelos por application inference profiles para aplicar tags, budgets, métricas e controle de promoção por equipe ou projeto. O formato de configuração abaixo é conceitual; valide o contrato atual de settings do Claude Code no seu ambiente antes de copiá-lo para managed settings:
{
"modelOverrides": {
"claude-opus-4-8": "arn:aws:bedrock:us-east-1:123456789012:application-inference-profile/opus-48-prod",
"claude-sonnet-4-6": "arn:aws:bedrock:us-east-1:123456789012:application-inference-profile/sonnet-46-prod",
"claude-haiku-4-5-20251001": "arn:aws:bedrock:us-east-1:123456789012:application-inference-profile/haiku-45-prod"
}
}Mantenha ARNs amplos de modelos apenas em tutoriais. A postura de produção é uma allowlist explícita, com processo de mudança para adicionar ou retirar modelos.
Passo 7: Habilitar AWS Guardrails (Opcional)
Crie um Guardrail no console Bedrock, publique uma versão e adicione os headers:
{
"env": {
"ANTHROPIC_CUSTOM_HEADERS": "X-Amzn-Bedrock-GuardrailIdentifier: your-guardrail-id\nX-Amzn-Bedrock-GuardrailVersion: 1"
}
}Inferência Cross-Region
Perfis de inferência cross-region (IDs prefixados com us. ou eu.) permitem que o Bedrock roteie requisições entre regiões configuradas para melhorar throughput e performance. Habilite inferência cross-region nos seus Guardrails se estiver usando esses perfis.
Cenário 2: Claude Desktop Cowork on 3P com Bedrock
Como habilitar o setup UI
Para avaliação em uma máquina, a documentação oficial indica abrir o Claude Desktop, ir em Help -> Troubleshooting -> Enable Developer mode e depois Developer -> Configure third-party inference. Essa tela valida os campos do provider e exporta um arquivo .mobileconfig no macOS ou .reg no Windows para distribuição por MDM. Para rollout, prefira MDM em vez de configuração manual por usuário.
Configuração Bedrock mínima
As chaves relevantes para Bedrock são inferenceProvider=bedrock, inferenceBedrockRegion, um método de credencial e inferenceModels. A Anthropic documenta dois métodos de autenticação: inferenceBedrockBearerToken, que exige bedrock:CallWithBearerToken no principal subjacente, ou inferenceBedrockProfile, que usa um perfil AWS do ~/.aws/config e exige bedrock:InvokeModel e bedrock:InvokeModelWithResponseStream para os perfis de inferência e modelos usados. Se a organização usa AWS SSO, o perfil AWS é o caminho mais natural para piloto; para produção, valide renovação de credenciais e distribuição via MDM.
{
"enterpriseConfig": {
"inferenceProvider": "bedrock",
"inferenceBedrockRegion": "us-east-1",
"inferenceBedrockProfile": "claude-bedrock",
"inferenceModels": "[\"us.anthropic.claude-sonnet-4-5-20250929-v1:0\"]",
"deploymentOrganizationUuid": "REPLACE_WITH_REAL_UUID"
}
}Importante: chaves do tipo array, como inferenceModels, precisam ser gravadas como JSON string. Em .mobileconfig, isso significa um único valor string contendo [...], não um array nativo do plist. Configure um UUID real para deploymentOrganizationUuid antes do rollout; se você deixar um placeholder compartilhado, a telemetria fica marcada com um valor genérico que a Anthropic não consegue diferenciar de outros deployments sem configuração. Para Bedrock, use IDs de modelo ou perfis de inferência disponíveis na região escolhida e valide com aws bedrock list-inference-profiles antes do rollout.
Base URL, PrivateLink e gateway Bedrock
Se você deixar inferenceBedrockBaseUrl vazio, o Desktop usa o endpoint regional público do Bedrock. Para ambientes que precisam de caminho privado, a chave pode apontar para um endpoint Bedrock via PrivateLink ou para um LLM gateway que represente o Bedrock, sempre usando https://. Mesmo com gateway, mantenha o escopo como Bedrock: IAM, CloudTrail, região, modelo, cota e custo continuam sendo as decisões principais.
Code tab: ainda valide separadamente
A aba Code no Cowork on 3P usa o mesmo motor do Claude Code CLI, mas a própria Anthropic avisa que algumas chaves do Cowork on 3P ainda não propagam para sessões da aba Code do mesmo jeito que se aplicam à aba Cowork. Para deployment enterprise, trate a aba Code como validação separada e distribua também o managed-settings.json do Claude Code quando precisar fixar políticas, modelos ou sandboxing diretamente para sessões de código.
Checklist de validação do Desktop 3P + Bedrock
- Confirmar versão do Claude Desktop e que o setup UI de third-party inference aparece.
- Validar
inferenceProvider=bedrock, região, perfil AWS ou bearer token e modelos expostos. - Confirmar que o perfil AWS dentro do sandbox resolve credenciais e renova via SSO ou credential process.
- Testar Cowork e Code separadamente com um repositório pequeno antes de liberar monorepos.
- Configurar
allowedWorkspaceFolders,coworkEgressAllowedHosts, ferramentas desabilitadas, OTel e limites de token quando aplicável. - Confirmar CloudTrail, budgets, métricas de Bedrock e logs locais antes de rollout amplo.
Cenário 3: Modelos Auto-Hospedados na AWS
Organizações que precisam executar modelos open-source ou de terceiros podem hospedá-los na sua VPC e conectar o Claude Code a esses endpoints. Isso oferece controle total sobre seleção de modelos, residência de dados e custos, mas requer gerenciamento de infraestrutura e vem com limitações de compatibilidade.
Provisionar Computação GPU
| Família | GPU | Caso de Uso |
|---|---|---|
| p4d / p4de | NVIDIA A100 (40/80 GB) | Modelos grandes (70B+) |
| p5 | NVIDIA H100 | Maior performance |
| g5 | NVIDIA A10G | Custo-benefício (7B–34B) |
| inf2 | AWS Inferentia2 | Inferência otimizada |
Implantar Servidor de Inferência
Seu servidor deve implementar o formato da API de Mensagens da Anthropic (/v1/messages):
- vLLM (Recomendado): Suporte nativo ao formato Anthropic com inferência de alta vazão. O vLLM possui documentação específica para uso com Claude Code via sua API compatível com Anthropic.
- LiteLLM Proxy: Camada de tradução para modelos que suportam apenas endpoints OpenAI.
Notas de Compatibilidade
- Funcionalidades limitadas: Quando
ANTHROPIC_BASE_URLaponta para um host não oficial, a busca de ferramentas MCP é desabilitada por padrão, a menos que o proxy encaminhe os blocos necessários. - Segurança do LiteLLM: Esteja ciente de que as versões 1.82.7 e 1.82.8 do LiteLLM foram sinalizadas com um aviso de segurança na documentação de gateway da Anthropic. Verifique se está usando uma versão corrigida.
- Paridade de recursos: A paridade depende do servidor/proxy e das capacidades do modelo. Por exemplo, a busca de ferramentas MCP é desabilitada por padrão em hosts não oficiais, a menos que o proxy encaminhe blocos
tool_reference.
Rede e Segurança
- Servidor de inferência em sub-rede privada via VPN ou AWS Client VPN
- ALB interno com terminação TLS
- Security groups restritivos + CloudWatch para monitoramento
- AWS PrivateLink para padrões zero-trust
Configurar Claude Code
export ANTHROPIC_BASE_URL=https://your-vllm-endpoint.internal
export ANTHROPIC_AUTH_TOKEN=your-auth-tokenComparação de Cenários
| Dimensão | Claude Code + Bedrock | Desktop 3P + Bedrock | Auto-Hospedado |
|---|---|---|---|
| Melhor para | Engenheiros usando CLI | Cowork, Code, plugins e MDM com inferência no Bedrock | Modelos open-source ou terceiros na sua VPC |
| Complexidade | Baixa a média | Média; exige Desktop, MDM, credenciais e políticas locais | Alta |
| Modelos disponíveis | Família Claude no Bedrock | IDs de modelo ou perfis de inferência Bedrock configurados no Desktop | Qualquer modelo compatível com seu servidor |
| Infraestrutura | Bedrock gerenciado | Bedrock gerenciado + configuração local/MDM do Claude Desktop | Propriedade total |
| Governança | IAM, região, CloudTrail, budgets e settings do Claude Code | IAM, região, MDM, workspace folders, egress, OTel e políticas da aba Code | Rede, GPU, servidor de inferência, logs e gateway próprios |
| Tempo até piloto | Horas | Horas a dias, dependendo de MDM e SSO | Dias a semanas |
Melhores Práticas para Produção
Perfis de Inferência de Aplicação
Use application inference profiles do Bedrock para rastreamento de custos com tags e métricas CloudWatch por equipe, projeto ou ambiente. Isso fornece visibilidade granular que tags simples do Cost Explorer não conseguem. Use-os depois para atribuição por equipe e projeto quando o rollout inicial estiver estável.
Cache de Prompt
O Claude Code é um caso de uso forte para prompt caching do Bedrock, que pode reduzir significativamente latência e custos para contextos de sistema repetitivos e conteúdo de codebase. Verifique a disponibilidade regional, pois o cache de prompt pode não estar disponível em todas as Regiões.
Gateway LLM Enterprise
Para autenticação centralizada, rate limiting e controles de custo, você pode implantar um LLM Gateway na frente do Bedrock via ANTHROPIC_BEDROCK_BASE_URL. Se o gateway ou um caminho auto-hospedado bypassar a invocação do Bedrock runtime, implemente logging centralizado equivalente de requisições/respostas, atribuição de identidade, retenção e controles de acesso, porque o invocation logging nativo do Bedrock não cobre mais o caminho completo.
Observabilidade e Auditoria
Não trate OpenTelemetry local do Claude Code como fonte de auditoria. Ele é útil para adoção, latência, UX, métricas de terminal/ferramentas e análise de experiência de desenvolvedor, mas não pode ser exigido de todos os terminais e não substitui evidência AWS-side.
O baseline de auditoria em produção é Bedrock model invocation logging para CloudWatch Logs e/ou S3, somado a CloudTrail e telemetria de billing/custos. CloudTrail registra atividade de API no Amazon Bedrock, mas captura de prompt e resposta exige Bedrock invocation logging. Em produção, use CloudWatch Logs para revisão operacional e S3 para retenção de longo prazo e entrega de payloads grandes. Payloads grandes, dados de imagem e dados de documentos podem ser entregues ao S3, então o bucket de logs é dado sensível de produção e precisa de revisão própria de acesso.
Há também um limite duro: AWS model invocation logging é atualmente suportado para chamadas pelo endpoint bedrock-runtime, incluindo InvokeModel e InvokeModelWithResponseStream. A AWS informa que chamadas por outros endpoints, como a Responses API em bedrock-mantle, não são capturadas atualmente por invocation logging. Se você usa Mantle, gateway ou modelos auto-hospedados, desenhe logging equivalente antes de chamar o rollout de auditável.
Guardrails de Política IAM
- Não dê
aws-marketplace:Subscribea engenheiros em roles de runtime do dia a dia. - Não dê permissões de logging, acesso a modelos ou administração do Bedrock em roles de runtime.
- Prefira uma allowlist de inference profiles e IDs de modelos aprovados.
- Adicione denies explícitos para chamadas fora das Regiões aprovadas/com logging,
bedrock:CallWithBearerToken, ações create/update/delete/admin do Bedrock e subscribe/unsubscribe do Marketplace.
Terraform e State
Mantenha infraestrutura separada de helpers e templates. Coloque logging do Bedrock, budgets, profiles, IAM e guardrails em infra/bedrock; faça bootstrap do backend de state separadamente em infra/state-backend. O backend deve usar versionamento S3, criptografia SSE-KMS, Block Public Access e locking em DynamoDB. Mantenha Terraform state e tfvars fora do git.
Custo e Créditos
Não assuma que créditos promocionais ou funding AWS cobrem todos os caminhos. Confirme se Bedrock, API Gateway, CloudWatch Logs, S3, NAT e qualquer gateway estão cobertos antes do rollout. Crie um budget específico para Bedrock, um budget total da conta e uma subscription de anomalia. Meça valor como custo por tarefa concluída com sucesso, não apenas gasto de tokens.
Segurança e Compliance
Habilite CloudTrail, Bedrock invocation logging, controles de retenção, criptografia KMS e revisões de acesso para cada destino de log. Use Guardrails quando filtragem de conteúdo for necessária, mas trate-os como um controle no caminho da requisição, não como substituto de IAM, logging e gates de aprovação. Para modelos auto-hospedados ou via gateway, implemente logging de acesso no servidor de inferência e captura centralizada de requisição/resposta antes de produção.
Solução de Problemas
- Problemas de região:
aws bedrock list-inference-profiles --region your-region - Erro "On-demand throughput isn't supported": Use ID de perfil de inferência em vez de ID de modelo base.
- Expiração de credenciais: Configure
awsAuthRefreshpara re-autenticação automática. - Endpoint auto-hospedado: Deve implementar
/v1/messages. Use LiteLLM Proxy (versão corrigida) para endpoints apenas OpenAI. - Desktop 3P não inicia em modo Bedrock: confirme
inferenceProvider=bedrock, credencial válida,inferenceBedrockRegioneinferenceModelscomo JSON string. - Aba Cowork funciona, mas Code não segue a mesma política: valide a aba Code separadamente e distribua
managed-settings.jsondo Claude Code quando precisar fixar políticas para sessões de código.
Nota: O Claude Code usa a API Invoke do Bedrock e não suporta a API Converse.
Perguntas Frequentes
Qual infraestrutura eu preciso para implantar o Claude Code na AWS?
No mínimo, você precisa de uma conta AWS com acesso ao Bedrock ou um endpoint privado compatível com Anthropic, permissões IAM para acesso a modelos e subscrição no Marketplace, configuração explícita de região e rede, além de controles operacionais como fixação de modelos, logging e guardrails.
O Bedrock inclui o Claude na web?
Não como experiência SaaS padrão. O Bedrock fornece a API de modelo e serviços de desenvolvimento AWS; os apps Claude web/iOS/Android, administração do plano, histórico hospedado, Projects, Artifacts e conectores gerenciados continuam sendo parte dos planos Claude Team e Enterprise. O que mudou é o Desktop: o Claude Desktop pode usar Bedrock no modo Cowork on 3P, com inferência no Bedrock, armazenamento local e configuração via MDM/sistema operacional.
O Claude Desktop agora pode usar Bedrock sem enviar conversas para a infraestrutura da Anthropic?
Sim, para o modo Cowork on 3P com inferenceProvider=bedrock, a Anthropic documenta que prompts, respostas, arquivos e saídas de ferramentas são enviados ao endpoint de inferência configurado e armazenados no dispositivo local, não na infraestrutura first-party da Anthropic. Ainda assim, crash reports, analytics, updates, OTel, egress e políticas locais precisam ser configurados conforme o perfil de segurança da organização.
Preciso de aprovação para acessar modelos?
Não é uma fila de aprovação manual. Com as permissões AWS Marketplace corretas, complete o formulário de Primeiro Uso da Anthropic e o acesso é concedido imediatamente. A configuração inicial pode levar alguns minutos.
Chaves de API Bedrock são seguras para produção?
Chaves de API Bedrock podem ser úteis para exploração, mas não são recomendadas para workstations humanas em produção. Prefira SSO ou credenciais temporárias de role, e negue bedrock:CallWithBearerToken em roles de runtime salvo exceção estreita e aprovada.
O que não funciona com modelos auto-hospedados?
A paridade depende do servidor/proxy e das capacidades do modelo. A ressalva mais bem documentada é a busca de ferramentas MCP: ela é desabilitada por padrão em hosts não oficiais, a menos que o proxy encaminhe blocos tool_reference. Versões específicas do LiteLLM (1.82.7–1.82.8) têm alertas de segurança conhecidos.
Como a Elevata Pode Ajudar
Configurar o Claude Code é apenas o começo. Como AWS Advanced Tier Services Partner com a Competência AWS de IA Generativa, a Elevata ajuda organizações a construir a plataforma completa de desenvolvimento com IA na AWS.
- Implantação do Claude Code e Claude Cowork no Amazon Bedrock — setup completo para Bedrock, Claude Desktop 3P, Cowork on 3P e auto-hospedados, incluindo IAM, MDM, configurações gerenciadas, perfis AWS, controles da aba Code e automação de onboarding.
- Infraestrutura de IA — dimensionamento de GPU, otimização de inferência, perfis de aplicação, cache de prompt, Bedrock invocation logging, enriquecimento OTel e dashboards de custo/uso.
- Design de plano híbrido — decidir onde Bedrock e Claude Team/Enterprise se encaixam e construir as integrações.
- Elevata Orbit — engenheiros AWS sêniores sob demanda para setup, otimização e operações contínuas.
Entre em contato em elevata.io para discutir sua implantação do Claude Code, estratégia de IA ou necessidades de infraestrutura AWS.





