Codex agora roda pelo Amazon Bedrock: AWS mostra piloto com IAM, sem nova stack

Quando uma empresa quer distribuir um agente de IA para código aos desenvolvedores, o resultado costuma ser uma segunda infraestrutura: chaves separadas, faturas separadas, auditoria separada. Para o time de plataforma, isso é dor de cabeça desnecessária. A AWS publicou um guia detalhado sobre como rotear o Codex pelo Amazon Bedrock sem criar uma stack paralela.

O Codex em si continua rodando na máquina de trabalho do desenvolvedor. O que muda é só a rota: as requisições aos modelos compatíveis da OpenAI passam pelo Bedrock. Os exemplos usam o GPT-5.6 Sol, mas, antes de começar, vale verificar separadamente se Sol, Terra ou Luna estão disponíveis na conta, na região e no caminho de inferência desejados. A disponibilidade pode variar entre eles.

Três caminhos, um deles como padrão

A AWS propõe três opções.

• Native AWS Access. Login via IAM Identity Center, sem nenhum serviço adicional. É o ponto de partida recomendado.
• AgentCore Gateway. Gateway gerenciado da AWS para roteamento e Bedrock Guardrails.
• LLM Gateway, como LiteLLM no ECS ou Portkey. Serve se você já tem um gateway desse tipo ou precisa de orçamentos e limites rígidos diretamente no caminho da requisição.

A AWS classifica explicitamente a integração customizada como uma variante avançada de gateway, e não como um início rápido. É mais um serviço que precisará ser projetado, protegido e mantido.

A regra é simples: escolha o caminho mais leve que atenda aos seus requisitos. Para um piloto, o acesso nativo costuma bastar.

Como é um piloto seguro

Os funcionários entram por um provedor que já usam, como o Okta via SAML. Ele entrega usuários e grupos ao IAM Identity Center por SCIM, e o Identity Center emite chaves temporárias da AWS para o Codex. O provedor de identidade não é configurado no Codex em si.

A validação tem três etapas.

1. Fazer login com aws sso login e chamar diretamente bedrock-runtime converse com o modelo desejado. Se algo estiver quebrado, isso mostra de imediato o problema no perfil, na região ou nas permissões do IAM, e não no Codex.
2. Registrar em ~/.codex/config.toml o provedor amazon-bedrock, o modelo, o perfil e a região.
3. Executar uma tarefa segura em um repositório que não seja de produção.

O ideal é manter a configuração em um arquivo do usuário ou gerenciado, para que o repositório não consiga trocar o provedor. Antes mesmo de começar, é preciso designar a pessoa responsável pelo rollback.

A AWS também pede que se verifique o isolamento de identidades. Um único usuário só prova que o login funciona. Dois usuários executam a mesma tarefa inofensiva, e suas sessões, auditoria e telemetria devem permanecer separadas. O rollback também é testado: remove-se a configuração ou a atribuição no Identity Center, espera-se a sessão expirar e confirma-se que uma nova chamada é recusada.

Observabilidade e custo: não misture as fontes

O mais útil no guia é que ele não mistura tipos diferentes de dados.

• A telemetria do Codex via OpenTelemetry mostra a atividade do cliente: tokens, turnos, chamadas de ferramentas. Só é possível associá-la a pessoas depois que um coletor local adicionar atributos de identidade verificados.
• As métricas e os logs do Bedrock mostram o que aconteceu no lado do serviço.
• Identidade e dinheiro vêm da auditoria da AWS e do relatório CUR. No acesso nativo, o CUR 2.0 com alocação por caller identity pode mostrar o principal do SSO.

O volume de tokens não pode ser apresentado como relatório de gastos. Use o preço real do faturamento e marque qualquer alocação estimada como estimativa.

Para o piloto, o repositório traz uma configuração pronta do coletor ADOT e um dashboard do CloudWatch.

Limitações e o que fazer

O guia foi escrito pelo time de plataforma da AWS para os serviços da própria AWS, por isso não diz nada sobre alternativas fora desse ecossistema. A telemetria não prova a correção do código, então a revisão e os testes das mudanças geradas continuam obrigatórios. Segredos e dados confidenciais não podem ser enviados pelo modelo enquanto isso não for explicitamente aprovado.

Antes de expandir para os times, vale padronizar o ambiente. Os plugins da organização distribuem skills e hooks, e cada um deve ter dono e versão. Servidores MCP abrem uma fronteira de confiança própria: libere o acesso apenas às pessoas e ferramentas necessárias e mantenha as credenciais fora da configuração do provedor do modelo. Hooks como o PreToolUse devem ser testados nos cenários de allow, deny, timeout e endpoint desativado.

A conclusão prática para o time de plataforma é esta. Comece com duas pessoas, acesso nativo e um plano claro de rollback. Só expanda depois que as evidências de identidade, chamadas e custos baterem. Adicione um gateway quando precisar de limites rígidos, e não simplesmente porque ele existe.