FinOps : définition, méthode et 10 leviers pour réduire sa facture AWS

La facture AWS a une particularité : elle augmente rarement d’un coup. Elle dérive, mois après mois, au rythme des environnements créés pour un test et jamais supprimés, des instances dimensionnées « au cas où » et des flux réseau que personne ne surveille. Le FinOps est la réponse organisée à cette dérive. Cet article en donne une définition simple, explique sa méthode, puis détaille dix leviers concrets sur AWS. Pour situer ce sujet dans l’ensemble de nos expertises, voir notre page conseil cloud AWS et Azure.

FinOps : définition simple

La FinOps Foundation définit le FinOps comme un cadre opérationnel et une pratique culturelle qui maximise la valeur métier des technologies, permet des décisions rapides fondées sur les données et crée une responsabilité financière grâce à la collaboration entre équipes d’ingénierie, de finance et métiers.

Autrement dit : le FinOps ne cherche pas à dépenser le moins possible, mais à dépenser en connaissance de cause. Une hausse de facture liée à une croissance d’activité est saine ; une hausse liée à des ressources oubliées ne l’est pas. Le FinOps permet de faire la différence.

D’où vient le FinOps

Le terme s’est structuré autour de la FinOps Foundation, qui publie le FinOps Framework : des principes, des rôles (personas), des domaines de pratique et un modèle de maturité. Six principes en forment le socle :

1. Les équipes doivent collaborer.
2. La valeur métier guide les décisions technologiques.
3. Chacun est responsable de sa consommation.
4. Les données FinOps doivent être accessibles, à jour et exactes.
5. Le FinOps est porté par une fonction centrale.
6. Il faut tirer parti du modèle de coûts variables du cloud.

Inform, Optimize, Operate : les trois phases

Le framework organise la démarche en trois phases qui se répètent en continu :

• Inform (visibilité et allocation) : examiner les données de coûts, d’usage et d’efficacité pour savoir qui dépense quoi, et pourquoi.
• Optimize (tarifs et usage) : identifier les opportunités d’amélioration, côté tarif (engagements, remises) comme côté consommation (dimensionnement, arrêt, architecture).
• Operate (amélioration continue) : mettre en œuvre les changements identifiés, les intégrer aux processus et mesurer leurs effets.

Qui fait du FinOps dans une PME ou une ETI

Dans une grande entreprise, une équipe FinOps dédiée peut exister. Dans une PME ou une ETI, le FinOps est plutôt un rôle partagé : un responsable technique qui pilote les outils et les optimisations, un interlocuteur finance qui suit le budget et les prévisions, et des responsables métier qui valident la valeur des dépenses de leurs applications. L’essentiel est qu’une personne soit clairement responsable de l’animation et qu’un rituel régulier réunisse ces trois profils.

Pourquoi la facture AWS dérape

Ressources orphelines, surdimensionnement, hors production allumée 24/7

Trois causes reviennent presque toujours :

• Les ressources orphelines : volumes EBS détachés, snapshots anciens, adresses IP élastiques non associées, équilibreurs de charge sans cible, environnements de test oubliés.
• Le surdimensionnement : des instances et des bases choisies par précaution, jamais réajustées après la mise en production.
• Les environnements hors production allumés en permanence : développement, recette et préproduction tournent souvent la nuit et le week-end alors que personne ne les utilise.

Transferts de données et NAT Gateway

Les transferts réseau sont la ligne la moins lisible de la facture. Une NAT Gateway est facturée à l’heure et au volume de données traité. Si vos serveurs privés téléchargent beaucoup de données depuis Amazon S3 ou d’autres services AWS en passant par une NAT Gateway, vous payez ce trafic alors qu’il existe des alternatives. Les flux entre zones de disponibilité ajoutent aussi des coûts souvent ignorés.

Absence de tagging et d’allocation

Sans étiquetage des ressources, la facture est un bloc : impossible de dire combien coûte une application, un client ou une équipe. Personne ne se sent responsable, et chaque optimisation devient une négociation. C’est pour cela que le tagging est le premier levier.

10 leviers pour réduire sa facture AWS

1. Taguer et allouer les coûts

Définissez un petit nombre de tags obligatoires (application, environnement, équipe ou centre de coûts, responsable) et appliquez-les via l’Infrastructure as Code plutôt qu’à la main. Point souvent oublié : sur AWS, les tags doivent être activés comme tags de répartition des coûts dans la console de facturation avant d’apparaître dans Cost Explorer et les rapports, et cette activation peut prendre jusqu’à 24 heures. Pour ce qui ne peut pas être tagué, les catégories de coûts (Cost Categories) permettent de compléter l’allocation.

2. Rightsizing avec Compute Optimizer

AWS Compute Optimizer analyse la configuration et les métriques d’utilisation de vos ressources (par défaut sur les 14 derniers jours, jusqu’à 93 jours avec une option payante) pour recommander un redimensionnement ou signaler des ressources inactives. Il couvre notamment EC2, les groupes Auto Scaling, EBS, Lambda, ECS sur Fargate, RDS et Aurora. Il faut l’activer explicitement. Attention : sans métrique mémoire collectée, les recommandations EC2 sont moins fiables.

3. Arrêt planifié des environnements hors production

Un environnement utilisé uniquement en journée ouvrée n’a pas besoin de tourner 168 heures par semaine. La solution AWS Instance Scheduler démarre et arrête automatiquement les instances EC2 et RDS selon un planning défini par tag ; AWS donne l’exemple d’une utilisation hebdomadaire ramenée de 168 à 50 heures. Même logique pour les clusters de conteneurs de développement, que l’on peut réduire à zéro hors des heures ouvrées.

4. Savings Plans et Reserved Instances

Pour la consommation stable, les engagements sont le levier tarifaire le plus direct. Les Savings Plans engagent sur un montant de dépense horaire pendant un ou trois ans, avec paiement total, partiel ou nul à l’avance ; AWS annonce jusqu’à 72 % d’économies par rapport aux tarifs à la demande. Les Compute Savings Plans s’appliquent à EC2 quelle que soit la famille d’instance, la taille, le système ou la région, ainsi qu’à Fargate et Lambda. Les Reserved Instances restent utiles pour des services comme RDS, ElastiCache ou OpenSearch. Règle de prudence : n’engagez que la part de consommation dont vous êtes sûr, après avoir fait le rightsizing, pas avant.

5. Spot pour les charges tolérantes

Les instances Spot utilisent la capacité inutilisée d’EC2, avec des remises annoncées par AWS jusqu’à 90 % par rapport à la demande. Contrepartie : AWS peut récupérer l’instance avec un préavis de deux minutes. Elles conviennent aux traitements par lots, à l’intégration continue, au calcul distribué ou aux nœuds de conteneurs sans état, pas à une base de données de production.

6. Graviton

Les processeurs Graviton, conçus par AWS sur architecture Arm, sont présentés par AWS comme jusqu’à 20 % moins chers que des instances x86 comparables. La migration est souvent simple pour les langages interprétés ou compilés en bytecode (Python, Java, Node.js) et pour les services managés (RDS, ElastiCache, OpenSearch). Elle demande plus de tests pour les logiciels compilés ou les dépendances binaires.

7. Cycle de vie du stockage S3 et des snapshots

Les règles de cycle de vie S3 font passer automatiquement les objets vers des classes moins chères (Standard-IA, Glacier) ou les suppriment après une durée définie. Elles s’appliquent aussi aux objets déjà présents. Deux points d’attention : les transitions sont facturées par requête et certaines classes imposent une durée minimale de stockage. Pour des accès imprévisibles, la classe S3 Intelligent-Tiering déplace les objets automatiquement. Côté snapshots EBS et sauvegardes, définissez une politique de rétention explicite plutôt que de tout conserver.

8. Réduire les transferts réseau et les NAT Gateway

AWS recommande deux pistes : placer les ressources dans la même zone de disponibilité que leur NAT Gateway (ou prévoir une NAT Gateway par zone), et créer des points de terminaison VPC pour les services AWS les plus sollicités. Les points de terminaison de type passerelle pour S3 et DynamoDB évitent de faire transiter ce trafic par la NAT Gateway. Analysez d’abord les flux réels avant de modifier l’architecture.

9. Budgets, alertes et Cost Anomaly Detection

AWS Budgets alerte quand une dépense réelle ou prévue dépasse un seuil. AWS Cost Anomaly Detection utilise l’apprentissage automatique pour repérer des dépenses inhabituelles, en tenant compte de la saisonnalité, et identifie la cause probable par service, compte, région ou type d’usage. Le service s’exécute environ trois fois par jour, avec un délai pouvant aller jusqu’à 24 heures. Il ne remplace pas la revue humaine, mais il évite de découvrir une dérive en fin de mois.

10. Gouvernance continue : revue mensuelle et KPI unitaires

Les leviers précédents s’érodent sans rituel. Une revue mensuelle courte, avec la technique, la finance et les métiers, suffit souvent : évolution de la facture, anomalies, recommandations en attente, couverture des engagements. Ajoutez des indicateurs unitaires qui relient le coût à l’activité (coût par commande, par utilisateur actif, par document traité) : ce sont eux qui disent si la dépense crée de la valeur.

Outils FinOps : natifs AWS et tiers

Pour démarrer, les outils natifs couvrent l’essentiel :

Outil AWS	Rôle	Phase FinOps
Cost Explorer	Explorer la facture par service, compte, tag, période	Inform
Data Exports (CUR 2.0, FOCUS)	Exporter le détail des coûts vers S3 pour analyse	Inform
Cost Categories et tags de répartition	Allouer les coûts aux applications et équipes	Inform
Cost Optimization Hub	Centraliser et prioriser les recommandations (rightsizing, ressources inactives, Savings Plans, Reserved Instances)	Optimize
Compute Optimizer	Recommandations de dimensionnement	Optimize
Budgets et Cost Anomaly Detection	Alerter sur les dépassements et anomalies	Operate

AWS Data Exports permet notamment d’exporter les coûts au format FOCUS, la spécification ouverte de données de coûts portée par la FinOps Foundation, utile si vous comparez plusieurs fournisseurs. Les outils tiers deviennent pertinents en multicloud, quand les volumes de données augmentent ou quand vous avez besoin d’une allocation fine des coûts Kubernetes partagés.

Le FinOps de l’IA générative

Les services d’IA générative obéissent à une logique de coût différente. Sur Amazon Bedrock, l’usage à la demande est facturé au nombre de tokens en entrée et en sortie, avec des tarifs propres à chaque modèle. D’autres modes existent : l’inférence par lots, annoncée par AWS à un tarif inférieur de 50 % pour les modèles éligibles, le débit provisionné et, pour certains modèles, la mise en cache des prompts.

Pour allouer ces coûts, Bedrock permet de créer des profils d’inférence applicatifs auxquels on attache des tags de répartition des coûts : chaque application ou équipe voit sa propre consommation. La FinOps Foundation consacre d’ailleurs un domaine de travail spécifique au FinOps pour l’IA, centré sur la visibilité des coûts sur tout le cycle de vie et sur la mesure de la valeur produite. Les bons réflexes : choisir le plus petit modèle qui répond au besoin, limiter la taille du contexte envoyé, mettre en cache ce qui peut l’être et suivre un coût par tâche métier. Nous traitons ces sujets dans notre approche de mise en production de l’IA.

Par où commencer : la checklist des 30 premiers jours

Semaine 1 : rendre visible

• Activer Cost Explorer, Cost Optimization Hub et Compute Optimizer
• Configurer un export de données de coûts (Data Exports) vers S3
• Créer un budget global et activer Cost Anomaly Detection

Semaine 2 : allouer

• Définir 4 à 5 tags obligatoires et les activer comme tags de répartition des coûts
• Identifier les dépenses non allouées et leurs responsables

Semaine 3 : gains rapides

• Supprimer les ressources orphelines (volumes, snapshots, IP, équilibreurs inutilisés)
• Planifier l’arrêt des environnements hors production
• Ajouter les points de terminaison S3 et DynamoDB si le trafic NAT est significatif

Semaine 4 : décider

• Appliquer les recommandations de rightsizing validées
• Étudier la couverture en Savings Plans sur la base stabilisée
• Instaurer la revue mensuelle et choisir un premier KPI unitaire

Aucun de ces leviers ne garantit un pourcentage d’économies fixé à l’avance : les gains dépendent de votre architecture et de votre usage, et se mesurent sur vos propres données.

Prochaine étape

Si vous souhaitez un regard extérieur sur votre facture AWS ou Azure, nous pouvons analyser vos données de coûts, prioriser les leviers et mettre en place une gouvernance que vos équipes pourront faire vivre, depuis Villeneuve-d’Ascq dans la métropole lilloise ou à distance. Découvrez notre accompagnement en FinOps et optimisation des coûts cloud. Et si vous préparez une migration, notre article sur la stratégie de migration vers le cloud et les 7R vous aidera à intégrer la maîtrise des coûts dès la conception.

[ VOS QUESTIONS ]

Questions fréquentes

FinOps, c’est quoi ?

Le FinOps est une discipline qui vise à maximiser la valeur métier des dépenses cloud et technologiques. Il repose sur la collaboration entre équipes techniques, financières et métiers, sur des données de coûts accessibles et à jour, et sur la responsabilisation de chaque équipe sur sa consommation.

Comment estimer le coût d’une infrastructure AWS ?

Pour un nouveau projet, AWS Pricing Calculator permet de modéliser les services prévus et leurs volumes. Pour une infrastructure existante, la référence est votre facture réelle, analysée dans Cost Explorer ou via les exports de coûts détaillés. Dans les deux cas, intégrez le stockage, les transferts de données et les environnements hors production, souvent oubliés.

Savings Plans ou Reserved Instances ?

Les Savings Plans engagent sur un montant de dépense horaire pendant un ou trois ans ; les Compute Savings Plans s’appliquent à EC2 quelle que soit la famille d’instance ou la région, ainsi qu’à Fargate et Lambda. Les Reserved Instances restent pertinentes pour certains services comme RDS, ElastiCache ou OpenSearch. Le bon choix dépend de la stabilité de votre consommation.

Qu’est-ce que le FinOps pour l’IA ?

C’est l’application des principes FinOps aux services d’IA, dont la facturation repose souvent sur le nombre de tokens traités. Il s’agit de rendre visibles ces coûts, de les allouer par application ou par équipe, et de vérifier que chaque usage produit une valeur mesurable.

Quelle certification FinOps ?

La certification d’entrée de la FinOps Foundation est le FinOps Certified Practitioner. Elle couvre le framework, les principes, les personas et les phases Inform, Optimize et Operate. Une certification Professional, plus avancée, existe pour les praticiens expérimentés.

Sources

• FinOps Foundation : What is FinOps?
• FinOps Foundation : FinOps Principles
• FinOps Foundation : FinOps Phases
• FinOps Foundation : FinOps for AI
• AWS : Organizing and tracking costs using cost allocation tags
• AWS : What is AWS Compute Optimizer?
• AWS : Instance Scheduler on AWS
• AWS : What are Savings Plans?
• AWS : Amazon EC2 Spot Instances
• AWS : Spot Instance interruption notices
• AWS : AWS Graviton Processor
• AWS : Managing the lifecycle of objects (Amazon S3)
• AWS : Pricing for NAT gateways
• AWS : AWS Cost Anomaly Detection
• AWS : Cost Optimization Hub
• AWS : What is AWS Data Exports?
• AWS : Amazon Bedrock pricing
• AWS : Amazon Bedrock inference profiles