Claude Code + AWS FinOps : comment on a réduit nos coûts cloud de 20%

La facture AWS qui grimpe insidieusement mois après mois, c'est une réalité que connaît bien n'importe quelle équipe qui scale. Des snapshots EBS qui s'accumulent, des instances EC2 surdimensionnées depuis un pic de charge passé, des Elastic IPs non attachées qui tournent en roue libre — chaque ligne de ressource inutilisée est de l'argent qui part.

Chez KODY, on a décidé d'adresser ce problème autrement : plutôt que de faire des audits manuels ponctuels, on a intégré Claude Code dans notre workflow FinOps, en s'appuyant sur le skill aws-cost-finops du marketplace open source devops-claude-skills. Résultat : -20% sur notre facture AWS en moins de 3 mois. Voici le retour d'expérience complet.

Claude Code Skills : c'est quoi exactement ?

Avant d'entrer dans le vif du sujet, un rappel rapide sur le modèle de Skills de Claude Code.

Les Agent Skills sont des extensions modulaires qui donnent à Claude Code des capacités spécialisées au-delà de la génération de code. Concrètement, un skill est un répertoire structuré qui contient :

• Un fichier SKILL.md avec le contexte métier et les workflows
• Des scripts d'analyse automatisés
• Des guides de référence
• Des templates

Une fois installé, Claude Code sait quand et comment invoquer ces ressources en fonction de votre demande. Vous posez une question sur vos coûts AWS, il sait qu'il doit dérouler le workflow FinOps du skill plutôt que de répondre depuis sa connaissance générale.

Le marketplace devops-claude-skills regroupe plusieurs skills DevOps : Terraform, Kubernetes troubleshooting, CI/CD, GitOps, monitoring/observability — et le skill qui nous intéresse ici : aws-cost-optimization.

Le skill aws-cost-finops en détail

Ce qu'il embarque

Le skill propose un ensemble d'outils pour trouver des ressources inutilisées, analyser les opportunités de Reserved Instances, détecter les anomalies de coûts, rightsizer les instances, évaluer les Spot Instances et migrer vers des générations plus récentes.

Concrètement, le skill embarque 6 scripts Python qui interrogent directement les APIs AWS :

Il inclut aussi des guides de référence (best_practices.md, service_alternatives.md, finops_governance.md) et un template de rapport mensuel.

Installation

# Ajouter le marketplace
/plugin marketplace add https://github.com/ahmedasmar/devops-claude-skills

# Installer le skill AWS
/plugin install aws-cost-optimization@devops-skills

# Prérequis : credentials AWS
pip install boto3 tabulate
aws configure  # ou utiliser --profile <nom_profil>

Notre workflow FinOps avec Claude Code

Phase 1 : Discovery (semaine 1)

On commence chaque cycle mensuel par un scan complet de l'infra. Claude Code orchestre les scripts de découverte en séquence :

# Lancer l'analyse mensuelle complète
python3 scripts/find_unused_resources.py --profile production
python3 scripts/cost_anomaly_detector.py --days 30 --profile production
python3 scripts/rightsizing_analyzer.py --days 30 --profile production

Sur notre premier run, le script find_unused_resources.py a identifié :

• Une douzaine de volumes EBS non attachés laissés par d'anciennes pipelines de CI
• Plusieurs snapshots vieux de plus de 90 jours sans politique de rétention définie
• Deux Elastic IPs réservées mais jamais assignées

Rien de spectaculaire pris isolément. Mais agrégé, c'était plusieurs centaines d'euros par mois qui partaient pour rien.

Phase 2 : Analyse et priorisation

Claude Code ne se contente pas de lister des ressources — il contextualise les recommandations dans un cadre de priorisation clair.

Le framework utilisé distingue trois niveaux :

Quick wins (faible risque, gain immédiat) :

• Suppression des EBS orphelins après vérification
• Libération des Elastic IPs non utilisées
• Migration gp2 → gp3 — 20% d'économies sans interruption de service

Optimisations moyen terme (à planifier en sprint) :

• Rightsizing des instances EC2 sous-utilisées
• Migration vers des générations d'instances plus récentes (ex: t2 → t3, ou x86 → Graviton)

Initiatives stratégiques (réflexion trimestrielle) :

• Achat de Reserved Instances pour les workloads stables
• Introduction de Spot Instances sur les pipelines CI/CD

Phase 3 : Décision humaine — le point non-négociable

C'est là que la supervision humaine devient critique. Et c'est probablement la leçon la plus importante de ce retour d'expérience.

Claude Code peut identifier qu'une instance EC2 m5.2xlarge tourne à 8% de CPU en moyenne sur 30 jours. Il peut recommander de la downsize vers une m5.large. Mais il ne sait pas :

• Que cette instance héberge un service dont la charge est fortement saisonnière
• Qu'elle est dans un cluster Auto Scaling où la métrique CPU agrégée est trompeuse
• Qu'une migration est planifiée dans 6 semaines qui justifie de ne pas y toucher

Avant toute action destructive ou irréversible, la règle chez KODY est simple : un humain qui connaît l'infra valide. Les scripts d'analyse ne font que lire — ils ne suppriment rien. Chaque recommandation est une proposition, pas un ordre d'exécution.

# Claude Code identifie des candidats
python3 scripts/rightsizing_analyzer.py --days 30

# Exemple de sortie :
# Instance: i-0abc123 (m5.2xlarge) | CPU: 8.2% avg | Mémoire: 12% avg
# Recommandation: Downsize vers m5.large — économie estimée: ~45$/mois
# ⚠️  Vérifier: workload saisonnier ? Auto Scaling Group ? Dépendances ?

Le workflow de validation qu'on a mis en place :

1. Claude Code génère le rapport d'analyse
2. L'ingénieur infra qui possède la connaissance du contexte passe chaque recommandation en revue
3. Les quick wins "évidents" (EBS orphelins, EIPs non attachées) sont validés rapidement
4. Les rightsizings et migrations passent par une discussion avec l'équipe concernée
5. Les Reserved Instances font l'objet d'une analyse trimestrielle dédiée

Les leviers qui ont fait -20%

En 3 mois, voici la décomposition approximative de nos économies :

Nettoyage des ressources orphelines (~30% des économies)

Le gros du premier gain. Des mois d'accumulation passive : snapshots, EBS, EIPs. Nettoyage one-shot après validation manuelle de chaque ressource.

Migration gp2 → gp3 (~20% des économies)

Migration sans downtime de nos volumes EBS. gp3 offre de meilleures performances de base pour un coût inférieur à gp2. Le script detect_old_generations.py a listé tous les volumes concernés en quelques secondes — ce qui aurait pris une heure à faire manuellement.

Rightsizing EC2 (~35% des économies)

Plusieurs instances dev/staging surdimensionnées depuis leur provisioning initial. On a attendu 30 jours de métriques CloudWatch pour avoir une base solide avant de downsize. Sur les instances de production, on a été plus conservateurs.

Reserved Instances sur les workloads stables (~15% des économies)

Le script analyze_ri_recommendations.py cherche des instances qui tournent 24h/24 depuis au moins 60 jours et calcule le ROI sur des engagements 1 an ou 3 ans. On a acheté des RIs sur nos instances RDS et EC2 dont on était certains de la stabilité.

Ce que Claude Code change concrètement

Avant ce workflow, les audits de coûts étaient ponctuels, manuels, et souvent déprioritisés. Parcourir Cost Explorer, corréler avec les ressources actives, identifier les anomalies — c'est du travail ingrat qui tombait régulièrement dans les limbes.

Avec Claude Code + le skill :

• La collecte de données est automatisée : les scripts interrogent les APIs AWS en quelques minutes
• La contextualisation est faite : Claude Code comprend ce que signifie un t2.medium à 5% de CPU, sans qu'on lui explique ce qu'est une instance EC2
• La priorisation suit un cadre éprouvé : quick wins vs. stratégique, chaque recommandation est classifiée
• Le rapport est généré automatiquement : on l'utilise comme base pour la revue mensuelle avec l'équipe

Ce qu'il ne change pas : le jugement humain sur ce qui est safe de toucher en production.

Limites et points de vigilance

Il faut connaître son infra pour interpréter les recommandations

Ce workflow n'est pas fait pour quelqu'un qui "veut juste réduire la facture AWS" sans comprendre ce qu'il héberge. Les scripts sont des outils d'analyse — ils ne connaissent pas votre architecture, vos contraintes métier ou vos plans de migration.

Un find_unused_resources.py qui remonte une instance arrêtée depuis 30 jours ne sait pas que cette instance est le backup d'une base de données critique maintenu à chaud pour un basculement rapide.

Les Spot Instances demandent de la préparation

Le skill identifie les workloads éligibles au Spot — instances dans des Auto Scaling Groups, environnements de dev/test, pipelines de traitement batch, serveurs CI/CD — mais ne l'applique pas aux bases de données, applications stateful ou workloads temps réel. Même sur les workloads recommandés, l'architecture doit être prête à gérer les interruptions.

Les Reserved Instances engagent sur 1 à 3 ans

Le ROI est excellent pour les workloads stables — jusqu'à 65% d'économies sur des Standard RIs. Mais acheter des RIs sur une infrastructure qu'on prévoit de refactorer dans 6 mois, c'est pire que de payer On-Demand.

Ce qu'il faut retenir

L'IA agentique comme Claude Code change la donne sur le FinOps : elle transforme un audit cloud fastidieux en un process structuré, reproductible, et actionnable. La friction principale disparaît — collecter les données, les croiser, identifier les patterns — et ce qui reste, c'est la décision humaine, là où elle a le plus de valeur.

Le skill aws-cost-finops est un bon exemple de ce que les Agent Skills apportent : pas une boîte noire qui agit à votre place, mais un expert outillé qui vous amène au bon endroit pour prendre la bonne décision.

-20% en 3 mois, sans aucune régression en production. Avec, systématiquement, un ingénieur qui valide avant de toucher quoi que ce soit de critique.

Ressources

• devops-claude-skills sur GitHub — le marketplace open source
• Documentation Claude Code — Agent Skills et plugins
• AWS Cost Explorer
• FinOps Foundation — référence sur les pratiques FinOps