Un agent FinOps pour l'optimisation des coûts AWS

Contexte

Les coûts d’un compte AWS dérivent naturellement : instances dimensionnées large au lancement et jamais revues, volumes EBS détachés qu’on oublie de supprimer, Elastic IP allouées et jamais associées — facturées quand même, depuis février 2024, à un tarif fixe par adresse. Détecter ce gaspillage n’est pas difficile, c’est fastidieux : il faut croiser les recommandations de Compute Optimizer, l’inventaire EC2 et l’API de tarification, puis chiffrer chaque cas. Exactement le type de travail qui se reporte de sprint en sprint.

C’est un terrain bien adapté à un agent LLM — croiser des sources, raisonner, prioriser, synthétiser. C’est aussi un terrain où un agent mal conçu est dangereux. Ce projet, personnel et au code public, sert les deux objectifs : produire un diagnostic de coûts utilisable, et répondre sérieusement à la question « comment met-on un agent LLM au contact d’une infrastructure sans en hériter les risques ? ».

Contrainte

La contrainte est double, et chacune a structuré une partie du design.

D’abord la sûreté : un modèle de langage se trompe parfois avec assurance. Donner des droits d’écriture sur un compte AWS à un système non déterministe n’est pas défendable. La sûreté ne devait pas reposer sur la qualité du prompt, mais sur ce que l’agent est matériellement capable de faire.

Ensuite l’exactitude : un outil FinOps ne vaut que si ses chiffres sont justes. Or un LLM produit des nombres plausibles, pas des nombres exacts — et une économie annoncée à tort coûte plus cher en crédibilité qu’elle ne rapporte. Il fallait donc que le modèle ne calcule jamais rien.

Décisions

La première décision structure tout le reste : l’agent est en lecture seule par construction. Six outils lui sont exposés — recommandations de rightsizing via Compute Optimizer, détection des volumes EBS non attachés et des Elastic IP non associées, tarification EC2 et EBS via l’API Price List, coût des IPv4 publiques, et un calculateur d’économies — et aucun ne mute quoi que ce soit. La politique IAM tient en quatre actions, toutes en lecture. La nuance compte : une permission refusée peut se déborder par erreur de configuration, une capacité absente ne s’invoque pas. Le coût est assumé : l’agent ne « répare » rien lui-même, la remédiation reste un geste humain, hors du système.

Deuxième décision : aucune arithmétique n’est laissée au modèle. Les outils de tarification renvoient des prix exacts tirés de l’API AWS ; un outil dédié, en code pur, fait les soustractions et les totaux ; le prompt interdit explicitement au modèle de calculer et lui impose d’étiqueter « unpriced » ce qu’il ne peut pas chiffrer avec les outils, plutôt que d’estimer de mémoire. L’agent ne fait même pas confiance aux économies précalculées de Compute Optimizer : pour chaque recommandation, il re-tarife le type d’instance actuel et le type proposé, et dérive l’écart exact du tarif réel. Enfin, les chiffres du rapport — table d’économies, graphique, carte des ressources — sont re-dérivés en code, indépendamment de la prose du modèle. Le modèle raconte ; le code compte.

Troisième décision : le système est développable sans AWS et sans LLM. Un mode mock sert des données à l’exacte forme des réponses AWS, avec la parité mock/réel vérifiée au même endroit dans chaque fonction. Un mode --tools-only exécute tout le pipeline — collecte, chiffrage, rapport — sans aucun appel à un modèle : c’est ce qui rend la CI et les démonstrations possibles. La logique vit dans des fonctions Python ordinaires, les décorateurs d’outils sont des enveloppes d’une ligne : le cœur du système se teste comme du code normal, sans mocker un LLM. Le prix : des mocks à entretenir quand les API évoluent. Il est faible devant l’alternative — développer en aveugle contre de vraies ressources facturées.

Dernière décision, la moins évidente : tester contre du vrai AWS exige de créer du vrai gaspillage, et ce coût devait être borné. Une stack CDK jetable provisionne exactement le décor minimal que les outils savent détecter — une instance idle, un volume jamais attaché, une IP jamais associée — avec une alerte budget et une destruction en une commande. Quant à la fondation : Strands Agents sur Amazon Bedrock par défaut, ce qui garde les données de facturation dans la frontière AWS du compte ; le fournisseur de modèle est une variable d’environnement, pas une décision d’architecture — l’API Anthropic directe se substitue à Bedrock sans toucher au code des outils.

Résultat

L’agent fonctionne en trois modes — mock, outils seuls, agent complet contre un compte réel — et produit un rapport Markdown : table des économies par action, graphique, carte des ressources colorée par état. Les totaux du rapport sont reproductibles à l’identique sans modèle, ce qui en fait aussi un contrôle de la prose de l’agent.

Le code est public — le dépôt tient lieu de preuve pour chaque affirmation de cette page. Ce que le projet démontre : un agent LLM peut produire un diagnostic de coûts digne de confiance, à condition de retirer au modèle ce qu’il fait mal — l’arithmétique, la mutation — et de lui laisser ce qu’il fait bien — l’orchestration des outils, le croisement des données, la synthèse priorisée.