Codex fonctionne désormais via Amazon Bedrock : AWS présente un pilote basé sur IAM, sans nouvelle pile technique

Quand une entreprise veut distribuer à ses développeurs un agent IA pour le code, elle finit souvent par monter une seconde infrastructure : des clés distinctes, une facturation distincte, un audit distinct. Pour l'équipe plateforme, c'est un casse-tête inutile. AWS a publié un guide détaillé expliquant comment faire passer Codex par Amazon Bedrock sans multiplier les piles parallèles.

Codex continue de s'exécuter sur le poste de travail du développeur. Seul l'itinéraire change : les requêtes vers les modèles OpenAI pris en charge transitent par Bedrock. Les exemples utilisent GPT-5.6 Sol, mais avant de démarrer, il faut vérifier séparément si Sol, Terra ou Luna sont disponibles dans le compte, la région et le chemin d'inférence voulus. Leur disponibilité peut différer.

Trois voies, une par défaut

AWS propose trois options.

• Native AWS Access. Connexion via IAM Identity Center, sans service supplémentaire. C'est le point de départ recommandé.
• AgentCore Gateway. Une passerelle gérée d'AWS pour le routage et Bedrock Guardrails.
• LLM Gateway, comme LiteLLM sur ECS ou Portkey. Adaptée si vous disposez déjà d'une telle passerelle ou si vous avez besoin de budgets et de limites stricts directement sur le chemin de la requête.

AWS qualifie explicitement l'intégration personnalisée d'option avancée de passerelle, et non de démarrage rapide. C'est un service de plus qu'il faudra concevoir, sécuriser et maintenir.

La règle est simple : choisissez la voie la plus légère qui répond à vos exigences. Pour un pilote, l'accès natif suffit généralement.

À quoi ressemble un pilote sûr

Les collaborateurs se connectent via leur fournisseur habituel, par exemple Okta en SAML. Celui-ci fournit utilisateurs et groupes à IAM Identity Center via SCIM, qui émet à son tour des clés AWS temporaires pour Codex. Aucun fournisseur d'identité n'est configuré dans Codex lui-même.

La vérification se déroule en trois étapes.

1. Se connecter avec aws sso login et appeler directement bedrock-runtime converse avec le modèle voulu. En cas de problème, cela révèle immédiatement une erreur de profil, de région ou de droits IAM, et non dans Codex.
2. Renseigner dans ~/.codex/config.toml le fournisseur amazon-bedrock, le modèle, le profil et la région.
3. Lancer une tâche sans risque dans un dépôt hors production.

Il vaut mieux conserver la configuration dans un fichier utilisateur ou géré, afin que le dépôt ne puisse pas remplacer le fournisseur. Avant le démarrage, il faut aussi désigner la personne responsable du retour arrière.

AWS demande en outre de vérifier l'isolation des identités. Un seul utilisateur prouve uniquement que la connexion fonctionne. Deux personnes lancent la même tâche anodine, et leurs sessions, leur audit et leur télémétrie doivent rester séparés. Le retour arrière se teste aussi : on supprime le paramètre ou l'attribution dans Identity Center, on attend la fin de la session, puis on vérifie qu'un nouvel appel est refusé.

Observabilité et coûts : ne pas confondre les sources

L'atout principal du guide est qu'il ne mélange pas les différents types de données.

• La télémétrie de Codex via OpenTelemetry montre l'activité du client : tokens, tours, appels d'outils. On ne peut la rattacher à des personnes qu'après qu'un collecteur local a ajouté des attributs d'identité vérifiés.
• Les métriques et journaux de Bedrock montrent ce qui s'est passé côté service.
• L'identité et l'argent proviennent de l'audit AWS et du rapport CUR. Pour l'accès natif, CUR 2.0 avec allocation par caller identity peut afficher le principal SSO.

Le volume de tokens ne doit pas passer pour un rapport de dépenses. Prenez le coût réel dans la facturation et signalez toute allocation estimative comme une estimation.

Pour le pilote, le dépôt contient une configuration prête à l'emploi du collecteur ADOT et un tableau de bord CloudWatch.

Limites et marche à suivre

Le guide a été rédigé par l'équipe plateforme d'AWS pour ses propres services ; il ne dit donc rien des alternatives extérieures à l'écosystème. La télémétrie ne prouve pas la justesse du code : la revue et les tests des modifications générées restent obligatoires. Les secrets et les données confidentielles ne doivent pas transiter par le modèle tant que ce n'est pas explicitement approuvé.

Avant un déploiement par équipes, il convient de standardiser l'environnement. Les plugins de l'organisation diffusent des compétences et des hooks ; chacun doit avoir un responsable et une version. Les serveurs MCP ouvrent une frontière de confiance distincte : n'y donnez accès qu'aux personnes et outils nécessaires, et gardez les identifiants hors de la configuration du fournisseur du modèle. Testez les hooks comme PreToolUse sur les scénarios allow, deny, expiration du délai et point de terminaison désactivé.

La conclusion pratique pour l'équipe plateforme est la suivante. Commencez avec deux personnes, l'accès natif et un plan de retour arrière clair. N'étendez le déploiement qu'une fois que les preuves concernant l'identité, les appels et les coûts concordent. Ajoutez une passerelle lorsque vous avez besoin de limites strictes, et non simplement parce qu'elle existe.