Les leviers d'optimisation des coûts cloud qui produisent des résultats durables sont peu nombreux : supprimer ce qui ne sert pas, dimensionner au juste besoin, éteindre ce qui n'a pas à tourner, payer moins cher ce qui tourne en continu, placer les données au bon niveau de stockage et corriger l'architecture quand elle est la source du coût. La difficulté n'est pas de les connaître, mais de les appliquer dans le bon ordre et de façon continue.
L'ordre compte. Le FinOps Framework distingue l'optimisation de l'usage, qui consiste à consommer moins, de l'optimisation tarifaire, qui consiste à payer moins cher, et rappelle qu'un engagement n'est pas une ressource : il ne fait que couvrir des ressources en cours d'exécution 1. S'engager sur une capacité surdimensionnée revient donc à figer le gaspillage pour un à trois ans. Nettoyer et dimensionner d'abord, s'engager ensuite.
Les exemples ci-dessous s'appuient sur la documentation d'AWS, dont les chiffres sont publics et précis. Les mêmes mécanismes existent chez Azure, Google Cloud ou les fournisseurs européens, sous d'autres noms et avec d'autres conditions qu'il faut vérifier au cas par cas.
Dimensionnement : partir de l'usage réel, pas de l'estimation initiale
La plupart des ressources sont dimensionnées au moment du déploiement, sur une estimation prudente, puis jamais réévaluées. Les outils natifs des fournisseurs comparent la configuration à l'usage observé. AWS Compute Optimizer, par exemple, analyse par défaut 14 jours de métriques (processeur, mémoire, stockage et réseau pour EC2), période portée à 93 jours avec l'option payante de métriques étendues 2. Il couvre les instances et groupes Auto Scaling, les volumes EBS, les fonctions Lambda, les services ECS sur Fargate, les bases RDS et Aurora ainsi que plusieurs autres services managés, et identifie aussi les ressources inactives 2.
La fenêtre d'analyse est un vrai sujet : 14 jours ne capturent ni une clôture mensuelle ni un pic saisonnier. Pour les charges cycliques, il faut soit allonger la période, soit compléter l'analyse par la connaissance métier. Les recommandations gagnent aussi en fiabilité lorsque la mémoire est mesurée ; Compute Optimizer peut d'ailleurs intégrer des métriques mémoire issues d'outils d'observabilité tiers 2.
Le cas des conteneurs
Sur Kubernetes, le gaspillage se cache dans les requests. Le scheduler utilise la request déclarée pour choisir le nœud, et le kubelet réserve au moins cette quantité au conteneur 3. Une request surestimée bloque donc de la capacité qui ne sera jamais consommée mais que l'on paie, puisque des nœuds supplémentaires seront provisionnés pour accueillir les pods suivants. Ajuster les requests à l'usage observé est souvent le levier le plus rentable d'une plateforme de conteneurs.
- Lister les ressources sans activité depuis plusieurs semaines et confirmer leur suppression avec leur propriétaire.
- Supprimer les volumes non attachés et les adresses ou équilibreurs de charge orphelins.
- Appliquer les recommandations de redimensionnement en commençant par les environnements hors production.
- Revoir les requests CPU et mémoire des conteneurs à partir de l'usage mesuré.
- Programmer une revue trimestrielle plutôt qu'un nettoyage unique.
Arrêt planifié : le levier le plus rapide pour le hors production
Les environnements de développement, de test et de recette ne servent généralement qu'aux heures ouvrées. Un calcul simple suffit à mesurer l'enjeu : une semaine compte 168 heures, alors qu'un environnement utilisé douze heures par jour, cinq jours par semaine, ne sert que 60 heures. Tout ce qui tourne en dehors de ces plages est payé sans contrepartie.
L'automatisation repose sur des étiquettes et un ordonnanceur. La solution Instance Scheduler on AWS, par exemple, démarre et arrête selon un planning des instances EC2, des groupes Auto Scaling et des bases RDS identifiés par tag, sur plusieurs comptes et régions ; elle fournit une interface en ligne de commande pour estimer les économies d'un planning donné 4. Les autres fournisseurs proposent des équivalents.
Quelques précautions évitent que l'arrêt planifié ne soit désactivé au premier incident : prévoir une procédure simple de dérogation ponctuelle, documenter l'ordre de redémarrage des dépendances, vérifier que les traitements nocturnes ne tournent pas sur ces environnements et rappeler que le stockage attaché continue d'être facturé quand la machine est arrêtée.
Engagements et Spot : payer moins cher ce qui tourne vraiment
Une fois l'usage assaini, la partie stable de la consommation peut être couverte par des engagements. AWS propose quatre types de Savings Plans, avec des remises maximales par rapport au tarif à la demande de 72 % pour les EC2 Instance Savings Plans, 66 % pour les Compute Savings Plans, 64 % pour les SageMaker Savings Plans et 35 % pour les Database Savings Plans 5. L'engagement porte sur un ou trois ans, sur un an uniquement pour les Database Savings Plans, avec un paiement sans avance, partiel ou total 5. Ces taux sont des maximums : la remise réelle dépend du type, de la durée, de l'option de paiement et des ressources couvertes.
Pour les charges tolérantes aux interruptions, les instances Spot offrent jusqu'à 90 % de réduction par rapport au tarif à la demande 6. AWS les recommande pour les charges sans état ou flexibles : conteneurs, big data et machine learning, calcul haute performance, pipelines CI/CD, environnements de test et de développement 6.
Piloter le portefeuille d'engagements
La FinOps Foundation propose plusieurs indicateurs pour éviter de payer des engagements inutilisés 1 :
- Effective Savings Rate : économies nettes obtenues rapportées à la dépense équivalente au tarif à la demande.
- Taux d'utilisation des engagements : part de l'engagement effectivement consommée ; une valeur basse signale des engagements payés pour rien.
- Part du gaspillage d'engagements : coût des engagements inutilisés rapporté au coût total des engagements.
Au niveau de maturité le plus avancé, le portefeuille d'engagements est rééquilibré en continu à partir de seuils et de rapports automatisés, en lien avec les décisions d'architecture 1. À l'inverse, des achats ponctuels et non coordonnés, sans comparaison des options, caractérisent une pratique débutante 1.
Un engagement ne réduit pas la consommation : il réduit le prix d'une consommation que l'on a décidé de garder.
Stockage : le coût qui grossit sans bruit
Le stockage croît par accumulation : journaux, sauvegardes, instantanés, données intermédiaires de traitements. Personne ne décide de le garder, personne ne décide de le supprimer. Deux mécanismes complémentaires permettent de le maîtriser : les règles de cycle de vie, qui suppriment ou déplacent les données selon leur âge, et le tiering automatique selon la fréquence d'accès.
Sur Amazon S3, la classe Intelligent-Tiering déplace un objet non consulté depuis 30 jours consécutifs vers un niveau d'accès peu fréquent, puis après 90 jours vers un niveau d'archive à accès instantané, et le ramène au niveau d'accès fréquent dès qu'il est lu 7. AWS annonce jusqu'à 40 % d'économies sur le niveau d'accès peu fréquent et jusqu'à 68 % sur l'archive à accès instantané, sans frais de récupération, mais avec des frais mensuels de surveillance par objet ; les objets de moins de 128 Ko ne sont pas déplacés automatiquement 7. Pour des millions de petits fichiers, une règle de cycle de vie ou un regroupement des objets sera souvent plus pertinent.
- Fixer une durée de rétention pour chaque catégorie de données, en accord avec les obligations légales et le métier.
- Appliquer des règles de cycle de vie sur les journaux et les données intermédiaires.
- Supprimer les instantanés et sauvegardes orphelins dont la ressource source n'existe plus.
- Réserver le tiering automatique aux données dont le profil d'accès est réellement imprévisible.
Architecture : traiter la cause plutôt que le symptôme
Les leviers précédents agissent sur une architecture donnée. Certains coûts sont pourtant structurels : flux de données qui traversent les zones ou les régions, passerelles NAT empruntées par tout le trafic sortant, traitements permanents pour des charges intermittentes, réplication de données sans exigence de résilience correspondante. Le pilier Cost Optimization du AWS Well-Architected Framework définit une charge de travail optimisée comme une charge qui utilise pleinement ses ressources, atteint son résultat au prix le plus bas possible et répond à ses exigences fonctionnelles 8. Il insiste sur la gestion de l'offre et de la demande de ressources et sur l'optimisation dans la durée 8.
Ces chantiers ont un délai de retour plus long et demandent l'implication des architectes et des équipes produit. Ils doivent être priorisés comme n'importe quel élément du backlog, avec une estimation du gain et du coût de mise en œuvre. Compute Optimizer couvre d'ailleurs désormais les passerelles NAT, signe que ce poste est devenu un sujet d'optimisation à part entière 2.
Dans quel ordre agir
- Rendre les coûts visibles et rattachés à un propriétaire.
- Supprimer les ressources inutiles et éteindre le hors production en dehors des heures d'usage.
- Redimensionner les ressources et les requests de conteneurs.
- Mettre en place les règles de stockage.
- Couvrir la consommation stable restante par des engagements et basculer les charges tolérantes vers Spot.
- Inscrire les chantiers d'architecture au backlog, avec un gain estimé.
Conclusion
L'optimisation des coûts cloud qui dure n'est pas une campagne, c'est une routine : nettoyer, dimensionner, éteindre, puis seulement s'engager, en suivant quelques indicateurs simples. Les gains rapides financent les chantiers d'architecture, qui produisent les économies les plus pérennes. DATASWING aide les équipes à installer cette routine et à traiter les causes architecturales des coûts.
— Questions fréquentes
Ce qu'on nous demande souvent
Quel est le levier le plus rapide pour réduire sa facture cloud ?+
Dans la plupart des organisations, il s'agit de supprimer les ressources inutilisées et d'éteindre automatiquement les environnements hors production en dehors des heures ouvrées. Ces actions ne demandent ni engagement contractuel ni refonte. Un environnement utilisé soixante heures par semaine ne sert qu'un peu plus d'un tiers des 168 heures que compte une semaine.
Faut-il acheter des Savings Plans ou des instances réservées avant d'optimiser ?+
Non. Un engagement ne fait que couvrir des ressources en cours d'exécution : s'engager sur une capacité surdimensionnée fige le gaspillage pour un à trois ans. Il faut d'abord nettoyer et redimensionner, puis couvrir la consommation stable restante, en suivant le taux d'utilisation des engagements et l'Effective Savings Rate.
Quelle réduction offrent les instances Spot ?+
Chez AWS, les instances Spot sont proposées jusqu'à 90 % moins cher que le tarif à la demande. En contrepartie, elles peuvent être interrompues. Elles conviennent aux charges sans état, tolérantes aux pannes ou flexibles : pipelines CI/CD, traitements big data, calcul intensif, environnements de test ou conteneurs conçus pour être replanifiés.
S3 Intelligent-Tiering est-il toujours rentable ?+
Pas toujours. La classe déplace automatiquement les objets peu consultés vers des niveaux moins chers, sans frais de récupération, mais facture des frais de surveillance par objet, et les objets de moins de 128 Ko ne sont pas déplacés. Pour des données au profil d'accès prévisible ou de très nombreux petits fichiers, des règles de cycle de vie sont souvent préférables.
— Sources
Références citées
Les textes réglementaires et documentations évoluent : vérifiez la version en vigueur avant toute décision. Cet article n'est pas un avis juridique.
-
[1]
Rate Optimization (FinOps Framework capability) ↗FinOps Foundation · 2026
-
[2]
What is AWS Compute Optimizer? ↗Amazon Web Services · 2026
-
[3]
Resource Management for Pods and Containers ↗Kubernetes (CNCF) · 2026
-
[4]
Instance Scheduler on AWS ↗Amazon Web Services · 2026
-
[5]
Savings Plans FAQs ↗Amazon Web Services · 2026
-
[6]
Amazon EC2 Spot Instances ↗Amazon Web Services · 2026
-
[7]
Amazon S3 Intelligent-Tiering ↗Amazon Web Services · 2026
-
[8]
Cost Optimization Pillar - AWS Well-Architected Framework ↗Amazon Web Services · 2024-06
