AWS détaille les contrôles des dépenses en temps quasi réel de Jamf pour Amazon Bedrock

Que s'est-il passé

AWS indique que Jamf a construit et testé en production un système sans serveur pour surveiller et appliquer les limites de dépenses Amazon Bedrock par utilisateur. Le système utilise les journaux d'appel de Bedrock, Amazon Athena, DynamoDB, AWS Lambda, les planifications EventBridge, les politiques gérées par le client IAM et les notifications Slack.

Dans un article daté du 1er septembre 2026, AWS a décrit comment Jamf a abordé le coût d'un large accès à Amazon Bedrock pour son organisation d'ingénierie. AWS indique que Jamf, qu'il décrit comme servant plus de 76 000 organisations avec des produits de gestion et de sécurité des appareils Apple, a étendu l'accès à Bedrock pour prendre en charge le développement assisté par l'IA. L’entreprise avait alors besoin d’une visibilité et d’une responsabilité par utilisateur à mesure que l’utilisation augmentait. L’article présente la mise en œuvre de Jamf comme un modèle testé en production plutôt qu’un nouveau modèle Bedrock ou un changement dans la tarification publique de Bedrock.

Le système mesure les dépenses quotidiennes de chaque ingénieur Bedrock à partir des journaux d'appel écrits dans un compartiment Amazon S3. Ces journaux incluent l'identifiant du modèle, le nombre de jetons d'entrée et de sortie et l'identité de l'utilisateur. Une vue Amazon Athena calcule les dépenses quotidiennes en appliquant les tarifs Bedrock publiés à ce nombre de jetons. AWS demande aux utilisateurs de mettre à jour la vue des tarifs dans leur région et d'ajouter une branche de tarification explicite chaque fois qu'un nouveau modèle est activé. Les modèles inconnus se voient attribuer le niveau le plus élevé en tant que sécurité jusqu'à ce que leur taux réel soit ajouté.

Une fonction Lambda AWS s'exécute toutes les 15 minutes via une planification EventBridge Amazon. Il lit les dépenses de la journée en cours auprès d'Athena, vérifie dans une table DynamoDB les exceptions approuvées et maintient l'état de l'utilisateur afin que chaque notification de seuil soit envoyée une seule fois. Lorsqu'un utilisateur franchit un seuil, la fonction publie une nouvelle version d'une stratégie gérée par le client IAM. La stratégie utilise la valeur d’identité saml:sub de l’utilisateur pour refuser l’accès aux familles de modèles spécifiées. AWS indique que la politique révisée est évaluée lors du prochain appel de l'ingénieur à Bedrock et ne nécessite pas de ré-authentification.

L'exemple de modèle d'application maintient un modèle moins coûteux disponible tout en limitant les modèles plus coûteux à des niveaux de dépenses progressivement plus élevés. AWS donne une configuration illustrative dans laquelle l'accès à Claude Opus est refusé à 80 % d'un budget quotidien et à Claude Sonnet à 100 %, tandis que Claude Haiku reste disponible. Une commande Slack slash, /bedrock-limit, permet aux administrateurs autorisés d'accorder une limite supérieure dans le temps pour des cas tels qu'une migration, une escalade client ou une évaluation de modèle. L'enregistrement d'exception inclut une heure d'expiration et des informations d'audit, et DynamoDB TTL est utilisé pour supprimer automatiquement les entrées expirées.

Détails de la source: aws.amazon.com ↗

Pourquoi c'est important

L’approche s’attaque à un obstacle pratique à l’adoption de l’IA en entreprise : les coûts des modèles peuvent varier en fonction du comportement des utilisateurs et des charges de travail des agents, ce qui rend les dépenses difficiles à prévoir. La conception de Jamf offre un moyen d’étendre l’accès tout en conservant une visibilité au niveau de l’utilisateur et des contrôles progressifs, bien que la source ne fournisse aucune mesure indépendante des gains de productivité ou du retour sur investissement.

Le problème pratique est que les coûts de l’IA générative dépendent du comportement. Un développeur exécutant une boucle de codage agent étendue peut générer une utilisation de jetons beaucoup plus importante que ne le suggère une charge de travail informatique provisionnée conventionnelle. Les limites par utilisateur donnent à une organisation un moyen de connecter l'utilisation à une identité et une fenêtre horaire, plutôt que d'attendre une facture cloud globale. Cela est particulièrement pertinent lorsque les modèles haut de gamme ont des tarifs sensiblement différents ou lorsque les flux de travail autonomes peuvent répéter des appels sans qu'un humain n'examine chaque étape.

La conception traite également le contrôle des coûts comme un problème de déploiement et de gestion des accès. Au lieu d'arrêter tout accès à Bedrock une fois qu'un budget est atteint, il applique des restrictions spécifiques au modèle et préserve une solution de repli moins chère. Cela peut réduire l’impact opérationnel d’un plafond, mais cela ne garantit pas que le travail se poursuivra avec la même qualité ou la même rapidité. La source ne précise pas combien d’ingénieurs Jamf utilisent le système, les seuils réels de l’entreprise, le montant dépensé avant et après le déploiement, ni les résultats mesurés de la productivité et du retour sur investissement. La déclaration de AWS selon laquelle la productivité a augmenté et que la gouvernance a permis un accès plus large reste le compte de l'entreprise et non un résultat vérifié de manière indépendante.

L'architecture se distingue par son ensemble relativement restreint de services gérés et sa logique d'application idempotente. Chaque exécution Lambda recalcule la liste complète des utilisateurs restreints à partir des dépenses quotidiennes cumulées, de sorte qu'une exécution manquée ou répétée ne nécessite pas de chemin de restauration distinct. La réinitialisation quotidienne est également dérivée de la vue Athena limitée dans le temps. AWS indique que Lambda, DynamoDB et S3 coûtent bien moins de 10 dollars par mois pour des centaines d'ingénieurs dans le cas d'utilisation de Jamf, mais il identifie Athena comme le principal coût variable. Cette estimation est spécifique à la charge de travail et à la configuration signalées et ne constitue pas une garantie générale des coûts.

Que regarder ensuite

Les principaux risques opérationnels sont les changements de prix, les données de coûts incomplètes, les limites des versions de politique, les coûts des requêtes Athena et le cycle d'application de 15 minutes. Les organisations qui adoptent ce modèle devront tester la rapidité avec laquelle les restrictions s'appliquent, valider le modèle de tarification, préserver un modèle de secours abordable et régir les exceptions.

La plus grande préoccupation technique concerne les données sources et la carte des prix. Les journaux Bedrock doivent contenir suffisamment d’informations d’identité et de jeton pour prendre en charge l’application, et chaque modèle activé nécessite un taux régional actuel. AWS indique qu'un modèle non mappé est tarifé au niveau le plus élevé pour empêcher un nouveau modèle de contourner les contrôles, mais cette protection pourrait temporairement restreindre les utilisateurs si la branche de tarification n'est pas mise à jour. La source ne décrit pas le rapprochement avec la facture finale AWS, le traitement des remboursements ou des crédits, ni la manière dont l'utilisation des demandes ayant échoué, réessayées ou mises en cache est gérée.

La conception des requêtes affectera à la fois le coût et la rapidité. AWS signale que quatre requêtes filtrées différemment sur la même vue JSON ont chacune analysé environ 11 Go, car le JSON orienté ligne doit être désérialisé avant le filtrage. Il recommande de combiner les requêtes dérivées en une seule requête groupée et de séparer les résultats dans le code de l'application, ou de convertir les journaux dans un format en colonnes tel que Parquet. Les requêtes Athena sont asynchrones, la fonction Lambda doit donc les soumettre et les interroger et disposer d'un délai d'attente suffisamment long pour se terminer. La source ne fournit pas de latence de bout en bout observée ni de garantie que chaque restriction prendra effet dans un nombre de minutes donné.

Les administrateurs devront examiner le plan de contrôle avec autant d’attention que le calcul des coûts. AWS indique que les stratégies gérées conservent un maximum de cinq versions, ce qui oblige la fonction Lambda à supprimer la version la plus ancienne, autre que celle par défaut, avant d'en créer une nouvelle. Les exceptions créent également une question de gouvernance : la conception enregistre qui a accordé une limite élevée et, éventuellement, quel ticket l'a autorisée, mais la source ne précise pas les rôles d'approbation, la durée maximale de l'exception ou les procédures de révision. Les évaluations futures devraient se concentrer sur les retards d’application, les échecs de cartographie des identités, l’effet des substitutions de modèles, l’adéquation du modèle de repli et si les contrôles produisent l’équilibre promis entre la prévisibilité des coûts et l’accès des développeurs.

Guides et quiz associés