LiteLLM sur Bedrock : la passerelle qui budgétise vos agents IA

Comment empêcher un agent de codage IA de dépasser son budget mensuel sans bloquer les développeurs qui en ont besoin ? AWS a publié le 3 septembre 2026 un guide de déploiement complet qui répond à cette question avec une architecture concrète : faire transiter OpenAI Codex par une passerelle LiteLLM auto-hébergée sur Amazon ECS, devant Amazon Bedrock. Ce n'est pas une astuce de configuration, c'est un patron d'architecture complet, avec ses coûts et ses angles morts assumés.

Le contexte

Une passerelle LLM (ou « LLM gateway ») est un service qui s'intercale entre les outils de vos développeurs et les modèles d'IA qu'ils appellent. Plutôt que chaque développeur détienne sa propre clé API vers un fournisseur de modèle, tout le trafic passe par un point de contrôle unique qui peut appliquer des quotas, tracer la consommation et masquer les identifiants réels. LiteLLM est un projet open source qui joue ce rôle : une API unifiée devant plus de 140 fournisseurs de modèles, avec des contrôles de coût et de gouvernance pensés pour les équipes plateforme. Le guide AWS documente comment le déployer soi-même sur ECS pour gouverner l'accès à Amazon Bedrock — ici, dans le cas précis d'OpenAI Codex utilisé comme agent de codage.

Une architecture LiteLLM entièrement définie en infrastructure as code

Le déploiement de référence repose uniquement sur des briques AWS managées, orchestrées par CloudFormation :

Amazon ECS sur Fargate héberge les conteneurs de la passerelle LiteLLM
Application Load Balancer + AWS WAF filtrent et contrôlent le trafic entrant
Amazon RDS (PostgreSQL) stocke l'état de LiteLLM, les métriques d'usage et les données de budget
AWS Secrets Manager + AWS KMS gèrent les identifiants et le chiffrement des clés
Amazon ECR conserve une image de conteneur immuable
Amazon CloudWatch centralise logs, alarmes et Container Insights

Le flux de bout en bout suit cinq étapes : Codex envoie le contexte de tâche et ses définitions d'outils vers l'endpoint /v1/responses de la passerelle ; l'ALB et le WAF appliquent leurs contrôles avant de router la requête vers LiteLLM sur Fargate ; LiteLLM authentifie l'appelant, valide la politique associée, puis invoque le modèle Bedrock via le rôle IAM de la tâche ECS ; Bedrock répond avec du texte ou des appels de fonction, relayés par LiteLLM ; Codex exécute localement les outils approuvés et renvoie le résultat à la requête suivante.

Immuabilité et rollback automatique

Le déploiement utilise une image Docker à empreinte figée (digest), poussée sur ECR puis fournie telle quelle à CloudFormation — jamais un tag mutable. Le service ECS embarque un circuit-breaker de déploiement qui déclenche un rollback automatique en cas d'échec, avec des health checks portés par l'Application Load Balancer. L'autoscaling à seuils cible fait varier la flotte entre 2 et 10 tâches dans la configuration de référence, et RDS peut être configuré en multi-AZ avec sauvegardes automatiques.

Un alias, jamais l'identifiant réel du fournisseur

Les correspondances entre alias et modèles Bedrock sont figées dans un fichier litellm_config.yaml, reconstruit dans l'image du conteneur à chaque déploiement — par exemple, l'alias gpt-5.5 pointe en interne vers bedrock_mantle/openai.gpt-5.5. Côté développeur, Codex ne voit que l'alias stable : la passerelle absorbe tout changement de fournisseur, de région ou de version de modèle sans qu'un seul poste de travail n'ait à être reconfiguré. C'est ce découplage qui rend le patron portable au-delà de Bedrock — le même LiteLLM peut, en théorie, router certains alias vers d'autres fournisseurs de modèles sans toucher au code appelant.

LiteLLM applique des quotas par clé, pas par développeur au hasard

Le cœur du patron réside dans l'attribution d'identité : chaque équipe ou développeur reçoit sa propre clé API de passerelle — jamais l'identifiant maître — provisionnée via l'API /key/generate de LiteLLM et stockée dans un secret Secrets Manager chiffré par KMS. Côté Codex, la clé est récupérée à l'exécution par un script Python qui appelle l'AWS CLI, sans jamais transiter par un fichier de configuration en clair.

Sur chaque clé, LiteLLM applique des politiques de consommation concrètes : un budget maximal (l'exemple du guide fixe 50 $ sur 30 jours), une limite de tokens par minute (100 000 dans l'exemple), une limite de requêtes par minute (1 000) et une liste de modèles autorisés (restreinte à un seul alias dans l'exemple donné). Dès qu'un seuil est franchi, LiteLLM rejette directement la requête suivante — pas d'alerte a posteriori, pas de facture surprise en fin de mois.

Une télémétrie pensée pour la responsabilité, pas seulement le débogage

La page de logs de requêtes de LiteLLM enregistre, pour chaque appel : le statut de succès ou d'échec, l'alias de clé (donc l'identité du développeur, alors que Bedrock ne voit que le rôle IAM de la tâche ECS), le modèle réellement résolu, le nombre de tokens, la durée de la requête et le temps jusqu'au premier token. Une tâche qui utilise des outils génère plusieurs lignes de log, ce qui matérialise clairement la frontière : LiteLLM gouverne et enregistre les appels au modèle, Codex exécute les outils localement sur le poste du développeur.

Ce que ça change pour les équipes IA

Ce patron s'oppose frontalement à une autre approche de gouvernance des dépenses IA sur Bedrock que nous avons couverte récemment sur ce blog : celle de Jamf, qui pilote des quotas de dépenses directement au niveau des politiques IAM, sans aucune infrastructure supplémentaire à opérer. Les deux patrons répondent au même besoin — éviter la facture Bedrock qui explose sans contrôle — avec des compromis diamétralement opposés.

Le patron IAM pur (Jamf) ne nécessite aucun service à faire tourner : la restriction vit dans la couche d'autorisation native du cloud. Mais il n'offre pas de granularité fine par requête, pas de journal de conversation détaillé, et reste spécifique à Bedrock. Le patron passerelle (LiteLLM sur ECS) offre l'inverse : granularité par clé et par requête, portabilité vers d'autres fournisseurs de modèles, observabilité riche — au prix d'une infrastructure supplémentaire à faire vivre. Le guide AWS est honnête sur ce compromis : « votre équipe possède la disponibilité de la passerelle, le cycle de vie de la base de données, les montées de version, la réponse aux incidents et la planification de capacité ». Ce n'est pas un détail — c'est un nouveau système en production, avec son astreinte.

Trois enseignements directement exploitables pour une équipe qui opère des agents IA :

Le choix du patron dépend de la maturité de l'équipe. Une petite équipe avec un besoin simple gagnera à démarrer par l'accès IAM direct via IAM Identity Center — moins de pièces mobiles, traçabilité native via AWS CloudTrail. Une passerelle dédiée se justifie quand la granularité par équipe, le multi-fournisseur ou l'observabilité fine deviennent des besoins réels, pas hypothétiques.
Les quotas ne remplacent pas le filtrage de contenu. Le guide est explicite : les contrôles de LiteLLM (budgets, limites de débit) ne suffisent pas seuls en production — il faut activer Amazon Bedrock Guardrails sur le chemin d'accès au modèle pour le filtrage de contenu, la détection de sujets interdits et les vérifications de grounding. Gouverner la dépense et gouverner le contenu sont deux problèmes distincts.
Un script de validation de contrat n'est pas un test de charge. Le guide insiste : avant la production, il faut aussi tester les sessions d'agents concurrentes, les flux longue durée, l'annulation de requête, la révocation de clé et la reprise après échec — au-delà de la simple compatibilité du contrat /v1/responses.

Le guide signale aussi une alternative managée, Portkey, pour les équipes qui veulent les bénéfices d'une passerelle sans opérer l'infrastructure — au prix d'un contrôle plus limité et d'une dépendance fournisseur à évaluer au cas par cas.

Deux points opérationnels, moins visibles mais tout aussi engageants, méritent d'être anticipés avant de reproduire ce patron. D'abord, la disponibilité des modèles varie selon le compte et la région AWS — le déploiement de référence n'a été validé que sur us-east-1, ce qui implique de revérifier soi-même la disponibilité avant tout déploiement dans une autre région. Ensuite, la question de la journalisation des prompts et réponses ne se tranche pas par défaut : le guide invite explicitement à traiter ce contenu comme une donnée client potentiellement sensible, avec sa propre politique de rédaction, de chiffrement, de contrôle d'accès et de rétention — y compris après la suppression de la pile CloudFormation, qui conserve par défaut les snapshots RDS, les clés KMS, les secrets et les logs CloudWatch selon la politique de rétention en vigueur.

En bref

AWS documente un déploiement LiteLLM auto-hébergé sur ECS Fargate devant Amazon Bedrock pour gouverner l'accès d'OpenAI Codex, publié le 3 septembre 2026.
Chaque développeur reçoit une clé de passerelle dédiée avec budget, limites de débit et modèles autorisés propres — la requête suivante est rejetée dès le seuil franchi.
La télémétrie par requête (statut, tokens, durée, temps au premier token) préserve l'identité développeur alors que Bedrock ne voit que le rôle IAM de la tâche ECS.
Ce patron passerelle s'oppose à l'approche IAM pure (comme chez Jamf) : plus de granularité et de portabilité, au prix d'une infrastructure supplémentaire à opérer.
Le guide rappelle que les quotas ne remplacent pas le filtrage de contenu (Bedrock Guardrails) et qu'un script de compatibilité n'est pas un test de charge.
Alternative managée disponible (Portkey) pour qui veut les bénéfices sans l'astreinte opérationnelle.

Vous industrialisez vos agents IA ? SeedVision propose des audits IA en 3-5 jours et des forfaits de mise en production de 15 à 30 jours. Voir les packages ou réserver un appel de 30 min.

Photo de couverture : Photo by Growtika on Unsplash.