Les VMs surdimensionnées : le gaspillage silencieux qui plombe votre facture
Une instance m5.2xlarge provisionnée pour un pic de charge trimestriel qui ne dure que deux heures peut coûter cher, très cher, pendant les 2188 heures restantes. Ce sur-provisionnement est l’une des sources de gaspillage les plus courantes et les plus difficiles à traquer manuellement. Selon la FinOps Foundation (State of FinOps 2024), 32% des dépenses cloud sont identifiées comme du gaspillage. Une part significative de ce chiffre provient de machines virtuelles surdimensionnées. Maîtriser la taille machine virtuelle cloud rightsizing n’est donc pas une simple optimisation, c’est une discipline FinOps fondamentale pour toute entreprise qui souhaite contrôler sa trajectoire de coûts. Ce guide technique se concentre sur les méthodes et outils pour diagnostiquer et corriger ce problème de manière systématique.
Diagnostiquer le sur-provisionnement : les métriques au-delà de la moyenne
Le premier réflexe est souvent de regarder l’utilisation CPU moyenne. C’est un début, mais c’est insuffisant. Une machine peut afficher 10% de CPU en moyenne sur 24h tout en ayant des pics critiques à 95% pendant 15 minutes chaque heure. Réduire sa taille sur la base de la moyenne provoquerait des pannes. L’analyse doit être plus fine.
CPU : Average vs. Maximum
La métrique clé est le CPUUtilization (sur AWS/Azure) ou CPU usage (sur GCP). Il faut analyser à la fois la moyenne (Average) et le pic (Maximum) sur une période représentative, idéalement 14 à 30 jours pour lisser les cycles hebdomadaires. Une machine dont le CPU maximum ne dépasse jamais 40% sur un mois est un candidat évident au rightsizing.
J’utilise cette commande AWS CLI pour obtenir les pics d’utilisation sur deux semaines, afin d’éviter les faux positifs d’une moyenne trop lissée. Le delta entre la moyenne et le maximum révèle la vraie nature de la charge de travail.
# Récupère l'utilisation CPU maximale par heure sur 14 jours pour une instance EC2.
# Indispensable pour distinguer une faible utilisation constante d'une charge avec des pics.
aws cloudwatch get-metric-statistics \
--namespace AWS/EC2 \
--metric-name CPUUtilization \
--dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
--start-time 2024-01-01T00:00:00Z \
--end-time 2024-01-15T00:00:00Z \
--period 3600 \
--statistics Maximum \
--unit PercentMémoire : le point aveugle des outils natifs
La métrique d’utilisation de la RAM n’est pas disponible par défaut via les API des fournisseurs cloud, car elle est gérée par le système d’exploitation invité. Sans un agent (comme l’agent CloudWatch unifié, l’agent Azure Monitor ou l’Ops Agent de GCP), il est impossible de connaître l’utilisation réelle de la mémoire. C’est la principale limite des outils de rightsizing natifs comme AWS Compute Optimizer. Ils se basent majoritairement sur le CPU, ce qui peut mener à des recommandations risquées pour des applications gourmandes en mémoire (bases de données, caches).
Réseau et IOPS Disque
Le CPU et la RAM ne sont pas tout. Une instance peut être surdimensionnée en calcul mais correctement dimensionnée (ou même sous-dimensionnée) en bande passante réseau ou en IOPS pour ses disques EBS/Managed Disks. Changer de famille d’instances (par exemple, de m5 à t3) peut réduire le CPU et le coût, mais aussi dégrader les performances réseau et disque, créant un nouveau goulot d’étranglement. L’analyse doit donc inclure les métriques NetworkIn/Out et VolumeRead/WriteOps.
Guide pratique pour la taille machine virtuelle cloud rightsizing
Le rightsizing est un processus en quatre étapes : analyser, recommander, valider et implémenter. L’erreur classique est de sauter l’étape de validation.
1. Analyser avec les outils natifs
Avant d’investir dans un outil tiers, il faut maîtriser les solutions fournies par le cloud provider. Elles sont gratuites et souvent suffisantes pour une première passe.
- AWS Compute Optimizer : Analyse l’historique d’utilisation sur 14 jours et recommande jusqu’à 3 options de redimensionnement (EC2, EBS, Lambda). Sa principale faiblesse reste l’absence de visibilité sur la RAM sans l’agent CloudWatch.
- Azure Advisor : Fournit des recommandations de coût, notamment pour le redimensionnement ou l’arrêt de VMs sous-utilisées. L’analyse est plus basique que celle de Compute Optimizer.
- GCP Recommender : Utilise le machine learning pour suggérer des types de machines optimaux. L’intégration avec les métriques de l’Ops Agent pour la RAM le rend plus fiable que ses concurrents.
Cette commande GCP est mon point de départ pour vérifier la configuration actuelle d’une VM avant même de consulter les métriques. On trouve souvent des n2-standard-8 là où un e2-standard-2 suffirait amplement.
# Étape 1: Vérifier le type de machine actuel sur GCP.
gcloud compute instances describe ma-vm-gcp-prod-01 \
--zone=europe-west1-b \
--format='get(machineType)'
# Étape 2: Lister les alternatives moins chères dans la même famille (ici, E2).
gcloud compute machine-types list \
--filter="zone:(europe-west1-b) AND name~e2-" \
--limit=52. Valider les recommandations
Une recommandation automatique n’est pas un ordre. Il faut la confronter à la connaissance métier :
- Le propriétaire de l’application : Est-ce qu’un pic de charge est prévu (lancement produit, soldes) ? L’application est-elle sensible à la latence CPU (burst des séries T sur AWS) ?
- Le type d’environnement : On peut être plus agressif sur le rightsizing en développement ou en pré-production. Pour la production, une approche conservatrice est de ne réduire que d’une taille à la fois. Pour en savoir plus, consultez notre guide sur comment le rightsizing peut être fait sans casser la production.
3. Implémenter et monitorer
L’implémentation doit être planifiée pendant une fenêtre de maintenance, car elle nécessite un redémarrage de l’instance. Après le changement, il est crucial de surveiller attentivement les métriques de performance (CPU, latence) pour s’assurer qu’aucun nouveau problème n’est apparu.
Automatisation : la seule approche viable à l’échelle
Au-delà de 50 VMs, le rightsizing manuel devient un travail à plein temps. Les outils natifs montrent leurs limites : ils sont spécifiques à un seul cloud, requièrent une action manuelle pour chaque recommandation et manquent souvent de contexte métier. C’est là que des plateformes FinOps comme Thalaxo deviennent indispensables.
Une approche automatisée permet de :
- Analyser en continu : Au lieu d’un audit trimestriel, la plateforme surveille 24/7 les métriques d’utilisation, y compris la RAM grâce à une intégration avec les agents de monitoring.
- Gérer le multi-cloud : Elle agrège les données d’AWS, Azure et GCP pour offrir une vue unifiée et des recommandations cohérentes, ce qui est crucial alors que 63% des organisations ont une équipe FinOps dédiée, souvent face à un environnement multi-cloud (Flexera 2026 State of the Cloud Report).
- Appliquer des politiques : Elle peut automatiquement appliquer des changements sur les environnements de dev/staging, ou créer des tickets Jira avec le contexte nécessaire pour que les équipes valident les changements en production.
Thalaxo, par exemple, identifie une machine comme sur-provisionnée si son CPU reste sous 20% et sa RAM sous 30% pendant plus de 7 jours consécutifs. L’automatisation transforme une tâche réactive et chronophage en une discipline proactive et continue. Vous pouvez consulter nos intégrations pour voir comment nous nous connectons à votre stack. Pour comprendre comment cela se traduit en termes de coût, consultez nos tarifs.
Pour une analyse plus approfondie des modèles de coût, la FinOps Foundation est une ressource externe de grande qualité.
