A AWS apresentou o Claude apps gateway for AWS em 8 de julho de 2026: um plano de controle self-hosted que coloca identidade, política, telemetria, roteamento e gasto de Claude Code e Claude Desktop atrás de um único gateway, em vez de deixar cada laptop gerenciar suas próprias credenciais cloud e o acesso a modelos. Quando o próprio fornecedor da plataforma entrega isso como produto de primeira linha, diz algo sobre como os agentes de código devem ser operados: não ferramenta a ferramenta em cada laptop, mas através de uma camada de governança que a organização controla. Para a maioria dos times, a pergunta deixou de ser se desenvolvedores alcançam modelos de fronteira. É onde identidade, custo e auditoria vivem quando esses agentes estão em todo lugar.
Nosso gateway para Amazon Bedrock começou com Claude Code e o requisito logo se ampliou. Equipes de engenharia não vivem em uma única superfície de IA; elas alternam entre agentes de terminal, assistentes desktop e ferramentas que falam APIs compatíveis com OpenAI. Por isso estendemos o mesmo plano de controle para Claude Code, Claude Desktop em modo Bedrock de terceiros e Codex, todos roteados por infraestrutura AWS governada. Este é um relato do que isso exigiu e de onde as decisões de arquitetura realmente pesaram.
O plano de controle está virando padrão
Um gateway assim vira o ponto de controle único: máquinas de desenvolvedores deixam de guardar credenciais cloud de longa duração, e o acesso a modelos deixa de depender do que cada ferramenta local oferece. O gateway segura a credencial upstream, centraliza login OIDC e política gerenciada, roteia para o Amazon Bedrock ou o Claude Platform on AWS, aplica limites de gasto e emite tokens de curta duração para os clientes — tudo em infraestrutura que você opera. Um fornecedor de plataforma entregando isso de fábrica é o sinal que importa: move o padrão de algo que poucos times montam à mão para a forma esperada de operar agentes de código em uma organização. Nosso próprio gateway segue a mesma tese; o que muda é o alcance de superfícies de cliente que ela cobre, não o princípio.
| Pergunta | Resposta prática |
|---|---|
| O que está virando padrão? | Um plano de controle self-hosted para agentes de código — identidade centralizada, política gerenciada, telemetria, roteamento e limites de gasto — agora entregue como produto de primeira linha da AWS para Claude Code e Claude Desktop. |
| O que a Elevata acrescenta? | O mesmo padrão de acesso governado estendido a Claude Code, Claude Desktop 3P em Bedrock e Codex. |
| O que não deve ser inferido? | Codex não faz parte do anúncio do Claude apps gateway for AWS. É uma extensão implementada pela Elevata sobre a mesma tese arquitetural. |
A extensão da Elevata
Mesmo plano de controle, alcance maior. A tabela abaixo se lê como um conjunto de decisões de arquitetura: onde nosso gateway acompanha o padrão da AWS e onde ele vai além para cobrir uma terceira superfície de cliente.
| Área | Claude apps gateway for AWS | Gateway da Elevata |
|---|---|---|
| Clientes primários | Claude Code e Claude Desktop | Claude Code, Claude Desktop 3P e Codex |
| Identidade | Fronteira de identidade OIDC, tokens de curta duração | Fronteira de identidade OIDC, tokens de curta duração |
| Caminho Claude Code | Fluxo Claude ciente do gateway | Roteamento nativo do Bedrock Runtime |
| Caminho Claude Desktop | Aplicativos Claude gerenciados pelo gateway | Modo provider Bedrock de terceiros |
| Caminho Codex | Não é o foco do anúncio | Endpoint compatível com OpenAI Responses roteado para o Bedrock |
| Credenciais | Gateway segura a credencial upstream | Gateway segura a credencial upstream; a task role assina as requisições ao Bedrock |
| Controle de gasto | Spend caps do gateway | Precheck, commit, reservas e limites de stream por principal e globais |
| Auditoria | Telemetria controlada pelo cliente | Invocation logs do Bedrock para caminhos nativos; registros de uso do gateway para os demais |
| Hardening operacional | Caminho de produto do gateway | Keepalives, slow-body handling, frames de exceção, telemetria streaming e testes e2e reais |
Como a arquitetura funciona
Os três clientes batem no mesmo gateway atrás de uma fronteira de identidade OIDC; o que muda por cliente é o protocolo que o gateway precisa falar e a rota que ele expõe.
Para Claude Code, roteamos chamadas nativas do Bedrock Runtime. Escolhemos o caminho nativo em vez de um fluxo ciente do Claude porque ele mantém o cliente no protocolo que já fala: o gateway autentica a requisição, verifica o estado de gasto, assina a chamada ao Bedrock com a task role, encaminha para o Amazon Bedrock e registra o uso — sem nenhuma credencial cloud no lado do cliente.
Para Claude Desktop, usamos seu modo de provider Bedrock de terceiros. O mesmo gateway fala o protocolo de provider Bedrock de terceiros, permitindo que Chat, Cowork e Claude Code for Desktop alcancem o Bedrock sem conta Claude.ai e sem credenciais AWS locais. Um helper de credencial sem argumentos entrega tokens de curta duração ao cliente, e a configuração gerenciada do Desktop limita ferramentas locais, como Bash, conforme a política da empresa.
Para Codex, expomos um endpoint compatível com OpenAI Responses para que o Codex trate o gateway como um provider compatível com OpenAI comum. Por trás desse endpoint, o gateway autentica o usuário, aplica os mesmos controles de gasto, emite um token de curta duração para o Bedrock a partir da task role e encaminha para o Bedrock. Essa é a superfície que o anúncio da AWS não cobre, e a razão de a termos construído: as equipes já a pediam.
O retorno é um plano de acesso único para clientes diferentes: cada ferramenta preserva seu protocolo e suas expectativas, enquanto identidade, custo, roteamento e auditoria ficam centralizados — e observáveis, como mostra o painel acima.
O que aprendemos
1. Tokens curtos vencem credenciais locais
O ganho mais importante não é cosmético. Quando laptops deixam de carregar credenciais cloud diretas, a empresa reduz superfície de vazamento, simplifica offboarding e força o acesso a modelos a passar por um ponto onde política e custo podem ser aplicados.
2. Streaming é uma preocupação de confiabilidade, não um detalhe de UI
O trabalho difícil não foi apenas chamar o Bedrock. Foi preservar as expectativas de cada cliente durante streaming. SSE e AWS eventstream precisam de keepalives, headers anti-buffering, caps de concorrência, tratamento de corpos lentos, parsing de telemetria limitado e frames de exceção dentro do stream. Sem isso, falhas de gateway podem parecer respostas vazias e limpas para o cliente.
3. Controle de custo precisa acontecer antes e durante a chamada
Registrar gasto depois da conclusão é necessário, mas insuficiente. O gateway faz precheck antes de encaminhar, registra uso após a conclusão, trata buckets de cache-read e cache-write quando disponíveis e reserva gasto estimado para streams ativos — para que requisições concorrentes não ultrapassem um limite antes de a contabilidade final chegar. O painel no topo deste artigo é a saída dessa contabilidade: é como enxergamos, por modelo, que o tráfego do Claude Code, intensivo em cache, roda a uma fração do custo por requisição de clientes com menos cache.
4. Política de cliente não substitui enforcement de gateway
Configurações gerenciadas em Claude Code ou Claude Desktop são úteis para experiência, padronização e redução de erro. Mas elas vivem no cliente, onde um usuário determinado pode contorná-las. Controles críticos precisam ser reforçados no gateway: identidade, modelos permitidos, gasto, roteamento upstream, limites de stream e comportamento de falha.
5. Auditoria precisa respeitar o endpoint, não só o provider
Uma armadilha comum é assumir que toda chamada ao Bedrock passa pelo mesmo plano de auditoria. Não passa. O tráfego nativo do Bedrock Runtime pode usar invocation logging do Bedrock como baseline de conteúdo e metadados; um caminho compatível com Responses reconcilia contra os próprios registros de uso do gateway até que a cobertura de invocation logging seja equivalente. Em um gateway de IA, endpoint e protocolo decidem o que sua trilha de auditoria de fato contém — projete para essa diferença em vez de mascará-la.
6. Testes e2e precisam usar clientes reais
Um teste HTTP sintético não prova que Claude Code, Claude Desktop ou Codex vão se comportar corretamente. Os testes de fumaça precisam exercitar login, credential helper, rotas Runtime, rotas do provider Desktop, endpoint compatível com Responses, streaming e os casos de erro que cada cliente realmente encontra — porque cada um falha de um jeito diferente.
Perguntas frequentes
A AWS endossou a implementação da Elevata?
Não. Este artigo descreve uma implementação da Elevata alinhada ao padrão arquitetural anunciado pela AWS. Não implica endosso, certificação ou aprovação da AWS.
Codex faz parte do Claude apps gateway for AWS?
Não. O anúncio da AWS foca Claude Code e Claude Desktop. O suporte a Codex é uma extensão da Elevata: um endpoint compatível com OpenAI Responses que o gateway roteia para o Bedrock.
Rotear pelo Bedrock expõe nossos prompts aos provedores dos modelos?
Não. O Amazon Bedrock executa cada modelo em uma conta de implantação isolada e aplica retenção zero de dados por padrão, então os provedores dos modelos não veem seus prompts ou respostas e a AWS não os armazena. A exceção hoje é o Claude Fable 5, que exige opt-in para reter o tráfego e compartilhá-lo com a Anthropic para revisão de abuso — exatamente o tipo de decisão que o gateway existe para tomar e aplicar, modelo a modelo.
Adicionar um cliente significa construir um novo gateway?
Não. A fronteira de identidade, a contabilidade de gasto e a auditoria são compartilhadas; cada novo cliente adiciona um adaptador de protocolo e uma rota, não um plano de controle paralelo. É por isso que estender de Claude Code para Claude Desktop e Codex não multiplicou a superfície que precisamos proteger.
Isso elimina a necessidade de políticas nos clientes?
Não. Políticas gerenciadas no cliente continuam importantes para experiência e padrões. A diferença é que decisões críticas também são aplicadas no gateway, onde o usuário não pode simplesmente contornar a configuração local.
Onde a governança vive
A decisão que isso força não é qual ferramenta de IA padronizar — os times vão continuar usando várias. É onde a governança vive. Coloque identidade, credenciais, custo, auditoria e roteamento em um único gateway e você pode adicionar superfícies de cliente sem transformar cada laptop em uma ilha de credenciais e políticas locais.
Se sua equipe está avaliando Claude Code, Claude Desktop, Codex ou agentes internos no Bedrock, a Elevata pode ajudar a desenhar o primeiro gateway e validá-lo com clientes reais.
Leituras relacionadas: Claude Code na AWS, Codex e OpenAI Agents no Amazon Bedrock e sandbox governado para agentes de IA na AWS.
