Les alarmes PromQL de CloudWatch peuvent désormais déclencher Auto Scaling : les groupes EC2 prennent en charge les politiques simples et par paliers mais pas le suivi de cible, le tableau du guide indique des paliers seulement pour Application Auto Scaling, ce qui diffère de l'ouverture « paliers et simples » de l'annonce, et la requête doit renvoyer une seule série

Le 10 novembre 2026, AWS a annoncé que les alarmes Amazon CloudWatch écrites en Prometheus Query Language (PromQL) peuvent désormais déclencher des politiques de dimensionnement d'Amazon EC2 Auto Scaling et d'Application Auto Scaling. L'annonce dit qu'on peut dimensionner des groupes EC2 Auto Scaling à partir des métriques OpenTelemetry de CloudWatch avec le même genre de requêtes PromQL que pour les tableaux de bord et l'alerte. Pour les équipes qui migrent vers OpenTelemetry, l'avantage annoncé est que la capacité peut suivre les mêmes métriques que le reste de leur supervision, au lieu d'un second jeu d'alarmes classiques conservées uniquement pour le dimensionnement. Ce compte rendu s'appuie sur l'annonce d'AWS et sur deux pages du guide de l'utilisateur de CloudWatch, l'une sur les alarmes PromQL, l'autre sur les actions d'alarme. Il n'a pas créé d'alarme ni mené de test de dimensionnement.

Le point le plus important est ce qui est pris en charge et ce qui ne l'est pas. L'annonce dit que les alarmes PromQL prennent désormais en charge les politiques de dimensionnement simples et par paliers d'EC2 Auto Scaling, et que le suivi de cible n'est pas actuellement un type de politique pris en charge pour les alarmes PromQL. La page des actions d'alarme comporte un tableau qui place cela à côté d'autres types d'alarme. Pour les actions sur les groupes Auto Scaling, une alarme de métrique standard prend en charge simple, par paliers et suivi de cible, une alarme PromQL prend en charge simple et par paliers, et l'alarme à séries temporelles multiples de Metrics Insights et l'alarme de journal sont indiquées comme non prises en charge. Pour les actions Application Auto Scaling, une alarme de métrique standard prend en charge les paliers et le suivi de cible, et une alarme PromQL les paliers seulement. Cela ne concorde pas avec la première phrase de l'annonce, qui dit que les alarmes PromQL peuvent déclencher des « politiques de dimensionnement par paliers et simples d'Amazon EC2 et d'Application Auto Scaling ». Le tableau du guide est plus précis. Le conseil prudent de ce compte rendu, et non une déclaration d'AWS, est qu'un lecteur qui prévoit de dimensionner des services ECS, des tables DynamoDB, des réplicas Aurora ou des flottes Spot avec une alarme PromQL planifie avec des politiques par paliers seulement jusqu'à ce qu'AWS précise.

La façon dont l'alarme pilote la politique demande une règle. Pour le dimensionnement par paliers, l'annonce dit que l'écart entre la valeur de votre requête PromQL et le seuil décide du palier appliqué. La requête doit renvoyer une seule série et la comparer à un seuil. Le guide PromQL dit la même chose dans les étapes ordinaires de création d'une alarme PromQL : la requête doit renvoyer une seule série temporelle pour que l'alarme puisse l'évaluer. Le même guide a aussi une section distincte sur la détection d'anomalies, où chaque série temporelle en infraction est suivie comme contributeur distinct sur tout un parc, et le tableau des actions d'alarme classe certaines actions des alarmes PromQL au niveau du contributeur. Aucune des deux sources ne dit que ce mode par contributeur peut piloter une politique de dimensionnement ; ce compte rendu ne le suppose donc pas. L'exigence porte sur le résultat : la requête doit aboutir à une seule série. Pour tirer un seul signal de dimensionnement de plusieurs instances ou étiquettes, une agrégation, par exemple en un chiffre pour tout le parc, est une façon d'y arriver, et l'agrégation qui convient dépend de ce que mesure la métrique. L'annonce ne donne pas de requête d'exemple, et ce compte rendu n'en indique pas.

Une deuxième condition concerne la répétition. Le guide des actions d'alarme dit que, sauf pour les actions Auto Scaling, les actions d'alarme n'ont lieu qu'aux transitions d'état et ne sont pas refaites si la condition persiste pendant des heures ou des jours. Les actions Auto Scaling sont l'exception, ce qui signifie qu'elles peuvent se répéter tant que la condition persiste. Le guide le dit pour les actions Auto Scaling en général, pas spécifiquement pour les alarmes PromQL, et il ne décrit pas le comportement de période de refroidissement ou de préchauffage. Les équipes qui déplacent la logique de dimensionnement des alarmes classiques vers les alarmes PromQL devraient vérifier les réglages de la politique EC2 Auto Scaling qui régissent les déclenchements répétés, car les sources ne le font pas.

La configuration passe par des outils connus. L'annonce dit qu'on peut ajouter des actions EC2 Auto Scaling et Application Auto Scaling dans la console CloudWatch à la création ou à la modification d'une alarme, ou avec l'API PutMetricAlarm, l'AWS CLI, les kits SDK d'AWS ou AWS CloudFormation. Le guide PromQL décrit le chemin par la console : sur la page des alarmes, choisir Créer une alarme, choisir Sélectionner une métrique, puis l'onglet PromQL, saisir la requête, régler le seuil, la période d'évaluation et les points de données pour déclencher l'alarme, puis configurer les actions. Il dit aussi qu'on peut créer une alarme à partir d'une requête exécutée dans Query Studio lorsque la requête renvoie une seule série temporelle. Pour le dimensionnement simple et par paliers, le guide des actions d'alarme dit qu'on crée l'alarme de métrique CloudWatch et qu'on l'attache à la politique. Pour le suivi de cible, c'est le service Auto Scaling qui crée et gère lui-même les alarmes, qu'il ne faut ni modifier ni supprimer. Le guide présente cela comme la façon dont ces alarmes sont gérées, pas comme la raison pour laquelle les alarmes PromQL ne prennent pas en charge le suivi de cible, et l'annonce ne donne pas de raison non plus.

Deux limites d'exploitation sont visibles dans le guide. Les alarmes composites ne peuvent pas déclencher d'actions Auto Scaling. Et les alarmes PromQL n'incluent ni raison d'état ni données de raison d'état dans leurs notifications, contrairement aux alarmes à métrique unique, qui montrent les points de données précis à l'origine du changement d'état. Quand un événement de dimensionnement paraît anormal, le message d'alarme contiendra moins de détails pour l'expliquer. Une équipe devrait prévoir de vérifier directement la requête PromQL et les métriques sous-jacentes. Les sources indiquent aussi que les alarmes PromQL ne prennent pas en charge les actions EC2 comme l'arrêt ou le redémarrage, les OpsItems et incidents de Systems Manager, ni les investigations CloudWatch : une alarme PromQL utilisée pour le dimensionnement ne peut donc pas porter aussi ces actions.

Sur la disponibilité et le coût, l'annonce dit que la fonction est disponible dans toutes les régions AWS où les alarmes PromQL de CloudWatch sont disponibles, et que la tarification standard des alarmes CloudWatch s'applique. Elle ne nomme aucune région ni aucun prix. Les sources ne donnent aucune mesure de la rapidité de réaction d'une alarme PromQL par rapport à une alarme de métrique classique : une équipe qui dimensionne sur de courtes rafales devrait tester le délai entre un changement de métrique et un changement de capacité. Les sources soutiennent une affirmation étroite : pour les groupes EC2 Auto Scaling, les politiques simples et par paliers peuvent désormais être pilotées par une alarme PromQL qui renvoie une seule série, et le suivi de cible ne le peut pas.