Sur les comptes AWS qu’on audite, le compute représente en moyenne 48 % de la facture. C’est le poste le plus lourd, et c’est aussi celui qui gaspille le plus, pour une raison assez simple : surprovisionner coûte moins cher à court terme que de se tromper. Une équipe qui doute monte d’un cran. Une équipe qui ne regarde pas l’usage réel ne redescend jamais. Sur trois ans et cinquante instances, l’écart finit par se voir nettement sur la facture.
Le bon réflexe, quand on prend en main un compte qu’on ne connaît pas, c’est de partir du plus visible et du moins risqué. Pas de toucher aux Savings Plans tant qu’on n’a pas calibré la baseline. Pas de migrer vers Graviton avant d’avoir testé la compatibilité applicative. Mais avant ça, il y a une dizaine d’actions plus modestes qui se font en quelques heures, sans engagement et sans risque, et qui retirent déjà 15 à 25 % de la facture compute. Cet article en présente cinq.
Aucune n’est exotique. Toutes sont documentées par AWS. La difficulté n’est pas technique. Elle est dans le fait que personne, dans l’organisation, n’est explicitement chargé de les chercher.
Cinq quick wins compute, dans l’ordre où on les applique : migration vers la génération d’instances courante (m5 vers m7i, ou m7g pour les workloads compatibles ARM), application des recommandations Compute Optimizer en commençant par les findings « Low risk », bascule sur les Savings Plans Compute après modélisation de la baseline 12 mois, identification des instances dormantes via les métriques CPU plates sur 30 jours, et arrêt programmé des environnements hors production en dehors des heures ouvrées.
Économies typiques cumulées : 20 % à 40 % de la facture compute, dont environ la moitié activable en moins d’une semaine. Les outils mobilisés sont tous natifs AWS (Cost Explorer, Compute Optimizer, CloudWatch metrics, Instance Scheduler) et aucune des cinq actions ne nécessite d’arrêt de production sur un workload correctement architecturé.
Il y a deux raisons mécaniques. La première, c’est qu’une instance EC2 facture à l’heure, qu’elle soit utilisée à 5 % ou à 95 % de ses capacités. Une m5.xlarge oubliée sur un environnement de pré-production tourne 730 heures par mois, soit environ 140 euros qui partent sans rien produire. La deuxième, c’est que le compute évolue plus vite que les habitudes : AWS sort une nouvelle génération tous les 12 à 18 mois, mais les Launch Templates, les modules Terraform et les playbooks Ansible continuent de référencer la génération avec laquelle l’équipe a démarré. Trois ans plus tard, on tourne encore sur m5 quand m7i est le standard du marché.
L’audit consiste essentiellement à corriger ces deux dérives. Pas à refondre l’architecture, pas à changer le pattern applicatif. À aligner ce qui tourne sur ce qui sert, et à le faire tourner sur la bonne génération.
C’est la première chose qu’on regarde, parce que c’est la plus indolore. AWS publie une nouvelle génération d’instances tous les 12 à 18 mois, avec un meilleur rapport prix/performance que la précédente, et continue de vendre les anciennes générations au même prix qu’avant. Concrètement, un workload qui tourne sur des m5.large en 2025 paie le même prix qu’en 2019 pour des performances inférieures à celles que la même somme achèterait aujourd’hui sur des m7i.large.
L’écart de génération typique qu’on rencontre est de deux ou trois crans. m5, m5a, parfois m4 sur les comptes les plus anciens. Le passage à m7i (Intel) à taille équivalente apporte entre 5 % et 15 % de gain prix/performance, sans changement d’architecture ni de configuration applicative. Pour les workloads Linux compatibles ARM64, c’est-à-dire la plupart des applications modernes qui ne dépendent pas d’une dépendance binaire x86, le passage à m7g (Graviton) ajoute environ 20 % de remise par rapport à m7i.
La détection est triviale : on liste les instances par famille via Cost Explorer ou la CLI, on croise avec la matrice de génération courante par région, et on identifie le delta. L’exécution dépend du contexte. Sur des ASG avec un Launch Template versionné, c’est une mise à jour du template suivie d’un rolling refresh, quelques minutes par groupe. Sur des instances stand-alone, c’est un arrêt-redémarrage avec changement de type, fenêtré sur la maintenance habituelle. Sur Graviton, on ajoute une étape de validation en pré-production parce que la compatibilité ARM64 ne se présume pas, même si elle est devenue la norme.
Compute Optimizer est probablement le service AWS le plus sous-utilisé par rapport à ce qu’il rapporte. Activé gratuitement au niveau Organizations, il analyse 14 jours de métriques CloudWatch sur chaque instance et propose une recommandation de redimensionnement, classée par niveau de risque (Low, Medium, High). Le service est là, les recommandations sont prêtes, et pourtant la plupart des comptes qu’on audite n’ont jamais consulté la console Compute Optimizer.
L’erreur fréquente, quand on commence à attaquer les findings, c’est de partir des plus gros gains. C’est tentant : Compute Optimizer affiche les économies estimées en euros, et on a envie de prendre la ligne du haut. Sauf que les plus gros gains sont presque toujours sur des instances stateful ou des bases managées, là où le risque est le plus élevé. On commence donc par autre chose.
La règle qu’on applique : tout ce qui est Low risk sur des workloads stateless (ASG d’application, instances de calcul batch, instances de build CI) passe en première semaine, en application directe via mise à jour du Launch Template. Tout ce qui est Low risk sur du stateful (RDS, ElastiCache) attend une validation en pré-production. Tout ce qui est Medium risk est reporté en deuxième semaine après validation. Tout ce qui est High risk, on s’assure d’avoir compris pourquoi avant d’y toucher, et ça devient souvent un projet à part entière plutôt qu’un quick win.
L’effet cumulé des Low risk stateless tourne autour de 8 à 15 % d’économie sur la portion compute concernée, en moins d’une semaine de mise en œuvre.
Les Savings Plans, c’est le levier d’économie le plus puissant qu’AWS propose, et c’est aussi celui qu’on rate le plus souvent. Trois patterns reviennent : l’absence totale d’engagement sur un workload pourtant stable depuis deux ans, un engagement souscrit à la louche sans modélisation préalable, et un Savings Plan arrivé à terme sans renouvellement. Les trois coûtent cher, mais pour des raisons différentes.
La méthode saine est la même dans les trois cas : avant de souscrire, on modélise. Cost Explorer, vue Savings Plans recommendations, période d’analyse à 7 jours, type d’engagement Compute Savings Plan (le plus flexible des trois), terme 1 an avec paiement No Upfront. On regarde le pourcentage de couverture recommandé, on le compare à la facture actuelle, et on vérifie que la baseline stable des 12 derniers mois (la portion de la facture qui ne descend jamais en dessous d’un certain seuil) couvre bien l’engagement proposé.
La règle qu’on suit en mission : on s’engage à 70 % de la baseline stable, pas plus. C’est conservateur, mais ça protège contre les décroissances imprévues (migration vers du serverless, downsizing après audit, perte d’un client). Le Compute Savings Plan offre 27 % de remise sur la portion engagée, donc même à 70 % de couverture, le gain est significatif. Et si l’usage continue de croître, on souscrit un deuxième Savings Plan dans 3 ou 6 mois, en couche.
L’erreur à éviter : les EC2 Instance Savings Plans (plus de remise mais engagement sur une famille précise) et les Reserved Instances classiques. La flexibilité du Compute Savings Plan, qui s’applique sur EC2, Fargate et Lambda, vaut largement les 7 % de remise supplémentaire qu’on perd en restant flexible.
Les instances dormantes sont les survivantes invisibles d’anciens projets. Une instance lancée pour un POC il y a deux ans et jamais arrêtée. Une base de données de staging qui sert encore d’archive consultée trois fois par an. Un worker batch dont le cron ne s’exécute plus mais que personne n’a osé supprimer « au cas où ». Sur la facture, elles ressemblent à toutes les autres instances. Sur les métriques, elles ont une signature très précise : CPU moyen sous 5 % sur 30 jours, network I/O quasi-nul, disk I/O proche de zéro hors processus système.
La détection se fait via CloudWatch metrics, croisée avec l’inventaire des instances. La requête type, en pseudo-CLI : describe-instances filtré sur les instances running, puis pour chacune get-metric-statistics sur CPUUtilization en moyenne sur 30 jours. Tout ce qui sort sous 5 % entre dans la liste de candidats. Sur un compte mature, on en trouve typiquement entre 5 % et 15 % du parc.
L’action n’est pas la suppression directe. C’est la mise en stop d’abord, avec une notification au propriétaire (d’où l’importance d’une stratégie de tags correcte, mais c’est un autre sujet). Si personne ne réagit pendant 14 jours, l’instance est terminée et son volume EBS associé est snapshoté avant suppression. Cette discipline d’observation préalable évite les erreurs sur les instances dont le pattern d’usage est ponctuel mais légitime (rendering une fois par mois, traitement de fin de trimestre).
Une instance de pré-production qui tourne 24/7 alors qu’elle n’est utilisée que pendant les heures ouvrées paie environ 4,5 fois trop. 168 heures par semaine facturées, contre 40 heures utilisées en pratique. Et pourtant, sur la quasi-totalité des comptes qu’on audite, les environnements de dev, staging et pré-prod tournent en permanence, par habitude.
AWS Instance Scheduler, déployable en quelques minutes via une stack CloudFormation, résout le problème de façon propre. On crée un schedule (heures ouvrées 8h-19h, lundi-vendredi), on tag les instances concernées avec Schedule=business-hours, et le scheduler les arrête et redémarre automatiquement. Pour les RDS de pré-prod, même principe. Pour les ASG, on utilise les Scheduled Actions natifs.
L’économie typique sur un environnement de pré-production qui passe de 24/7 à 11h × 5 jours/semaine est de l’ordre de 70 % du coût compute de ces instances. Sur un parc de 30 à 50 instances non-prod, c’est généralement plusieurs centaines d’euros par mois récupérés, à effort de mise en œuvre presque nul.
Le seul piège à connaître : certaines équipes développent en horaires décalés ou en remote sur d’autres fuseaux. Avant de pousser un schedule restrictif, on documente une procédure de réactivation à la demande (un simple start-instances avec confirmation), pour ne pas bloquer les usages légitimes.
« Le compute, c’est le poste où l’argent part le plus vite, et c’est aussi celui qui répond le plus vite à un audit. Une semaine de travail méthodique sur Compute Optimizer et les générations d’instances paie un trimestre de facture AWS. »
Julien MAUCLAIR
CTO, Co-Foundeur Stralya
Les cinq quick wins présentés couvrent ce qu’on attaque en première intention. Ils sont conçus pour produire un résultat mesurable rapidement, sans engager d’arbitrage architectural lourd. Mais ils laissent volontairement de côté trois sujets compute qui méritent un traitement à part, parce qu’ils demandent plus de temps, plus de compétences et une coordination avec les équipes produit.
Le premier, c’est la migration vers les architectures serverless. Sur un workload type API REST à trafic irrégulier, le passage d’EC2 ou ECS vers Lambda ou Fargate peut diviser la facture par trois ou quatre, mais demande une refonte applicative non négligeable (gestion du cold start, limites d’exécution, packaging). Ce n’est pas un quick win, c’est un projet de trimestre, qu’on identifie pendant l’audit pour le mettre dans la roadmap.
Le deuxième, c’est la conteneurisation pour les workloads qui ne le sont pas encore. Passer d’instances EC2 dédiées vers un cluster ECS ou EKS partagé permet de mutualiser les ressources et de monter le taux d’utilisation moyen de 20-30 % à 60-70 %. L’économie est réelle, mais la mise en place demande des compétences spécifiques et une discipline opérationnelle qui ne s’improvise pas.
Le troisième, c’est l’optimisation fine des workloads HPC, machine learning ou GPU, qui ont leurs propres patterns d’usage et leurs propres types d’instances optimisés (p, g, inf, trn). Sur ces workloads, les Savings Plans génériques ne suffisent pas, et la combinaison instance type / OS / runtime devient un sujet d’optimisation à part entière. C’est un domaine d’expertise distinct du FinOps généraliste.
Ces trois chantiers, on les laisse à leur place : après les quick wins, dans une roadmap d’optimisation à 3 ou 6 mois. Pas avant. Tenter une migration serverless sur un compte où Compute Optimizer n’a jamais été activé, c’est commencer le marathon par le dernier kilomètre.
Les cinq actions présentées dans cet article ne sont pas une découverte. Elles sont documentées par AWS, recommandées par les architectes solutions, et listées dans tous les guides FinOps sérieux. Ce qui les rend précieuses, ce n’est pas leur nouveauté, c’est leur ordre. Faire la génération d’instances avant les Savings Plans, c’est s’éviter de s’engager sur des prix qui vont baisser dans deux semaines. Faire Compute Optimizer avant la chasse aux instances dormantes, c’est éviter de supprimer des instances qu’il aurait suffi de redimensionner.
Sur un compte AWS d’une taille significative (10 000 € de facture mensuelle ou plus), l’effet cumulé de ces cinq actions tourne autour de 25 à 35 % d’économies récurrentes, dont la moitié est activable en moins d’une semaine. La deuxième moitié demande un peu plus de travail, mais aucune des cinq ne demande un projet à proprement parler. C’est de l’entretien méthodique, pas de la transformation.
Retrouvez un PDF complet et détaillé concernant cet article pour avoir plus d’informations
By submitting your email you agree to receive this case study and occasional updates from Stralya. We don’t share your data — see our privacy policy.
Un projet, une infra qui dérive, une facture qui explose. Dites-nous ce qui vous bloque à Paris, on revient avec un plan.
