CloudWatch PromQL Alarms Can Now Trigger Auto Scaling: EC2 Groups Support Simple and Step Policies but Not Target Tracking, the Guide's Table Shows Application Auto Scaling With Step Only, Which Differs From the Notice's "Step and Simple" Opening, and the Query Must Return a Single Series

On November 10, 2026, AWS announced that Amazon CloudWatch alarms written in the Prometheus Query Language (PromQL) can now trigger scaling policies for Amazon EC2 Auto Scaling and Application Auto Scaling. The notice says you can scale EC2 Auto Scaling groups on CloudWatch OpenTelemetry metrics using the same kind of PromQL queries you use for dashboards and alerting. For teams that are moving to OpenTelemetry, the stated benefit is that capacity can follow the same metrics as the rest of their monitoring, instead of a second set of classic metric alarms kept only for scaling. This report uses the AWS notice and two CloudWatch User Guide pages, one on PromQL alarms and one on alarm actions. It did not create an alarm or run a scaling test.

The most important point is what is and is not supported. The notice says PromQL alarms now support EC2 Auto Scaling simple and step scaling policies, and that target tracking is not currently a supported policy type for PromQL alarms. The alarm actions page has a table that sets this beside other alarm types. For Auto Scaling group actions, a standard metric alarm supports simple, step and target tracking, a PromQL alarm supports simple and step, and the Metrics Insights multiple time series alarm and the log alarm are listed as not supported. For Application Auto Scaling actions, a standard metric alarm supports step and target tracking, and a PromQL alarm supports step only. This is a mismatch with the notice's opening sentence, which says PromQL alarms can trigger "Amazon EC2 and Application Auto Scaling step and simple scaling policies". The guide's table is more specific. This report's cautious advice, not an AWS statement, is that a reader planning to scale ECS services, DynamoDB tables, Aurora replicas or Spot Fleets with a PromQL alarm should plan for step policies only until AWS clarifies.

How the alarm drives the policy needs one rule. For step scaling, the notice says how far the value in your PromQL query is past the threshold decides which step applies. The query must return a single series and compare it to a threshold. The PromQL guide says the same thing in its ordinary steps for creating a PromQL alarm: the query must return a single time series for the alarm to evaluate. The same guide also has a separate section on anomaly detection, in which each breaching time series is tracked as a separate contributor across a fleet, and the alarm actions table lists some actions for PromQL alarms at the contributor level. Neither source says that this contributor mode can drive a scaling policy, so this report does not assume it can. The requirement is about the result: the query must end in one series. If you want one scaling signal from several instances or labels, aggregating them, for example into a fleet-wide figure, is one way to get there, and the right aggregation depends on what the metric means. The notice does not give an example query, so this report does not state one.

A second condition is about repetition. The alarm actions guide says that, except for Auto Scaling actions, alarm actions happen only on state transitions and are not performed again if the condition persists for hours or days. Auto Scaling actions are the exception, which means they can repeat while the condition persists. The guide states this for Auto Scaling actions in general, not for PromQL alarms specifically, and it does not describe cooldown or warm-up behavior. Teams moving scaling logic from classic alarms to PromQL alarms should check the EC2 Auto Scaling policy settings that govern repeated triggers, because the sources do not.

Setup is through familiar tools. The notice says you can add EC2 Auto Scaling and Application Auto Scaling actions in the CloudWatch console when you create or edit an alarm, or with the PutMetricAlarm API, the AWS CLI, the AWS SDKs or AWS CloudFormation. The PromQL guide describes the console path: on the Alarms page choose Create alarm, choose Select metric, then the PromQL tab, enter the query, set the threshold, evaluation period and datapoints to alarm, and configure actions. It also says you can create an alarm from a query run in Query Studio when the query returns a single time series. For simple and step scaling, the alarm actions guide says you create the CloudWatch metric alarm and attach it to the scaling policy. For target tracking, the Auto Scaling service creates and manages the alarms itself, and you should not edit or delete them. The guide states this as how those alarms are managed. It does not give it as the reason why PromQL alarms do not support target tracking, and the notice gives no reason either.

Two operational limits are visible in the guide. Composite alarms cannot trigger Auto Scaling actions. And PromQL alarms do not include a state reason or state reason data in their notifications, unlike single-metric alarms, which show the specific datapoints that caused the state change. When a scaling event looks wrong, there will be less detail in the alarm message to explain why. A team should plan to check the PromQL query and the underlying metrics directly. The sources also list PromQL alarms as not supporting EC2 actions such as stop or reboot, Systems Manager OpsItems and incidents, and CloudWatch investigations, so a PromQL alarm used for scaling cannot also carry those actions.

On availability and cost, the notice says the feature is available in all AWS Regions where CloudWatch PromQL alarms are available, and that standard CloudWatch alarm pricing applies. It names no Regions and no prices. The sources give no measurements of how quickly a PromQL alarm reacts compared with a classic metric alarm, so a team that scales on short bursts should test the delay between a metric change and a capacity change. The sources support a narrow claim: for EC2 Auto Scaling groups, simple and step policies can now be driven by a PromQL alarm that returns one series, and target tracking cannot.