AWS publie un modèle de data lake pour Bedrock : chaque prompt, chaque token et son coût deviennent visibles

Une histoire familière : en fin de mois, la facture Bedrock arrive, le montant a grimpé, et impossible de répondre à la question « qui, et pourquoi ». On voit l'agrégat, mais pas le contenu des appels. Impossible de savoir quel prompt a été envoyé, ce que le modèle a renvoyé et combien de tokens il a consommés. AWS propose une solution prête à l'emploi : un data lake central pour tous les appels Bedrock de l'organisation. Les modèles CloudFormation, le code Lambda et les requêtes SQL se trouvent dans le dépôt AWS Sample Bedrock Invocation Data Lake.

Ce qui existe d'origine et ce qui manque

Bedrock propose la fonction model invocation logging. Elle écrit une trace complète des requêtes et des réponses dans S3 ou CloudWatch. Mais elle s'active séparément dans chaque compte, et les données y restent. Avec une dizaine de comptes, on obtient une dizaine d'îlots isolés. Comparer les équipes, repérer un prompt gaspilleur ou analyser un pic de dépenses devient difficile.

Comment fonctionne le pipeline

Le parcours de chaque appel comprend cinq étapes :

• Bedrock, dans le compte source, écrit le journal dans un groupe CloudWatch.
• Un subscription filter agit comme une règle de transfert permanente : chaque nouvel événement part vers un CloudWatch Logs destination dans le compte central. Les sources n'obtiennent aucun droit sur le pipeline central, elles se contentent d'envoyer les événements.
• Une petite Lambda décompresse les paquets CloudWatch, qui arrivent compressés et encodés. Elle écarte le bruit de service, comme le message « Permissions are correctly set », et remonte au niveau supérieur le champ imbriqué contenant l'identité de l'appelant.
• Amazon Data Firehose met les enregistrements en mémoire tampon, convertit le JSON en Parquet et les dépose dans S3, classés par date (year/month/day).
• Une table Glue explique à Athena comment lire ces fichiers, puis du SQL ordinaire prend le relais.

Résultat : dans une seule table, chaque appel dispose de son prompt, de sa réponse, du nombre de tokens en entrée et en sortie, du modèle, de la raison d'arrêt, du compte, de l'heure et du rôle IAM. On ne dit plus « nous avons dépensé X tokens », mais « voici ce qu'il y avait dans chaque appel ».

Que faire de tout cela en pratique

Voici quelques scénarios tirés du billet :

• Débogage. Vous récupérez le prompt et la réponse exacts d'un appel précis, sans fouiller dans les journaux bruts.
• Efficacité. Vous comparez les tokens d'entrée et de sortie par équipe et par modèle pour trouver où les tokens sont gaspillés.
• Ingénierie de prompts. Vous cherchez les réponses avec stop_reason = max_tokens : elles ont été tronquées, donc le prompt ou la configuration méritent d'être retravaillés.
• Coût. La table se joint à l'AWS Cost and Usage Report 2.0 via l'IAM ARN, ce qui donne les dépenses par équipe et par jour, ainsi que le prix des appels les moins efficaces.

Pour la visualisation, un tableau de bord Quick Sight est fourni, installable avec la commande cid-cmd deploy. On peut y ajouter des métadonnées de l'organisation, comme les noms des équipes.

Les auteurs relient le tout à la tokenomics : selon eux, la conférence de la FinOps Foundation en 2026 l'a érigée en domaine FinOps à part entière. La logique est simple : on ne peut pas optimiser les tokens tant qu'on ne les a pas mesurés. Le lac de données fournit précisément cette base.

Limites et pièges

Le principal risque est la sécurité. Vous stockez les prompts et réponses complets de toutes les équipes dans un seul bucket, et ils peuvent contenir des données personnelles (PII). Le bucket est chiffré via KMS, mais l'accès à celui-ci et aux résultats Athena doit être restreint par vos propres politiques IAM.

Il existe aussi des subtilités opérationnelles :

• La journalisation Bedrock est un paramètre au niveau du compte, et non une ressource CloudFormation. Il faut l'activer par un appel d'API distinct dans chaque source, et uniquement avec livraison vers CloudWatch.
• Les données n'apparaissent pas instantanément : Firehose vide son tampon environ une minute plus tard, parfois davantage. C'est acceptable pour des investigations, pas pour des alertes en temps réel.
• La vue Athena se crée manuellement : la requête enregistrée doit être exécutée une fois.
• La jointure avec les coûts se fait par IAM ARN. Si toutes les équipes accèdent à Bedrock avec le même rôle, la ventilation par équipe restera approximative. C'est notre conclusion ; le billet ne l'aborde pas directement.
• À la suppression, videz d'abord les buckets, puis supprimez manuellement le workgroup Athena.

Conclusion

Si vous utilisez Bedrock dans plusieurs comptes et ne pouvez pas dire quelle équipe brûle le plus de tokens, ce modèle mérite d'être déployé. Le conseil des auteurs : ne cherchez pas à tout couvrir d'un coup. Commencez par un ou deux comptes, maîtrisez les requêtes sur la table, et élargissez seulement ensuite à l'organisation. Profitez-en pour vérifier les politiques IAM et le bucket tant qu'il contient encore peu de données.