CloudWatch PromQLアラームがAuto Scalingをトリガー可能に：EC2グループはシンプルとステップに対応しターゲット追跡は非対応、ガイドの表ではApplication Auto Scalingはステップのみで通知冒頭の「ステップとシンプル」と食い違い、クエリは単一の系列を返す必要がある

2026年11月10日、AWSは、Prometheusクエリ言語（PromQL）で書かれたAmazon CloudWatchアラームが、Amazon EC2 Auto ScalingとApplication Auto Scalingのスケーリングポリシーをトリガーできるようになったと発表しました。通知によると、ダッシュボードやアラートと同じ種類のPromQLクエリを使って、CloudWatchのOpenTelemetryメトリクスに基づきEC2 Auto Scalingグループをスケールできます。OpenTelemetryへ移行中のチームにとって、示されている利点は、スケーリング専用に従来型のメトリクスアラームを別に持つ代わりに、他の監視と同じメトリクスに沿って容量を動かせることです。本稿はAWSの通知と、PromQLアラームとアラームアクションに関する2つのCloudWatchユーザーガイドのページに基づきます。アラームの作成やスケーリングのテストは行っていません。

最も重要なのは、何がサポートされ、何がされていないかです。通知は、PromQLアラームがEC2 Auto Scalingのシンプルスケーリングとステップスケーリングのポリシーをサポートし、ターゲット追跡は現在PromQLアラームのポリシータイプとしてサポートされていないと述べています。アラームアクションのページには、他のアラーム種別と並べた表があります。Auto Scalingグループのアクションでは、標準のメトリクスアラームはシンプル、ステップ、ターゲット追跡をサポートし、PromQLアラームはシンプルとステップをサポートし、Metrics Insightsの複数時系列アラームとログアラームはサポート対象外と記されています。Application Auto Scalingのアクションでは、標準メトリクスアラームはステップとターゲット追跡、PromQLアラームはステップのみです。これは、PromQLアラームが「Amazon EC2とApplication Auto Scalingのステップおよびシンプルスケーリングポリシー」をトリガーできるとする通知の冒頭の文と食い違います。ガイドの表のほうが具体的です。AWSの説明ではなく本稿の慎重な判断として、PromQLアラームでECSサービス、DynamoDBテーブル、Auroraレプリカ、Spot Fleetをスケールしようとする読者には、AWSが明確にするまでステップポリシーのみを前提に計画することを勧めます。

アラームがポリシーをどう動かすかには、ひとつ規則があります。ステップスケーリングでは、PromQLクエリの値がしきい値をどれだけ超えたかで、どのステップを適用するかが決まると通知は述べています。クエリは単一の系列を返し、それをしきい値と比較する必要があります。PromQLのガイドも、PromQLアラームを作成する通常の手順で、アラームが評価できるようクエリは単一の時系列を返す必要があると書いています。同じガイドには異常検知についての別の節があり、そこではフリート全体で基準を超えた各時系列が個別のコントリビューターとして追跡されると記されており、アラームアクションの表もPromQLアラームの一部のアクションをコントリビューター単位として挙げています。どちらの情報源も、このコントリビューター方式でスケーリングポリシーを動かせるとは述べていないため、本稿はそれを前提にしません。この要件は結果についてのもので、クエリは最終的に1つの系列にならなければなりません。複数のインスタンスやラベルの値から1つのスケーリング信号を作りたい場合、たとえばフリート全体の数値に集約するのは1つの方法で、どの集約が適切かはメトリクスの意味によります。通知はクエリの例を示していないため、本稿も示しません。

2つ目の条件は繰り返しに関するものです。アラームアクションのガイドは、Auto Scalingアクションを除き、アラームアクションは状態遷移のときにだけ実行され、条件が何時間も何日も続いても再実行されないと述べています。Auto Scalingアクションは例外で、条件が続く間は繰り返される可能性があるということです。ガイドはこれをAuto Scalingアクション全般について述べており、PromQLアラームに限った記述ではなく、クールダウンやウォームアップの動作も説明していません。スケーリングのロジックを従来型アラームからPromQLアラームへ移すチームは、情報源に書かれていないため、繰り返しのトリガーを制御するEC2 Auto Scalingポリシーの設定を確認すべきです。

設定は慣れたツールで行います。通知によると、アラームの作成時や編集時にCloudWatchコンソールでEC2 Auto ScalingとApplication Auto Scalingのアクションを追加でき、PutMetricAlarm API、AWS CLI、AWS SDK、AWS CloudFormationでも追加できます。PromQLガイドはコンソールでの手順を説明しています。アラームのページでアラームの作成を選び、メトリクスの選択、PromQLタブの順に進み、クエリを入力し、しきい値、評価期間、アラームにするデータポイントを設定し、アクションを構成します。また、クエリが単一の時系列を返す場合は、Query Studioで実行したクエリからアラームを作れるとも述べています。シンプルとステップのスケーリングでは、CloudWatchメトリクスアラームを作ってスケーリングポリシーにアタッチするとアラームアクションのガイドは述べています。ターゲット追跡では、Auto Scalingサービスがアラームを作成して管理し、編集や削除はしてはならないとされています。ガイドはこれをアラームの管理方法として述べているだけで、PromQLアラームがターゲット追跡に対応しない理由としては示しておらず、通知も理由を挙げていません。

ガイドには2つの運用上の制限が見えます。複合アラームはAuto Scalingアクションをトリガーできません。また、状態変化の原因となった具体的なデータポイントを示す単一メトリクスアラームと異なり、PromQLアラームの通知には状態の理由も状態理由データも含まれません。スケーリングのイベントがおかしく見えるとき、アラームのメッセージには理由を説明する詳細が少なくなります。チームはPromQLクエリと基になるメトリクスを直接確認する計画を立てるべきです。情報源はまた、PromQLアラームが停止や再起動などのEC2アクション、Systems ManagerのOpsItemやインシデント、CloudWatch調査をサポートしないと記しているため、スケーリングに使うPromQLアラームにはこれらのアクションを同時に持たせられません。

提供状況とコストについて、通知は、この機能はCloudWatchのPromQLアラームが利用できるすべてのAWSリージョンで利用でき、標準のCloudWatchアラーム料金が適用されると述べています。リージョン名も価格も示されていません。情報源には、PromQLアラームが従来型のメトリクスアラームと比べてどれほど速く反応するかの測定がないため、短時間のバーストでスケールするチームは、メトリクスの変化から容量の変化までの遅延を試すべきです。情報源が支持するのは狭い主張です。EC2 Auto Scalingグループでは、シンプルとステップのポリシーを、単一の系列を返すPromQLアラームで動かせるようになり、ターゲット追跡はできません。