CloudWatch PromQL agora aciona Auto Scaling de EC2 e Application Auto Scaling

Desde 10 de novembro de 2026, alarmes do CloudWatch baseados em PromQL podem disparar políticas simple e step scaling no EC2 Auto Scaling e no Application Auto Scaling. Target tracking ainda fica de fora.

A AWS anunciou em 10 de novembro de 2026 que alarmes do Amazon CloudWatch escritos em PromQL (Prometheus Query Language) agora podem acionar políticas de escalonamento do Amazon EC2 Auto Scaling e do Application Auto Scaling. Até então, um alarme PromQL servia para dashboard e para alertar, mas não entrava na cadeia de scaling: quem queria escalar grupos de Auto Scaling precisava manter um alarme separado, em métrica CloudWatch clássica, só para essa finalidade.

A mudança fecha essa lacuna. Agora dá para usar a mesma consulta PromQL que já alimenta o painel de observabilidade como gatilho de scaling, sem duplicar métrica nem alarme.

Por que isso importa pra quem já migrou para OpenTelemetry

Times que adotaram OpenTelemetry para instrumentar aplicação e enviam essas métricas ao CloudWatch já podem consultar esses dados com PromQL, usando a mesma linguagem de consulta do Prometheus que alimenta dashboards e alertas. O problema é que essa camada ficava isolada do Auto Scaling: scaling continuava dependendo de métrica clássica do CloudWatch (CPUUtilization, métrica customizada via PutMetricData, etc.).

Com o anúncio, o pipeline de métricas de OpenTelemetry passa a alimentar scaling diretamente. Isso elimina um padrão comum em produção: manter duas fontes de verdade para o mesmo sinal, uma para alertar e dashboard, outra (geralmente mais simples) só para escalar. Menos métrica redundante significa menos custo de ingestão e menos risco de as duas fontes divergirem no momento do incidente.

Simple e step scaling, mas não target tracking

O anúncio é explícito sobre o escopo: alarmes PromQL agora suportam políticas simple scaling e step scaling no EC2 Auto Scaling. Target tracking continua fora da lista de políticas suportadas para alarmes PromQL.

Essa limitação muda o desenho de quem planeja migrar capacidade de EC2 para métricas de OpenTelemetry:

• Se a estratégia de scaling hoje é target tracking (manter CPU ou uma métrica de aplicação perto de um valor-alvo), ela continua precisando de alarme clássico do CloudWatch; não há como reproduzir esse comportamento com PromQL ainda.
• Step e simple scaling, que reagem a limiares fixos, já podem sair inteiramente do pipeline de OpenTelemetry.
• Um ambiente real tende a ficar híbrido por um tempo: scaling reativo a limiar migra para PromQL, scaling por valor-alvo permanece em métrica clássica até a AWS estender o suporte.

Para step scaling, o comportamento segue a lógica conhecida: o quanto o valor da consulta PromQL ultrapassa o limiar decide qual degrau (step) da política é aplicado. Nada muda na semântica do step scaling em si, só a origem do dado que alimenta o alarme.

A consulta precisa devolver uma série única

A AWS impõe uma restrição técnica que afeta diretamente como se escreve a query: o alarme PromQL usado para scaling precisa devolver uma única série temporal, comparada contra um limiar. Isso é diferente de um painel, onde é normal uma consulta devolver várias séries agrupadas por by (label) para plotar uma linha por host ou por AZ.

Na prática, quem for reaproveitar uma consulta de dashboard para virar gatilho de scaling provavelmente vai precisar agregar o resultado. Um exemplo de consulta pensada para dashboard, que mostra uso de CPU por instância:

avg(rate(container_cpu_usage_seconds_total[5m])) by (instance_id)

Para virar gatilho de scaling válido, ela precisa colapsar em uma série só, agregando todas as instâncias do grupo:

avg(rate(container_cpu_usage_seconds_total[5m]))

Essa exigência é razoável (um alarme de scaling não tem como decidir o que fazer com N séries diferentes), mas é um ponto de atenção real: times que copiarem a query do dashboard sem revisar vão receber erro de validação ou, pior, um alarme que nunca atinge ALARM porque a lógica de agregação não bate com a intenção.

Como configurar

A ação de scaling pode ser adicionada da mesma forma que qualquer ação de alarme do CloudWatch: pelo console, ao criar ou editar o alarme, ou de forma programática via API PutMetricAlarm, AWS CLI, AWS SDKs ou AWS CloudFormation.

Quem já tem IaC descrevendo alarmes PromQL para dashboard e alerta pode, em tese, reaproveitar boa parte da definição e só acrescentar a ação de scaling e, se necessário, ajustar a query para devolver série única, conforme a seção anterior.

Preço e disponibilidade

O recurso está disponível em todas as regiões da AWS onde os alarmes PromQL do CloudWatch já existem; a página de lançamento não lista regiões região a região. Quem opera carga em São Paulo (sa-east-1) precisa confirmar na documentação da região se o recurso de alarmes PromQL já está habilitado ali antes de desenhar o scaling em cima dele.

Não há cobrança adicional: a AWS confirma que se aplica o preço padrão de alarme do CloudWatch, o mesmo modelo já usado para qualquer alarme, PromQL ou clássico.

O que fica em aberto

A ausência de target tracking é a lacuna mais visível para quem opera em produção. Até a AWS estender esse suporte, times que dependem de políticas de valor-alvo não têm como abandonar de vez o alarme clássico do CloudWatch, mesmo depois de migrar toda a instrumentação para OpenTelemetry.

Vale acompanhar a documentação Using PromQL in alarms e Alarm actions no Amazon CloudWatch User Guide para checar se a AWS amplia o suporte de políticas ao longo dos próximos lançamentos.

Fonte 1: AWS What's New (https://aws.amazon.com/about-aws/whats-new/2026/11/amazon-cloudwatch-alarms-autoscaling-group-actions)

CloudWatch PromQL alarms now support EC2 and Application Auto Scaling - AWS

Skip to main content

CloudWatch PromQL alarms now support EC2 and Application Auto Scaling

Posted on: Nov 10, 2026

Amazon CloudWatch alarms that use Prometheus Query Language (PromQL) can now trigger Amazon EC2 and Application Auto Scaling step and simple scaling policies. You can scale your EC2 Auto Scaling groups on CloudWatch OpenTelemetry metrics using the same kind of PromQL queries you use for dashboards and alerting.

In this release, PromQL alarms also support EC2 Auto Scaling simple and step scaling policies. Target tracking is not currently a supported policy type for PromQL alarms. Teams moving to OpenTelemetry can scale capacity on the same metrics as the rest of their monitoring, instead of keeping separate classic metric alarms for scaling. For step scaling, how far the value is past the threshold in your PromQL query decides which step applies. The query must return a single series and compare it to a threshold.

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, AWS CLI, AWS SDKs, or AWS CloudFormation. You can also use the PutMetricAlarm API, AWS CLI, AWS SDKs, or AWS CloudFormation.

This feature is available in all AWS Regions where CloudWatch PromQL alarms are available. Standard CloudWatch alarm pricing applies. To get started, see Using PromQL in alarms and Alarm actions in the Amazon CloudWatch User Guide.

Fonte: AWS What's New