AWS Compute Optimizer 2026 : Guide Righ…

Q: Peut-on désactiver Compute Optimizer pour certains comptes ou tags ?

Oui. Depuis le compte administrateur délégué, utilisez update-enrollment-status --status Inactive par account-id. Vous pouvez aussi filtrer les recommandations affichées par tag via les recommendation preferences , sans désactiver le service.

Mis à jour : 6 août 2026

AWS Compute Optimizer est un service gratuit qui analyse les métriques CloudWatch de vos ressources et recommande, via machine learning, la taille optimale pour vos instances EC2, volumes EBS gp3/io2, fonctions Lambda, tâches ECS on Fargate, groupes Auto Scaling et instances RDS. En 2026, les équipes FinOps que j'accompagne réduisent en moyenne leur facture compute de 25 à 40 % simplement en appliquant les recommandations « medium risk » du service, sans changer une ligne de code applicatif.

AWS Compute Optimizer est gratuit ; seules les métriques CloudWatch étendues (Enhanced Infrastructure Metrics) sont facturées à 0,0003 $ par ressource et par heure.
Le service couvre désormais EC2, EBS, Lambda, RDS (MySQL, PostgreSQL, MariaDB), ECS on Fargate et Auto Scaling Groups. La couverture RDS a été généralisée fin 2024.
Les recommandations Graviton sont proposées automatiquement pour les workloads x86 compatibles, avec un gain moyen documenté de 20 % sur le prix/performance.
L'activation multi-comptes se fait via AWS Organizations en désignant un compte délégué administrateur. Comptez 12 h à 24 h pour le premier lot de recommandations.
Combiner Compute Optimizer avec des Compute Savings Plans permet de capturer les économies de right-sizing puis de verrouiller un tarif engagé sur les workloads restants.

Comment fonctionne AWS Compute Optimizer ?

Compute Optimizer ingère jusqu'à 14 jours de métriques CloudWatch par défaut (93 jours si vous activez les Enhanced Infrastructure Metrics) et applique des modèles de machine learning entraînés sur des millions de workloads AWS pour identifier trois catégories de ressources : sous-utilisées, sur-provisionnées ou déjà optimisées. Le moteur ne se contente pas de lire le CPU moyen. Il analyse la corrélation entre CPU, mémoire, disque IOPS et réseau pour éviter les faux positifs classiques (par exemple, une instance à 10 % de CPU mais qui sature ses IOPS EBS n'est pas « oversized »).

Depuis la mise à jour de mai 2024, le service intègre également les External Metrics : vous pouvez pousser vos métriques de mémoire depuis Datadog, Dynatrace ou New Relic via l'API PutRecommendationPreferences. C'est ce qui manquait pour les workloads Linux sans agent CloudWatch. Franchement, on n'a plus d'excuse pour ignorer la mémoire dans le calcul de right-sizing.

Chaque recommandation inclut une projected utilization post-redimensionnement, la performance risk (0 à 5) et une estimation d'économies mensuelles en dollars. Les recommandations sont rafraîchies toutes les 24 heures pour EC2 et Auto Scaling, et toutes les 12 heures pour Lambda.

AWS Compute Optimizer est-il gratuit ? Tarification 2026

Le service lui-même est gratuit pour tous les comptes AWS. Il n'y a pas de frais d'activation, pas de coût par recommandation, pas de coût par compte membre dans une organisation. C'est probablement l'un des outils AWS avec le meilleur ROI que vous puissiez activer aujourd'hui.

Deux options optionnelles sont facturées :

Enhanced Infrastructure Metrics : 0,0003 $ par ressource et par heure, soit environ 2,20 $/mois par instance EC2 ou volume EBS. Cette option étend l'historique de 14 à 93 jours, ce qui améliore significativement la précision des recommandations pour les workloads à saisonnalité mensuelle.
Rightsizing Recommendation Preferences : gratuit, mais nécessite un CloudWatch Agent (~0,30 $/GB de métriques custom) pour remonter les métriques mémoire (indispensable pour EC2 Linux).

Ressources supportées en 2026

La couverture s'est considérablement étendue depuis le lancement en 2019. Voici l'inventaire précis mi-2026 :

EC2 : toutes les familles générales (M, C, R, T, X), y compris Graviton (M8g, C8g, R8g) et Trn/Inf pour l'inférence ML. Les instances Mac et les Bare Metal sont exclues.
Auto Scaling Groups : recommandations pour ASG à type d'instance unique ou à politique mixte (mixed instances policy), pratique pour combiner Spot et On-Demand.
EBS : volumes gp2, gp3, io1, io2. Le service détecte les gp2 candidats à une migration gp3 (typiquement 20 % moins cher à performances équivalentes).
Lambda : fonctions x86 et arm64 (Graviton2), toutes les runtimes supportées.
ECS on Fargate : recommandations de CPU/mémoire par task definition.
RDS : instances DB pour MySQL, PostgreSQL, MariaDB. Le support a été généralisé fin 2024 après une longue phase de preview.

Aucun support pour DynamoDB, Aurora Serverless v2, OpenSearch ou ElastiCache. Pour ces services, il faut passer par des outils tiers ou l'analyse manuelle de CloudWatch. Pour couvrir DynamoDB, jetez un œil à notre guide sur les tags d'allocation des coûts AWS multi-comptes qui permet au moins d'attribuer et de suivre ces dépenses.

Activer Compute Optimizer en multi-comptes AWS Organizations

L'activation à l'échelle d'une organisation prend environ 5 minutes, mais la génération des premières recommandations demande 12 à 24 heures. Voici la procédure minimale via AWS CLI depuis le compte de gestion :

# 1. Depuis le compte de gestion (management account) - activer l'accès Organizations
aws organizations enable-aws-service-access \
  --service-principal compute-optimizer.amazonaws.com

# 2. Désigner un compte administrateur délégué (compte FinOps par exemple)
aws compute-optimizer put-delegated-administrator \
  --account-id 123456789012

# 3. Depuis le compte délégué - s'abonner pour l'organisation entière
aws compute-optimizer update-enrollment-status \
  --status Active \
  --include-member-accounts

# 4. Vérifier le statut d'enrôlement des comptes membres
aws compute-optimizer get-enrollment-statuses-for-organization \
  --query 'accountEnrollmentStatuses[?status==`Active`]' \
  --output table

Une fois activé, exportez régulièrement les recommandations vers S3 pour les intégrer dans QuickSight ou votre plateforme FinOps :

aws compute-optimizer export-ec2-instance-recommendations \
  --account-ids 111111111111 222222222222 \
  --s3-destination-config bucketName=finops-recommendations,keyPrefix=ec2/2026/ \
  --include-member-accounts \
  --file-format Csv

Interpréter les recommandations : risk, savings, effort

Chaque recommandation EC2 arrive avec trois dimensions à croiser avant d'agir. Ne les prenez jamais isolément : j'ai vu des équipes appliquer bêtement toutes les recommandations « HIGH savings » et provoquer une dégradation de latence en production parce qu'elles ignoraient le champ performance risk.

Finding : Underprovisioned, Overprovisioned, Optimized ou NotOptimized. Les instances Underprovisioned sont prioritaires ; elles indiquent souvent des saturations CPU/mémoire qui dégradent déjà la performance.
Performance risk : score de 0 (très faible) à 5 (très élevé). Sous 3, la recommandation est généralement sûre. Au-dessus de 3, testez d'abord en pré-production.
Estimated monthly savings : calculé au tarif On-Demand par défaut. Si vous êtes couvert par des Savings Plans ou RIs, réajustez ; les économies réelles seront plus faibles.
Migration effort : Very Low, Low, Medium, High. Un passage x86 vers Graviton est classé Medium car il implique un rebuild d'AMI et parfois des ajustements applicatifs.

Right-sizing EC2 : cas concret avec Graviton

Prenons un exemple réel d'un client SaaS que j'ai accompagné en 2025 : parc de 380 instances m5.2xlarge en production, utilisation CPU moyenne de 18 %, mémoire à 45 %. Compute Optimizer proposait deux chemins de recommandation :

Option	Configuration cible	Coût unitaire (eu-west-1)	Économies mensuelles	Risk
Actuel	m5.2xlarge	0,448 $/h	N/A	N/A
Right-size vertical	m5.xlarge	0,224 $/h	62 000 $/mois	2/5
Right-size + Graviton	m8g.xlarge	0,179 $/h	74 500 $/mois	3/5
Right-size + Graviton + SP	m8g.xlarge + Compute SP 3 ans	~0,110 $/h	92 000 $/mois	3/5

Le client a opté pour la troisième option en deux phases : d'abord la migration vers m8g.xlarge (test de 4 semaines en canary sur 10 % du parc), puis achat de Compute Savings Plans sur la baseline stable. Résultat sur 12 mois : 1,1 M$ économisés sur un budget compute annuel de 4,3 M$. Pour approfondir la logique d'engagement, notre comparatif AWS Savings Plans vs Reserved Instances 2026 détaille comment structurer la couverture.

Pour extraire les recommandations Graviton spécifiquement via CLI :

aws compute-optimizer get-ec2-instance-recommendations \
  --filters name=RecommendationSourceType,values=Ec2Instance \
  --query 'instanceRecommendations[?recommendationOptions[?instanceType!=null && contains(instanceType, `g.`)]].[instanceArn,currentInstanceType,recommendationOptions[0].instanceType,recommendationOptions[0].estimatedMonthlySavings.value]' \
  --output table

Optimiser les fonctions Lambda (mémoire et coût)

Le right-sizing Lambda est contre-intuitif : augmenter la mémoire réduit souvent le coût total. AWS alloue le CPU proportionnellement à la mémoire (1 vCPU par tranche de ~1 769 Mo), et une fonction 2× plus rapide facturée 2× plus cher par ms revient au même prix, mais avec une latence divisée par deux. Compute Optimizer identifie automatiquement ces cas.

Le service classe chaque fonction Lambda en quatre catégories :

Memory Over-provisioned : la fonction utilise moins de 60 % de la mémoire allouée sur ses invocations récentes.
Memory Under-provisioned : throttling ou out-of-memory errors détectés dans les logs.
Not Optimized : la configuration actuelle n'est ni la moins chère ni la plus rapide pour le pattern d'exécution observé.
Optimized : point d'équilibre coût/latence atteint.

Pour les fonctions Lambda éligibles à Graviton (arm64), la recommandation combine souvent un ajustement de mémoire et un basculement d'architecture, avec un gain typique de 34 % sur le coût de facturation ms.

Recommandations RDS et migration EBS gp3

La couverture RDS de Compute Optimizer est un des ajouts les plus impactants de 2024-2025. Le service analyse les métriques CPUUtilization, DatabaseConnections, FreeableMemory et NetworkThroughput pour recommander une classe d'instance différente ou un passage à Graviton (instances db.m7g, db.r7g). Sur les workloads OLTP, le gain moyen documenté par AWS est de 35 % en prix/performance versus x86.

Côté EBS, la recommandation majeure reste la migration gp2 vers gp3. Si vos volumes gp2 tournent en dessous de leurs IOPS baseline, gp3 offre les mêmes performances 20 % moins cher, sans changement applicatif. La migration se fait online :

# Migration d'un volume gp2 vers gp3 sans downtime
aws ec2 modify-volume \
  --volume-id vol-0abc123def456ghij \
  --volume-type gp3 \
  --iops 3000 \
  --throughput 125

# Suivre l'avancement (peut prendre plusieurs heures pour de gros volumes)
aws ec2 describe-volumes-modifications \
  --volume-ids vol-0abc123def456ghij \
  --query 'VolumesModifications[0].[ModificationState,Progress]'

Compute Optimizer vs Trusted Advisor vs Cost Explorer

Question qui revient systématiquement dans mes ateliers FinOps : quelle est la différence entre ces trois outils AWS et lequel utiliser ? Ils se recouvrent partiellement, mais ont des rôles distincts.

Critère	Compute Optimizer	Trusted Advisor (Cost)	Cost Explorer (Rightsizing)
Périmètre	EC2, EBS, Lambda, RDS, ECS, ASG	EC2, EBS, RDS, Redshift, ELB	EC2 uniquement
Moteur	Machine Learning, 14 à 93 jours	Règles heuristiques statiques	Règles basées sur CPU/mémoire moyens
Recommandations Graviton	Oui, natif	Non	Non
Multi-comptes natif	Oui (Organizations)	Oui (Business/Enterprise Support)	Oui
Coût	Gratuit (option EIM payante)	Enterprise Support requis pour toutes les checks	Gratuit
Métriques externes	Oui (Datadog, Dynatrace, etc.)	Non	Non
API d'export	Oui (S3, CSV/JSON)	Oui (API basique)	Oui

Ma recommandation : Compute Optimizer d'abord, systématiquement, parce que c'est gratuit et que son moteur ML est nettement plus fiable que les seuils statiques. Trusted Advisor reste utile pour ses checks non-compute (Elastic IPs non attachés, snapshots RDS orphelins). Cost Explorer Rightsizing devient redondant depuis que Compute Optimizer est disponible partout.

Automatiser les actions de right-sizing

Générer des recommandations c'est bien, les appliquer c'est mieux. Voici trois patterns d'automatisation que je déploie couramment chez mes clients :

Pipeline hebdomadaire d'export puis tagging : une Lambda déclenchée par EventBridge (chaque lundi 6h UTC) appelle export-ec2-instance-recommendations, parse le CSV et pose un tag compute-optimizer:recommendation=Downsize-to-m8g.large sur les instances candidates. Les équipes voient la recommandation directement dans la console EC2.
Change tickets automatiques : intégration Systems Manager Change Manager qui crée un ticket ServiceNow ou Jira par recommandation ayant plus de 500 $/mois d'économies estimées et un risk score ≤ 3.
Auto-remediation contrôlée : pour les environnements non-prod (dev/staging), une Step Function applique automatiquement les recommandations Low risk pendant les fenêtres de maintenance. Toujours prévoir un rollback via snapshot AMI/EBS avant modification.

Pour les workloads très élastiques (queues, batch), combiner ce right-sizing avec des instances Spot AWS, Azure et GCP multiplie les économies : right-sizing = 30 %, puis Spot = 70 % supplémentaires sur le prix restant, soit un effet cumulatif de ~80 % versus le baseline On-Demand.

Enfin, pour le suivi programmatique, la documentation officielle de l'API Compute Optimizer détaille tous les endpoints, et le guide utilisateur AWS Compute Optimizer couvre les prérequis IAM. Pour les tarifs à jour, référez-vous à la page pricing officielle.

Questions fréquentes

AWS Compute Optimizer analyse-t-il les instances arrêtées ?

Non. Le service ne produit des recommandations que pour les ressources ayant au moins 30 heures d'activité continue sur les 14 derniers jours. Les instances arrêtées, terminées ou récemment lancées sont ignorées jusqu'à accumulation d'assez de métriques CloudWatch.

Quelle est la précision des recommandations Compute Optimizer ?

D'après les études internes AWS partagées lors de re:Invent 2024, les recommandations à performance risk ≤ 2 atteignent 94 % de précision. Au-delà, la précision descend à environ 78 %, donc ces recommandations doivent être validées en pré-production avant application.

Peut-on désactiver Compute Optimizer pour certains comptes ou tags ?

Oui. Depuis le compte administrateur délégué, utilisez update-enrollment-status --status Inactive par account-id. Vous pouvez aussi filtrer les recommandations affichées par tag via les recommendation preferences, sans désactiver le service.

Compute Optimizer prend-il en compte les Savings Plans existants ?

Partiellement. Les économies estimées sont calculées au tarif On-Demand. Pour un calcul net, exportez les recommandations puis croisez avec le rapport Cost and Usage Report (CUR) filtré sur vos couvertures Savings Plans en cours. Un notebook QuickSight ou Athena fait ça en quelques requêtes SQL.

Faut-il installer un agent pour obtenir les recommandations mémoire EC2 ?

Oui pour Linux : le CloudWatch Agent doit publier la métrique mem_used_percent. Sur Windows, la métrique Memory % Committed Bytes In Use suffit. Alternativement, poussez vos métriques mémoire depuis Datadog ou Dynatrace via l'API External Metrics, ce qui est plus simple si vous avez déjà cette stack d'observabilité.