Alarmes PromQL CloudWatch : piloter l’autoscaling EC2

Le 10 novembre 2026, AWS a annoncé que les alarmes CloudWatch fondées sur PromQL peuvent déclencher des politiques de mise à l’échelle d’EC2 Auto Scaling et d’Application Auto Scaling. Concrètement, vous pouvez faire croître ou réduire un groupe d’instances à partir de la même requête PromQL que celle de vos tableaux de bord. Si vos métriques applicatives passent déjà par OpenTelemetry vers CloudWatch, c’est utile. Sinon, vous pouvez passer votre tour.

Qu’est-ce qui a été annoncé, et qu’est-ce qui change?

L’annonce ajoute les alarmes PromQL comme source de déclenchement pour les politiques par paliers (step scaling) et les politiques simples d’EC2 Auto Scaling, ainsi que pour les politiques par paliers d’Application Auto Scaling. AWS précise deux choses importantes :

• La requête doit retourner une seule série temporelle, comparée à un seuil.
• Le suivi de cible (target tracking) n’est pas pris en charge pour les alarmes PromQL.

Vous configurez l’action dans la console CloudWatch, ou avec l’API PutMetricAlarm, la CLI, les SDK ou CloudFormation.

Combien ça coûte, et quelles sont les limites?

En date de novembre 2026, AWS indique que la tarification habituelle des alarmes CloudWatch s’applique et ne mentionne aucuns frais supplémentaires. Côté limites, le suivi de cible n’est pas pris en charge, et la requête doit retourner une seule série. L’annonce ne liste pas les régions : elle dit seulement que la fonction est offerte là où les alarmes PromQL le sont. Vérifiez donc votre région, notamment ca-central-1, dans la documentation.

1. 1Métrique OpenTelemetry
2. 2Requête PromQL
3. 3Alarme
4. 4Politique par paliers
5. 5Instances ajoutées

Le seuil fait partie de la requête PromQL elle-même.

Comment fonctionne une alarme PromQL?

La documentation CloudWatch explique qu’une alarme PromQL évalue une requête instantanée à intervalle régulier (EvaluationInterval). La requête sélectionne des métriques reçues par le point de terminaison OTLP de CloudWatch et ne retourne que les séries qui remplissent la condition. Chaque série retournée est un « contributeur » qui est considéré comme en dépassement.

Deux durées contrôlent les changements d’état :

• PendingPeriod : le temps qu’un contributeur doit dépasser sans interruption avant de passer à ALARM. C’est l’équivalent de la durée for d’une règle d’alerte Prometheus.
• RecoveryPeriod : le temps pendant lequel il doit cesser de dépasser avant de revenir à OK.

À la différence d’une alarme classique, le seuil est écrit dans la requête (par exemple > 5), pas dans une étape de configuration distincte. La page Créer une alarme avec une requête PromQL donne un exemple qui déclenche une politique d’Application Auto Scaling : la requête est enveloppée dans une fonction d’agrégation (par exemple avg, sum, max ou min), suivie de la comparaison, pour garantir une seule série.

Qui devrait s’y intéresser, et qui peut passer son tour?

Ça vaut la peine d’y jeter un œil si :

• vous mettez à l’échelle sur un signal propre à votre application (taux d’erreurs, durée de requête, profondeur d’une file) plutôt que sur le processeur;
• vous avez déjà investi dans OpenTelemetry et PromQL, et vous voulez un seul langage de requête pour les tableaux de bord, les alertes et l’autoscaling;
• votre mise à l’échelle actuelle repose sur des métriques personnalisées publiées avec des scripts maison.

Vous pouvez ignorer l’annonce si votre groupe se comporte bien avec le suivi de cible sur le processeur ou le nombre de requêtes par cible. La documentation d’EC2 Auto Scaling recommande fortement le suivi de cible pour des métriques comme le processeur moyen ou le nombre de requêtes par cible, et le conseille aussi quand la métrique varie proportionnellement à la capacité. Or, ce type de politique n’est justement pas offert avec les alarmes PromQL.

Comment fonctionne la mise à l’échelle par paliers?

Dans ce modèle, vous créez une alarme, puis une politique qui définit des paliers selon l’ampleur du dépassement. La documentation donne cet exemple : ajouter 10 % de la capacité quand la métrique atteint 60, puis 30 % à 70. Elle précise aussi les points suivants :

• Pendant la préparation (warmup) d’une nouvelle instance, les dépassements qui tombent dans le même palier ne causent qu’une seule activité de mise à l’échelle.
• Il faut prévoir un écart suffisant entre les seuils de croissance et de réduction, sinon le groupe oscille (flapping) : il ajoute puis retire des instances en boucle.
• Les paliers ne peuvent pas se chevaucher ni laisser de trou.

Avec une alarme PromQL, une seule série se compare à un seuil. Il faut donc agréger vous-même la requête (par exemple une moyenne sur l’ensemble des instances), puis choisir si le palier se mesure en nombre d’instances ou en pourcentage de la capacité.

Tant que l’alarme reste en dépassement, un nouveau palier peut s’appliquer.

Comment l’essayer en toute sécurité cette semaine?

1. Choisissez un groupe non critique, dans un compte de test ou de préproduction. Gardez le suivi de cible actuel sur le groupe de production.
2. Vérifiez que la métrique visée arrive bien dans CloudWatch par OpenTelemetry. Exécutez la requête dans Query Studio et confirmez qu’elle retourne une seule série.
3. Écrivez la requête avec agrégation et comparaison, puis créez l’alarme avec une PendingPeriod qui évite de réagir à un pic de quelques secondes. La plupart des exemples de la documentation d’AWS utilisent 60 à 300 secondes : c’est un point de départ à ajuster, pas une règle.
4. Définissez des paliers modestes, avec une capacité maximale du groupe qui plafonne la dépense.
5. Générez de la charge, observez les activités de mise à l’échelle et notez le délai entre le dépassement et l’instance prête.
6. Ajoutez une alarme distincte pour la réduction, avec un seuil assez éloigné pour éviter l’oscillation.

Par quoi commencerions-nous?

Avant d’adopter cette approche, nous commençons par ces questions :

• Le signal suit-il vraiment la capacité? Un taux d’erreurs peut monter pour une cause qui n’a rien à voir avec le nombre d’instances (une base de données saturée, par exemple). Ajouter des serveurs n’y changerait rien et coûterait de l’argent.
• Que se passe-t-il si la métrique disparaît? Une requête qui ne retourne rien veut dire « pas de dépassement ». Décidez comment vous serez averti d’une panne de la collecte.
• Quel est le plafond de dépense? La capacité maximale du groupe et une alerte de budget sont vos garde-fous.
• Le suivi de cible ne suffirait-il pas? Il est plus simple à maintenir. Les paliers se justifient quand le signal est propre à l’application.

Si vous voulez un regard d’expérience sur votre stratégie de mise à l’échelle et de fiabilité, notre page CTO fractionnel décrit notre façon de travailler.

Cet article est de l’information générale, pas un conseil d’architecture ni un avis financier. Consultez la documentation et les prix actuels d’AWS pour votre région avant de décider.