Le tableau de bord Compute Optimizer d’un compte AWS établi en 2026 montre 47 recommandations de right-sizing EC2 avec 11 k$/mois d’économies projetées. Les recommandations semblent défendables — la plupart sont des descentes d’une marche (m6i.2xlarge à m6i.xlarge, r6i.4xlarge à r6i.2xlarge). La tentation est d’accepter en masse et de capturer les économies. Le bon mouvement est de lire chaque recommandation contre la forme de la charge, parce que Compute Optimizer est vraiment bon sur les charges en état stable et aveugle à deux patrons spécifiques qui apparaissent dans les recommandations malgré tout. Cet article se complète avec l’approche right-sizing par p95 — Compute Optimizer est le moteur, p95 est la porte.

Ce qui se passe

Compute Optimizer est le moteur de right-sizing d’AWS. Il lit 14 jours de métriques CloudWatch (CPU, mémoire si l’agent CloudWatch est installé, I/O réseau, IOPS EBS, débit EBS), les passe contre une bibliothèque de benchmarks de types d’instances, et recommande un type cible. La recommandation inclut un score de risque de performance (low/medium/high), des économies projetées et les métriques qui ont conduit la décision.

Les types de ressources couverts :

Instances EC2 — recommandations de type d’instance contre l’usage réel de la charge.
Auto Scaling groups — recommandations niveau groupe incluant le type d’instance et le mélange suggéré.
Fonctions Lambda — recommandations de taille mémoire (parce que le CPU de Lambda est alloué proportionnellement à la mémoire, c’est aussi une recommandation CPU indirecte).
Volumes EBS — recommandations de type (gp2 → gp3 est le classique), et right-sizing IOPS/débit pour gp3 et io2.
Services ECS sur Fargate — recommandations CPU/mémoire au niveau task.
Instances RDS (depuis 2024) — moteur, version, classe d’instance.

La fenêtre de 14 jours est la calibration clé. Compute Optimizer suppose que les 14 derniers jours sont représentatifs. Pour la plupart des charges en état stable, c’est correct. Pour les charges où la fenêtre de 14 jours rate un pic connu — batch de fin de mois, rapport de fin de trimestre, exécution annuelle de conformité — les recommandations sont calibrées contre une période plus calme et la recommandation sera trop agressive.

Les endroits où le moteur est aveugle :

Charges en pics. Une charge qui tourne à 5 % CPU pendant 23 heures et 95 % CPU pendant 1 heure a une moyenne autour de 8 %, ce qui ressemble à un over-spec clair. La moyennisation de Compute Optimizer va recommander une descente qui ne peut absorber le pic horaire. Le score de risque de performance est censé signaler ça, mais il n’attrape que les pics les plus extrêmes ; les modérés passent avec un score Low.
Familles d’instances burstable (t3, t4g). La métrique d’utilisation CPU sur une instance burstable lit bas parce que l’instance est en throttling quand les crédits sont épuisés — la charge consommerait plus de CPU s’il y en avait plus de disponible, mais le throttling ressemble à de la sous-utilisation. Compute Optimizer respecte ça en grande partie mais les recommandations proposent parfois de descendre dans la famille burstable vers une t-class plus petite, ce qui aggrave le problème d’épuisement de crédit.
Charges memory-bound sans l’agent CloudWatch. Sans l’agent installé, Compute Optimizer n’a pas de donnée mémoire et traite la recommandation comme mémoire-aveugle. La recommandation peut descendre un r6i.xlarge memory-bound vers un c6i.xlarge CPU-équivalent qui a la moitié de la mémoire, et la charge OOM.
Charges avec contraintes débit réseau ou EBS non capturées par les moyennes. Une charge bursty sur I/O réseau et jamais CPU-bound a l’air idle au moteur. Le right-size vers un type d’instance plus petit peut traverser le plafond de débit réseau sur la plus petite instance pendant un pic que la plus grande absorbait de manière transparente.

Comment vérifier

Tirer l’ensemble courant de recommandations :

aws compute-optimizer get-ec2-instance-recommendations \
  --query 'instanceRecommendations[].[instanceArn,currentInstanceType,recommendationOptions[0].instanceType,recommendationOptions[0].performanceRisk,recommendationOptions[0].projectedUtilizationMetrics[?name==`CPU`].value|[0]]' \
  --output table

Pour chaque recommandation, obtenir le détail sur les métriques qui l’ont conduite :

aws compute-optimizer get-ec2-instance-recommendations \
  --instance-arns arn:aws:ec2:us-east-1:123:instance/i-0123456789abcdef0 \
  --query 'instanceRecommendations[].utilizationMetrics' \
  --output yaml

Le bloc utilizationMetrics liste les valeurs maximum, moyenne et percentile que le moteur a vues sur la fenêtre de 14 jours. Les valeurs à repérer :

Si CPU.value montre un maximum près de 100 % mais une moyenne près de 5 %, la charge est en pics et la recommandation est dangereuse sans vérification manuelle.
Si les métriques mémoire sont absentes (pas de ligne MEMORY dans la sortie), la recommandation est mémoire-aveugle.
Si les métriques réseau montrent un maximum près du plafond de bande passante de l’instance, la charge est réseau-bound et la descente peut traverser le plafond de la plus petite instance.

Pour l’approbation spécifique à la charge, lancer la requête p95 CloudWatch de l’article right-sizing-par-p95 sur la même instance. La recommandation de Compute Optimizer et le p95 par minute doivent s’accorder. Si Compute Optimizer dit descendre et le p95 par minute est au-dessus de 70 %, le moteur a moyenné à travers un pic.

La correction

Les règles d’approbation avant d’accepter toute recommandation Compute Optimizer :

Vérifier le score de risque de performance. Accepter les recommandations Low risk sur les charges en état stable. Retenir les recommandations Medium et High risk pour une revue manuelle. Le score de risque reflète la confiance du moteur ; s’il hésite, prendre l’hésitation au sérieux.

Lancer la requête p95 par minute en parallèle. Pour chaque candidat à descente Low risk, tirer le p95 CPU par minute sur la même fenêtre de 14 jours :

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --start-time $(date -u -v-14d +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 60 \
  --extended-statistics p95 \
  --query 'Datapoints[].ExtendedStatistics.p95' \
  --output text | sort -n | tail -1

Le p95 par minute maximum doit être sous 60 % pour qu’une descente d’une marche soit sûre. Si Compute Optimizer dit descendre mais le p95 par minute est à 78 %, le moteur a moyenné à travers un pic.

Vérifier la forme de charge (famille burstable). Si l’instance est t3/t4g, tirer CPUCreditBalance :

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUCreditBalance \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --start-time $(date -u -v-14d +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 300 \
  --statistics Minimum \
  --query 'Datapoints[].Minimum' \
  --output text | sort -n | head -1

Le solde de crédit minimum sur 14 jours. S’il a touché zéro à un moment, l’instance était CPU-throttlée et la métrique CPU est artificiellement basse. Ne pas descendre dans la famille burstable. Sortir la charge du burstable complètement (vers c6i ou m6i) ou monter dans le burstable vers une t-class plus grande.

Confirmer que la donnée mémoire est présente. Si Compute Optimizer dit descendre et MEMORY est absent de utilizationMetrics, la recommandation est mémoire-aveugle. Installer l’agent CloudWatch, attendre deux semaines pour que l’historique de métriques se peuple, puis réévaluer.
Vérifier l’alignement du pic quotidien. Tirer la métrique groupée par heure-du-jour pour voir quand le pic survient :
```
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --start-time $(date -u -v-14d +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 3600 \
  --extended-statistics p95 \
  --query 'Datapoints[?ExtendedStatistics.p95 > `60`]' \
  --output yaml
```
Les lignes de sortie sont les heures qui ont dépassé 60 % p95. Si elles se groupent à un moment précis (03:00 UTC pour un batch nocturne, 13:00 UTC pour un pic d’heures ouvrées), le type d’instance plus petit frappera ce pic plus dur. La descente peut quand même être sûre, mais l’astreinte doit être informée de l’heure-du-jour pour que le prochain incident ne soit pas une surprise.
Right-size d’une marche à la fois. Compute Optimizer recommande parfois une descente de deux marches (m6i.4xlarge à m6i.xlarge). Accepter d’abord la recommandation d’une marche (m6i.4xlarge à m6i.2xlarge), surveiller pendant un cycle métier, puis accepter la marche suivante si la nouvelle instance reste confortable. Les économies sont capturées à 90 % à la première marche ; le gain marginal sur la seconde vaut rarement le risque doublé.
Attendre un cycle métier après chaque redimensionnement. Confirmer à la nouvelle taille que le p95 par minute de la charge atterrit dans la bande de confort 40-60 % avant d’accepter la recommandation suivante pour la même instance.

Pour les recommandations ASG, l’approbation est légèrement différente. Compute Optimizer évalue le type d’instance mais le mélange ASG et la politique de scaling interagissent d’une façon que le moteur ne modélise pas. Un ASG faisant tourner une politique target-tracking à 50 % CPU sur m6i.xlarge est la bonne configuration ; une descente vers m6i.large ferait seulement que l’ASG lance deux fois plus d’instances, sans changement net de coût et pire fiabilité au niveau instance. N’accepter les recommandations ASG qu’avec la politique target-tracking révisée en même temps.

Pour les recommandations Lambda, la suggestion d’accordage mémoire du moteur est en général correcte parce que le modèle de facturation Lambda est direct (Go-secondes), et une fonction qui tourne en 800 Mo à 200 ms pourrait tourner en 1 Go à 120 ms et coûter moins au total. Accepter celles-ci librement ; le rollback est un changement de paramètre.

Pour les recommandations EBS, la migration gp2-vers-gp3 est essentiellement de l’argent gratuit — gp3 est plus rapide et moins cher que gp2 pour la grande majorité des charges. Accepter celles-ci en masse. Le right-sizing IOPS/débit sur gp3/io2 mérite plus de soin parce qu’une descente sous l’enveloppe de burst de la charge cause un throttling de débit qui ressemble à de la latence applicative.

Trois règles sur chaque mission Compute Optimizer :

Score de risque Low + p95 < 60 % = accepter. Les deux signaux d’accord, c’est la bande sûre à accepter. L’un seul ne suffit pas.

Les charges en famille burstable nécessitent la vérif du solde de crédit. Compute Optimizer respecte le burstable la plupart du temps, mais les recommandations sur les charges t-class nécessitent la vérif du solde de crédit avant toute descente.

Une marche, un cycle métier, puis réévaluer. Empiler les right-sizes sans attendre l’historique de métriques compose le risque à chaque étape.

La passe Compute Optimizer sur un parc de 200 instances, avec la discipline d’approbation appliquée, capture 60 à 80 % des économies projetées par le moteur en sécurité. Les 20 à 40 % que l’équipe rejette pour motifs d’approbation sont les recommandations qui auraient causé des incidents — et le score de risque du moteur ne les signalait pas toujours, ce qui est la raison pour laquelle la porte manuelle existe.

Stack Harbor opère le nettoyage IAM, la baseline CloudWatch, AWS Backup et le rythme de contrôle des coûts dans le cadre de Gestion AWS et des Environnements infogérés en continu. Si les recommandations Compute Optimizer dorment dans le tableau de bord pendant des mois parce que personne n’a le temps de les valider, commencez par une consultation d’infrastructure.