Pour maîtriser les coûts d’Amazon Bedrock, attribuez les appels à leurs responsables, observez leur consommation et choisissez un contrôle budgétaire adapté à la façon dont ils sont acheminés. Dans son guide publié le 30 octobre 2026, AWS organise cette démarche en cinq étapes : attribuer, observer, contrôler, optimiser et piloter.
Organiser le suivi autour de cinq étapes
Le cadre d’AWS répartit le travail entre FinOps et ingénierie plateforme. FinOps prend en charge l’attribution, les budgets, le suivi des anomalies et les revues de coûts. L’équipe plateforme configure notamment la journalisation, les métadonnées des requêtes, les contrôles et les règles de routage. Les deux équipes se retrouvent pour examiner les résultats et ajuster le dispositif.
L’ordre compte : il faut d’abord savoir à qui rattacher les appels, puis disposer d’indicateurs utiles. Les alertes ou les blocages n’interviennent qu’ensuite. Enfin, le routage et le cache peuvent contribuer à optimiser le coût, à condition d’évaluer leur effet sur les charges concernées.
Attribuer les coûts aux utilisateurs et aux applications
Dans CUR 2.0, AWS décrit le champ line_item_iam_principal pour identifier le principal IAM associé à une ligne de coût. Les équipes peuvent aussi appliquer des balises métier et les activer comme balises d’allocation des coûts. AWS indique qu’elles apparaissent dans Cost Explorer sous 24 à 48 heures.
Un rôle IAM unique derrière une passerelle partagée peut faire apparaître cette identité commune comme responsable des appels. Pour retrouver l’attribution par utilisateur, le modèle décrit par AWS consiste à assumer le rôle d’invocation Bedrock pour chaque utilisateur : son identité passe dans le nom de session, et les informations métier dans les balises de session.
Pour regrouper les dépenses par application, modèle et région AWS, AWS décrit les profils d’inférence d’application, avec un profil pour chaque combinaison. Les Projects répondent à un autre périmètre : AWS les associe aux charges bedrock-mantle utilisant l’API Responses ou l’API Chat Completions. Un Project peut couvrir plusieurs modèles.
Observer les appels avant l’attribution de facturation
CUR sert à analyser les coûts de facturation, mais AWS indique que l’attribution CUR accuse un retard d’environ 24 heures. Pour suivre l’activité plus tôt, son exemple associe CloudWatch et OpenTelemetry à un tableau de bord qui peut afficher les dépenses par développeur en quelques minutes. Ce délai correspond à l’exemple décrit par AWS.
La journalisation des invocations peut envoyer les données de requête, de réponse et les métadonnées vers CloudWatch Logs, S3, ou les deux. AWS recommande CloudWatch pour les requêtes opérationnelles et S3 avec Athena pour l’analyse à plus long terme. Les métadonnées peuvent désigner une application, un flux de travail ou un locataire, mais Bedrock n’impose pas de schéma uniforme. Définissez donc des noms de champs cohérents entre les applications si vous voulez comparer leurs usages.
Choisir un contrôle au seuil budgétaire
Les alertes AWS Budgets préviennent d’un dépassement, mais ne bloquent pas les appels. Une règle IAM peut refuser l’accès de façon asynchrone, après un délai de quelques secondes à quelques minutes suivant la mise à jour de la politique. Le refus peut aussi attendre le renouvellement des identifiants si l’équipe choisit de ne pas les fournir. Une passerelle peut appliquer la limite de façon synchrone, en moins d’une seconde selon AWS, et renvoyer une réponse HTTP 429 au seuil.
| Contrôle | Effet au seuil | Délai indiqué par AWS | Exigence opérationnelle |
| Alertes AWS Budgets | Signale le dépassement sans arrêter les appels. | Après détection du dépassement. | Une personne doit intervenir si l’équipe veut réduire l’usage. |
| Refus IAM | Refuse les appels après l’application de la politique ou le renouvellement des identifiants. | De quelques secondes à quelques minutes pour une mise à jour de politique; au prochain renouvellement des identifiants dans l’autre scénario. | Convient aux appels directs lorsque l’équipe accepte un contrôle asynchrone. |
| Contrôle par passerelle | Bloque au seuil et peut renvoyer HTTP 429. | Moins d’une seconde dans la description d’AWS. | Les clients doivent acheminer leurs appels par la passerelle, qu’il faut déployer, dimensionner et soumettre à une revue de sécurité. |
Si les clients appellent Bedrock directement, les alertes ou le contrôle IAM évitent d’ajouter un intermédiaire au chemin des requêtes. Si un arrêt immédiat est nécessaire, la passerelle offre le contrôle synchrone, à condition que les applications puissent toutes l’utiliser. Le choix dépend donc du risque de dépassement accepté et de la possibilité de modifier le routage.
Évaluer le routage et le cache de prompts
AWS recommande d’évaluer la qualité d’un modèle moins coûteux sur la tâche visée avant de lui acheminer des requêtes. Le taux de routage ne suffit pas à décider : une économie sur le modèle peut perdre son intérêt si le résultat ne convient pas à l’usage.
Les chiffres de cache présentés par AWS dans son article d’octobre 2026 concernent Anthropic Claude dans la région US East (N. Virginia). AWS indique un coût d’écriture du cache égal à 1,25 fois le tarif de base des jetons d’entrée pour une durée de vie de cinq minutes, ou à 2 fois ce tarif pour une durée d’une heure. Pour la lecture du cache, l’article indique 0,1 fois le tarif de base pour Claude Sonnet 4.6 et Claude Haiku 4.5, et 0,05 fois pour Claude Sonnet 5.5 et Claude Opus 5.5.
On peut retrouver l’estimation sur dix appels en supposant un préfixe identique et de même volume à chaque appel : une écriture, puis neuf lectures. Avec un tarif de lecture de 0,1 fois le tarif de base, le calcul donne (1,25 + 9 × 0,1) / 10 = 0,215, soit 21,5 % du coût d’entrée du préfixe sans cache. À 0,05 fois le tarif de base, (1,25 + 9 × 0,05) / 10 = 0,17, soit 17 %. Ces calculs portent uniquement sur les jetons d’entrée du préfixe; ils excluent les jetons de sortie et les autres frais. Une écriture qui n’est pas réutilisée ne bénéficie pas des neuf lectures de l’hypothèse.
Revoir les indicateurs avec les équipes
AWS propose de suivre notamment la dépense quotidienne par développeur, la part des appels dirigés vers des modèles moins coûteux, le taux de lecture du cache et le coût par résultat réussi. Ses seuils de scorecard sont des points de départ à calibrer selon les charges de travail, pas des niveaux universels. AWS suggère une revue hebdomadaire pour les flottes dont l’usage évolue rapidement et une revue toutes les deux semaines dans les autres cas.
