Aller au contenu

AWS Mis à jour le 2026-07-04

Redimensionner EC2 en pratique : au-delà de ce que Compute Optimizer vous dit

Redimensionnement EC2 au-delà de Compute Optimizer : installer les métriques mémoire, tenir compte des crédits de rafale et des contraintes applicatives, et réduire sans causer d'incident.

Compute Optimizer est un bon point de départ pour redimensionner EC2, mais il ne voit que ce que CloudWatch voit — et par défaut, CloudWatch ne voit pas la mémoire. En pratique, le vrai redimensionnement est un exercice en trois temps : installer la télémétrie mémoire pour que les recommandations cessent d’être des devinettes basées sur le CPU seul, superposer ce que l’outil ne peut pas savoir (crédits de rafale, termes de licence, tas JVM, marge de basculement), puis réduire une instance à la fois avec un chemin de retour rapide. L’outil propose; l’opérateur dispose.

Ce qui se passe

Compute Optimizer analyse l’historique d’utilisation CloudWatch — 14 jours par défaut, jusqu’à 93 jours si vous payez pour les métriques d’infrastructure améliorées — et recommande des types d’instance mieux ajustés. Nous avons couvert l’outil lui-même dans le redimensionnement avec Compute Optimizer; cet article porte sur l’écart entre sa recommandation et un changement sécuritaire.

Les écarts qui comptent en production. Un : la mémoire est invisible sans l’agent CloudWatch — une instance à 20 % de CPU et 92 % de RAM ressemble à une candidate à la réduction pour toute analyse CPU seulement, et la rétrécir produit un incident d’OOM, pas une économie. Deux : les instances à rafale mentent au premier coup d’œil — une t3.large à 15 % de CPU moyen vit peut-être de ses crédits CPU, et le passage « évident » à une t3 plus petite s’effondre quand les crédits s’épuisent. Trois : l’outil ne connaît pas votre application — une JVM avec un tas fixe de 12 Go, une licence facturée au cœur, un nœud volontairement surdimensionné pour absorber le basculement d’un nœud partenaire ressemblent tous à du gaspillage dans un graphique d’utilisation. Quatre : les fenêtres de rétrospective manquent les cycles lents — clôtures de fin de mois, pointes saisonnières, lot d’audit annuel. Une fenêtre de 14 jours en mi-juillet ne sait rien de janvier.

Quoi vérifier d’abord

  • L’agent CloudWatch est-il déployé? S’il n’y a pas d’espace de noms CWAgent dans les métriques CloudWatch, toutes vos recommandations reposent sur CPU/réseau seulement. Corrigez ça avant d’agir sur quoi que ce soit.
  • Quelles instances sont à rafale? Tout ce qui est en famille T exige l’examen de son solde de crédits, pas juste de sa moyenne CPU.
  • Quelle génération utilisez-vous? Une m4 ou m5 à utilisation saine coûte quand même plus cher que l’équivalent de génération courante; la mise à niveau de génération à taille égale est l’économie la moins risquée qui soit.
  • Les candidates sont-elles dans un groupe Auto Scaling? Alors redimensionner veut dire éditer le modèle de lancement et laisser la rotation faire le travail — une procédure différente et plus sûre que de redimensionner des animaux de compagnie.
  • Quel est le pic, pas la moyenne? Tirez le p95/max sur 90 jours, pas la moyenne de deux semaines.

Comment vérifier

# La vue actuelle de Compute Optimizer
aws compute-optimizer get-ec2-instance-recommendations \
  --query 'instanceRecommendations[].[instanceArn,finding,currentInstanceType,recommendationOptions[0].instanceType]' \
  --output table

# CPU de pointe sur 90 jours, maximums quotidiens — pas la moyenne
aws cloudwatch get-metric-statistics --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --start-time 2026-04-05T00:00:00Z --end-time 2026-07-04T00:00:00Z \
  --period 86400 --statistics Maximum

# Mémoire, si l'agent CloudWatch rapporte
aws cloudwatch get-metric-statistics --namespace CWAgent \
  --metric-name mem_used_percent \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --start-time 2026-06-04T00:00:00Z --end-time 2026-07-04T00:00:00Z \
  --period 3600 --statistics Maximum

# Solde de crédits de rafale pour les instances de famille T
aws cloudwatch get-metric-statistics --namespace AWS/EC2 \
  --metric-name CPUCreditBalance \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --start-time 2026-06-27T00:00:00Z --end-time 2026-07-04T00:00:00Z \
  --period 3600 --statistics Minimum

Chemins console : EC2 > Instances > Monitoring pour les graphiques par instance, Compute Optimizer > EC2 instances pour la liste des constats. Un solde de crédits qui tend vers zéro pendant les heures d’affaires disqualifie une réduction en famille T. La mécanique du changement de type d’instance est dans la documentation EC2.

Le plan d’exécution

  1. Déployez l’agent CloudWatch sur toute la flotte d’abord. Via SSM Distributor ou votre gestion de configuration, avec mem_used_percent au minimum. Puis attendez deux semaines — agir sur des données CPU seulement, c’est comme ça que le redimensionnement s’est bâti sa mauvaise réputation.
  2. Prenez les gains gratuits : les mises à niveau de génération. Même taille, famille plus récente (m5.xlarge vers m7g.xlarge quand ARM est viable, ou m7i.xlarge sinon) coupe le coût à performance égale ou meilleure sans risque de capacité. Évaluez la compatibilité Graviton à part — c’est une décision de portage, pas de redimensionnement.
  3. Réduisez les cas clairs un cran à la fois. Les candidates avec p95 CPU sous ~30 % et p95 mémoire sous ~50 % sur 90 jours descendent d’une taille, jamais deux. Arrêt, changement de type, démarrage — quelques minutes d’indisponibilité pour une instance autonome, donc planifiez; pour les flottes en ASG, mettez à jour le modèle de lancement et faites rouler.
  4. Surveillez chaque changement pendant un cycle d’affaires complet. CPU, mémoire et les métriques de latence de l’application pendant au moins une semaine — incluant le lot hebdomadaire que l’instance roule en secret.
  5. Traitez les instances à rafale explicitement. Si une instance T brûle ses crédits chaque jour, elle est sous-dimensionnée peu importe sa moyenne; montez-la ou passez à une famille à performance fixe. Si elle ne touche jamais à ses crédits, elle est peut-être candidate à une taille de moins.
  6. Documentez les exceptions. Les instances gardées grosses pour des raisons de tas, de licence ou de basculement reçoivent une étiquette qui le dit — sinon la chasse du prochain trimestre rejuge les mêmes instances.

Quand c’est le mauvais choix

Ne redimensionnez pas pendant ou juste avant votre haute saison; les économies sont permanentes, mais les rapports d’incident aussi. Sautez les instances promises à la conteneurisation ou au remplacement dans le trimestre — l’effort vaut mieux sur la migration. Et dans un groupe Auto Scaling dont les politiques suivent déjà l’utilisation, rétrécir agressivement chaque instance ne fait surtout qu’augmenter le nombre d’instances; ajustez plutôt la cible de mise à l’échelle du groupe.

Erreurs courantes

  • Faire confiance à une recommandation de réduction calculée sans métriques mémoire.
  • Descendre de deux tailles d’un coup parce que les graphiques semblaient plats — le mode de défaillance n’est pas linéaire.
  • Ignorer la bande passante EBS et la base réseau : les instances plus petites reçoivent moins de débit EBS et de réseau, ce qui peut étrangler une charge intensive en E/S dont le CPU était pourtant tranquille.
  • Redimensionner l’instance mais pas le plan d’engagement — rétrécissez d’abord, puis dimensionnez votre plancher de Savings Plan, dans cet ordre.

Prévention

  • Gardez l’agent CloudWatch dans chaque AMI ou modèle de lancement pour que les données mémoire existent toujours.
  • Faites une revue de redimensionnement trimestrielle avec une rétrospective de 90 jours; de petites passes régulières battent les purges annuelles.
  • Imposez les types d’instance de génération courante dans les nouveaux modèles de lancement.
  • Consignez la raison du dimensionnement dans des étiquettes (sizing:reason=jvm-heap-12g) pour accélérer les revues futures.
  • Suivez le p95 d’utilisation de la flotte comme indicateur pour voir la dérive avant que la facture ne la montre.

Le redimensionnement n’est pas la sortie d’un outil; c’est une habitude appuyée sur de la télémétrie. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.