AWS décrit cinq étapes de gouvernance des coûts Bedrock, de l’attribution aux contrôles budgétaires et au cache

AWS a publié le 30 octobre une méthode en cinq étapes pour gouverner les coûts d’Amazon Bedrock: attribuer, observer, imposer des limites, optimiser et piloter régulièrement. Notre édition technique date du 1er novembre, sans modifier la date de la source. Le texte est un guide du fournisseur pour les équipes de plateforme et FinOps, non un montant d’économies mesuré par notre rédaction. Une tâche agentique peut appeler plusieurs fois un modèle et accumuler du contexte; le nombre de conversations visibles n’est donc pas une mesure fiable des jetons facturés.

La première étape demande à qui revient chaque dollar. D’après AWS, les dépenses d’inférence sont associées au principal IAM appelant dans la colonne `line_item_iam_principal` de CUR 2.0. Il faut activer l’export des données de principal, étiqueter les identités avec équipe et application, activer ces étiquettes pour la répartition des coûts et analyser les résultats. Elles peuvent mettre 24 à 48 heures à apparaître dans Cost Explorer. Si tous les utilisateurs passent par un même rôle IAM de passerelle, toutes les dépenses se retrouvent sous ce rôle commun. AWS propose d’assumer un rôle pour chaque utilisateur, avec nom et étiquettes de session, puis de réutiliser temporairement ces identifiants afin de retrouver la répartition individuelle. Cela demande des droits IAM et une gestion correcte des sessions.

La deuxième étape rend les requêtes observables. CUR attribue les factures, mais n’explique pas pourquoi une demande a consommé tant de jetons. AWS conseille de configurer les journaux d’invocation des modèles, puis d’en vérifier la livraison, le chiffrement et la conservation. Ils peuvent aller vers CloudWatch Logs, S3 ou les deux. Chaque appel doit porter des métadonnées cohérentes d’application, de workflow et de locataire. Bedrock n’oblige pas chaque équipe à les fournir; une bibliothèque partagée ou une passerelle peut les insérer et mesurer leur couverture. Les journaux peuvent contenir des données sensibles et nécessitent donc leur propre gouvernance. Le CUR peut être en retard d’environ un jour; une observation opérationnelle plus rapide ne remplace pas la facture finale.

La troisième étape choisit un délai d’application des budgets. Le niveau 1 utilise des alertes AWS Budgets, sans bloquer les appels. Le niveau 2 met à jour une règle de refus IAM ou cesse de fournir des identifiants après dépassement, sur la base des données d’usage. Il applique une limite de façon asynchrone: une règle peut prendre plusieurs secondes ou minutes après l’appel excédentaire, et une vérification d’identifiants attend leur prochain renouvellement. Le niveau 3 place une passerelle dans le chemin d’inférence et renvoie HTTP 429 dès qu’une limite configurée est atteinte. Il exige en contrepartie un composant à déployer, dimensionner et auditer. Les clients qui joignent Bedrock directement ne profitent pas d’un blocage synchrone par passerelle sans changer leur chemin réseau.

La quatrième étape change les choix par défaut plutôt que de demander seulement aux développeurs de raccourcir leurs consignes. Il faut tester la qualité sur ses propres tâches avant de diriger les demandes simples vers des modèles moins coûteux. Le cache de prompt n’est avantageux que si un préfixe stable est relu. Dans l’exemple AWS d’octobre 2026 pour certains modèles Claude en région US East, une écriture de cache de cinq minutes coûte 1,25 fois l’entrée de base, une lecture coûte 0,1 ou 0,05 fois selon le modèle, et une écriture d’une heure coûte deux fois la base. Ce sont des multiplicateurs d’exemple liés à une période, une région et un modèle, pas des prix mondiaux permanents. Une écriture jamais relue peut augmenter la facture.

La cinquième étape transforme les données en décisions régulières. AWS recommande de suivre le mélange de modèles, les échecs et reprises, l’efficacité des lectures de cache et le pourcentage de demandes avec métadonnées complètes. Une requête abandonnée côté client mais terminée côté service, puis réessayée, peut créer du travail facturé supplémentaire. Le tableau d’exemple contient des bandes quotidiennes de moins de 100 dollars, de 100 à 300 dollars et de plus de 300 dollars par développeur. AWS les présente comme des points de départ à adapter, non comme des seuils imposés à tous. Le coût par résultat réussi compte davantage qu’un tarif de jeton isolé.

L’ordre des étapes a une justification: impossible de savoir si routage ou cache aident sans connaître le propriétaire et la cause des dépenses. Des budgets appuyés seulement sur la facturation différée ne garantissent pas non plus un arrêt immédiat. Avant un déploiement, une équipe doit vérifier identité et journaux, choisir son délai d’application acceptable, mesurer la qualité après routage et revoir ensemble coûts et résultats. Notre rédaction n’a pas appliqué cette méthode ni reproduit des économies. Nous rapportons le plan AWS et ses mécanismes avec leurs limites.

La documentation AWS sur CloudTrail ajoute une condition d’audit. Les trails et les magasins d’événements ne journalisent pas les événements de données par défaut; la page Event history n’affiche que les événements de gestion. Pour suivre les opérations de données Bedrock dans CloudTrail, il faut configurer explicitement les sélecteurs adaptés. La journalisation des invocations de modèles constitue une source distincte, à activer séparément, qui peut contenir des requêtes et réponses sensibles. Il convient de rapprocher les traces d’accès, les requêtes, la facturation et les résultats de l’application au moyen d’un identifiant fiable, au lieu de tenir un journal isolé pour exhaustif.