Right-sizing EC2 et Compute Optimizer

Vous héritez d'un compte avec 40 serveurs web en m5.2xlarge. Toutes les instances sont saines. Aucune alarme depuis huit mois. CloudWatch montre un CPUUtilization moyen de 8 % avec des pics vers 22 %. La facture de calcul mensuelle tourne autour de 11 000 $, dont environ 8 000 $ achètent de la capacité que personne n'utilise.

Rien n'est cassé ici, et c'est exactement pour cela que personne ne regarde. Le right-sizing est la partie du métier CloudOps sans incident attaché, et l'examen la teste parce que les compétences sont les mêmes que celles utilisées quand quelque chose est cassé : lire correctement les métriques d'utilisation, savoir quelle métrique manque, et savoir quel outil répond à quelle question.

CPUUtilization n'est qu'une dimension sur quatre

CPUUtilization est la métrique vers laquelle tout le monde se tourne, et prise seule elle est quasiment inutile pour une décision de dimensionnement.

Une instance a au moins quatre dimensions de capacité qui peuvent s'épuiser indépendamment : CPU, mémoire, réseau et I/O de stockage. CloudWatch publie des métriques d'instance pour trois d'entre elles sans configuration. Il ne publie pas la mémoire, parce que l'hyperviseur ne voit pas à l'intérieur de l'invité. Pour AWS, la mémoire de votre système d'exploitation est opaque ; seul un agent qui tourne dans l'instance peut dire combien en est utilisée.

Cela produit une forme de panne précise et très fréquente : une application lente alors que CPUUtilization stagne à 12 %. L'instance manque de mémoire, le système d'exploitation swappe, et tous les graphes de la console ont l'air calmes. Si un scénario décrit un CPU bas et de mauvaises performances, la mémoire est la première piste, et l'action qui débloque le diagnostic est d'installer l'agent CloudWatch unifié pour que la mémoire devienne une métrique visible.

Le même angle mort touche l'outillage bâti sur ces métriques. Compute Optimizer analyse l'utilisation mémoire uniquement pour les ressources où l'agent CloudWatch est installé. Sans lui, vous obtenez des findings fondés sur le CPU, le réseau et les I/O, et le service recommandera tranquillement une instance plus petite pour une charge en réalité contrainte par la mémoire.

Ce que fait Compute Optimizer

AWS Compute Optimizer lit la configuration et les métriques d'utilisation CloudWatch de vos ressources et renvoie une configuration recommandée, avec l'utilisation projetée si vous l'adoptiez.

Quatre faits sur son fonctionnement structurent la plupart des questions d'examen :

Il faut l'activer. Il ne fait rien tant que vous ne l'avez pas activé pour un compte autonome, un compte membre ou le compte de gestion d'une organisation. Un scénario où « Compute Optimizer n'affiche aucune recommandation » s'arrête souvent là.

La fenêtre par défaut est de 14 jours. Il analyse les 14 derniers jours de métriques et rafraîchit ses recommandations chaque jour. Activer les enhanced infrastructure metrics, une préférence de recommandation payante, étend la fenêtre à 93 jours. C'est la réponse dès qu'une charge a une clôture mensuelle, un batch trimestriel ou n'importe quel pic qu'une fenêtre de 2 semaines manquerait entièrement.

Il lui faut assez de données. Les recommandations peuvent mettre jusqu'à 24 heures à apparaître après l'activation, et une ressource avec trop peu d'historique métrique n'obtient aucun finding.

Il couvre bien plus qu'EC2. Instances EC2 et Auto Scaling groups, volumes EBS, fonctions Lambda, services ECS sur Fargate, bases RDS et Aurora, DynamoDB, ElastiCache, MemoryDB, DocumentDB, NAT gateways, WorkSpaces, SageMaker et licences logicielles commerciales. Si une question demande quel service unique donne des recommandations de dimensionnement à la fois sur le calcul, le stockage et les bases de données, c'est celui-là.

Lire un finding

Chaque instance analysée tombe dans l'une de trois classifications :

La classification vous dit que quelque chose ne va pas. La finding reason vous dit quoi, et elle est précise : CPU over-provisioned, Memory under-provisioned, EBS throughput under-provisioned, EBS IOPS over-provisioned, Network bandwidth under-provisioned, Network PPS under-provisioned, Disk IOPS, Disk throughput, et leurs équivalents GPU. Chacune nomme la métrique dont elle est tirée, ce qui vous permet d'aller vérifier vous-même : les raisons EBS IOPS viennent de VolumeReadOps et VolumeWriteOps, la bande passante réseau de NetworkIn et NetworkOut, le PPS réseau de NetworkPacketsIn et NetworkPacketsOut.

Notez la distinction qui piège : les raisons Disk parlent des volumes instance store (DiskReadOps, DiskWriteBytes), tandis que les raisons EBS parlent des volumes EBS attachés. Matériel différent, correction différente. Un finding Disk se règle en changeant le type d'instance ; un finding EBS se règle souvent en modifiant le volume, ce que la leçon sur EBS couvrira en détail.

Chaque recommandation porte aussi un performance risk allant de very low à very high (0 à 4 dans l'API). C'est le score de risque maximal parmi toutes les spécifications analysées, et il répond à la question « quelle est la probabilité que ce type plus petit me déçoive ? ». Very low signifie que le type est prédit comme toujours suffisant. Tout ce qui est au-dessus invite à tester sous charge réelle d'abord.

Les instances burstable suivent d'autres règles

Tout ce qui précède suppose qu'une instance peut utiliser 100 % de son CPU quand elle le veut. Les instances T ne le peuvent pas, et c'est le point le plus testé du dimensionnement EC2.

Une instance burstable est vendue avec un niveau baseline de CPU qu'elle tient indéfiniment, plus un seau de crédits CPU qui lui permet de tourner au-dessus du baseline pendant un temps. Un crédit CPU vaut un vCPU à 100 % pendant une minute. Sous le baseline, l'instance gagne plus qu'elle ne dépense et le seau se remplit. Au-dessus, elle dépense plus qu'elle ne gagne et le seau se vide.

Voici une t3.large, qui a 2 vCPU, gagne 36 crédits par heure, a un baseline de 30 % et accumule jusqu'à 864 crédits (une journée entière de gain) :

• La demande monte à 55 % de CPU en continu.
• Crédits dépensés par minute = vCPU x utilisation = 2 x 0,55 = 1,1, soit 66 par heure.
• Crédits gagnés par heure = 36.
• Drainage net = 30 crédits par heure. En partant d'un solde plein de 864, le solde atteint zéro en environ 29 heures.

Ce qui se passe à zéro dépend du mode de configuration des crédits :

• Mode standard : l'instance est ramenée à son baseline. La CPU est bridée à 30 % et l'application ralentit, sans erreur, sans alarme et sans cause visible. C'est le défaut pour T2 et pour T3 sur un Dedicated Host.
• Mode unlimited : l'instance continue de tourner au-dessus du baseline en dépensant des crédits excédentaires. Si sa moyenne de CPU sur 24 heures glissantes reste au niveau du baseline ou en dessous, l'excédent est couvert par le tarif horaire normal. Sinon, vous payez un tarif forfaitaire supplémentaire par vCPU-heure. C'est le défaut pour T3, T3a et T4g.

L'idée fausse à nommer à voix haute : on lit « burstable » comme un bonus et on suppose que l'instance peut tenir un CPU élevé indéfiniment. Elle ne le peut pas, dans aucun des deux modes, sans conséquence. En mode standard, la conséquence est une falaise de performance environ une journée après la hausse de charge. En mode unlimited, la conséquence est une ligne de facture que personne n'attendait. La métrique qui prédit les deux est CPUCreditBalance, pas CPUUtilization, donc une flotte d'instances T a besoin d'une alarme sur le solde de crédits qui tend vers zéro. CPUSurplusCreditsCharged est celle à surveiller côté facturation.

Quelques faits de crédits supplémentaires à garder :

• La limite d'accumulation vaut toujours 24 heures de gain. Une t3.micro gagne 12 par heure et accumule 288 ; une t3.2xlarge gagne 192 par heure et accumule 4 608.
• Les pourcentages de baseline sont par vCPU et correspondent à ce qu'affiche CloudWatch. Une t3.large à son baseline se lit 30 % dans la console.
• Pour T3, T3a et T4g, les crédits accumulés survivent 7 jours à un arrêt. Pour T2 ils sont perdus dès l'arrêt de l'instance.
• Les launch credits n'existent que pour T2 en mode standard. T3 et les générations suivantes démarrent en mode unlimited, donc elles peuvent burster immédiatement sans en avoir besoin.

Si une instance T vit constamment au-dessus de son baseline, c'est la mauvaise instance pour cette charge. C'est un finding de right-sizing, pas un problème de réglage, et Compute Optimizer trace justement la ligne du baseline burstable sur son graphe CPU pour que vous le voyiez.

Redimensionner une instance en production

Une fois le finding obtenu, le changement lui-même est mécanique, et l'examen s'intéresse à l'ordre des opérations et aux effets de bord.

Pour une instance EBS-backed, changer le type exige que l'instance soit arrêtée :

aws ec2 stop-instances --instance-ids i-0abc123def4567890
aws ec2 wait instance-stopped --instance-ids i-0abc123def4567890

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123def4567890 \
  --instance-type "{\"Value\": \"m5.xlarge\"}"

aws ec2 start-instances --instance-ids i-0abc123def4567890

L'instance garde son ID, ses volumes EBS, ses security groups et son rôle IAM. Trois choses ne survivent pas au stop et start :

• Les données sur les volumes instance store, parce que l'instance change d'hôte physique.
• L'adresse IPv4 publique, sauf si une Elastic IP est associée.
• Le solde de crédits CPU sur une instance T2.

Les tags font la moitié organisationnelle de ce travail. Faire du right-sizing à l'échelle d'une flotte, c'est pouvoir répondre à « qui possède cette instance et dans quel environnement est-elle » avant de la redimensionner, ce qui explique que la Skill 1.3.1 du guide d'examen nomme les resource tags à côté des métriques de performance. Un jeu de tags cohérent Environment, Owner et Application transforme une liste de 400 findings en 12 conversations.

Pour les instances d'un Auto Scaling group, ne redimensionnez pas les instances une par une. Mettez à jour le launch template avec le nouveau type et lancez un instance refresh, pour que le changement soit durable et que le groupe remplace les instances de façon contrôlée.

Quel outil répond à quelle question

Trois services produisent des conseils qui se ressemblent, et les questions sont écrites pour les séparer.

L'indice : « recommander un type d'instance à partir de l'utilisation mesurée » désigne Compute Optimizer. « Montrez-moi les économies possibles à côté de ma facture » désigne Cost Explorer. « Vérifiez mon compte face à une liste de bonnes pratiques » désigne Trusted Advisor.

Conseils pour l'examen

• CPU bas plus application lente signifie mémoire. L'action qui débloque est d'installer l'agent CloudWatch, parce que la mémoire n'est pas une métrique CloudWatch par défaut et que Compute Optimizer ne peut pas l'analyser sans l'agent.
• « Batch mensuel », « pic trimestriel » ou « charge saisonnière » avec Compute Optimizer désigne les enhanced infrastructure metrics et leur fenêtre de 93 jours. Les 14 jours par défaut ne verraient jamais le pic.
• Une instance T qui devient lente environ une journée après une montée de charge est une question d'épuisement de crédits. La métrique est CPUCreditBalance ; la correction est soit le mode unlimited (en acceptant la facturation de l'excédent), soit une famille non burstable.
• Regardez quel défaut la question implique. T2 démarre en mode standard et bride ; T3, T3a et T4g démarrent en unlimited et facturent.
• Ne confondez pas les finding reasons Disk (instance store) avec les finding reasons EBS (volumes attachés). Elles mènent à des remédiations différentes.
• Changer un type d'instance exige l'instance arrêtée, et l'arrêter détruit les données instance store et libère une IP publique non Elastic.

L'habitude à emporter : avant de changer la taille d'une instance, sachez laquelle de ses quatre dimensions de capacité est réellement contrainte. Le CPU est celle que vous voyez par défaut, la mémoire est celle qu'il faut aller chercher, et pour les instances T la contrainte n'est pas une dimension mais un solde de crédits. La leçon suivante prend la troisième dimension, le réseau, et montre pourquoi une instance peut être très loin de sa bande passante annoncée et être quand même bridée.