CloudWatch アラームの新機能 「ウォームアップ期間」 を試してみた
はじめに
2026 年 9 月 1 日、AWS の What's New で、Amazon CloudWatch アラームがウォームアップ期間に対応したとの発表がありました。
What's New の記載では、Amazon CloudWatch が提供される全リージョンで利用でき、標準の CloudWatch アラーム料金を超える追加料金はかからないとされています。
ウォームアップ期間とは
ウォームアップ期間は、アラーム作成直後の評価開始を一定時間遅らせ、メトリクス未到着による誤発報を抑える静観期間です。
従来は、メトリクスがまだ届いていない状態でアラームを作成すると、CloudWatch は最初の評価タイミングから treat missing data の設定に基づいて状態を評価していました。これに対し、ウォームアップ期間中はアラームの状態（StateValue）が INSUFFICIENT_DATA になります。評価状態（EvaluationState）は IN_WARM_UP になり、アラームアクションは実行されません。
ウォームアップ期間は PutMetricAlarm と PutLogAlarm の両方で指定できます。必須項目の WarmUpPeriodDurationInMinutes には、1〜2,880 分（2 日）を指定します。任意項目の OnlyStartEvaluatingAfterWarmUpPeriodEnds の既定値は false です。この場合、評価ウィンドウ（Period × Evaluation Periods）が埋まった時点でウォームアップが早期終了します。true にすると、データが早く届いてもウォームアップ期間が満了するまで評価を開始しません。なお、早期終了の判定に Datapoints to Alarm は影響しないとドキュメントに記載されています。
なお、ウォームアップが適用されるのは、アラーム作成時の 1 回だけです。
Warm-up applies only once at alarm creation and does not restart.
検証内容
検証は AWS CLI 2.36.36 で実施しました。このバージョンの aws cloudwatch put-metric-alarm は --warm-up-configuration をサポートしています。
アラーム構成
名前空間 WarmUpDemo/233910 のカスタムメトリクスを対象に、リージョン ap-northeast-1 で 4 つのアラームを同時に作成しました。閾値と評価期間は 4 アラームで共通です。
--statistic Average --period 60 --evaluation-periods 1 --datapoints-to-alarm 1
--threshold 80 --comparison-operator GreaterThanThreshold
--treat-missing-data breaching
欠損の扱いに breaching を選んだのは、既定の missing では欠損時に INSUFFICIENT_DATA のまま留まり、ウォームアップの有無で挙動の差が出ないためです。
ウォームアップの指定（--warm-up-configuration）は 3 通り（指定なし・5 分・5 分＋フル待機）にし、対象メトリクスとの組み合わせで 4 つのアラームを作成しました。
A: warmup-demo-A-nowarmup metric=m1 指定なし
B: warmup-demo-B-warm5 metric=m1 {"WarmUpPeriodDurationInMinutes":5}
C: warmup-demo-C-warm5 metric=m2 {"WarmUpPeriodDurationInMinutes":5}
D: warmup-demo-D-warm5-full metric=m2 {"WarmUpPeriodDurationInMinutes":5,"OnlyStartEvaluatingAfterWarmUpPeriodEnds":true}
メトリクスは、アラーム作成時刻を t=0 として t+120 秒から 20 秒間隔で送信し、t+780 秒で停止しました。t+120 秒までは何も送っていません。m1 は t+120 秒以降、閾値を下回る値 10 を送り続けました。m2 は t+120〜240 秒の間、閾値を超える値 95 を送り、t+240 秒以降は送信する値を 10 に戻しました。
4 アラームの設定は describe-alarms で確認できます。
aws cloudwatch describe-alarms --alarm-name-prefix warmup-demo --query 'MetricAlarms[].{N:AlarmName,M:MetricName,W:WarmUpConfiguration}' --output json
[
{
"N": "warmup-demo-A-nowarmup",
"M": "m1",
"W": null
},
{
"N": "warmup-demo-B-warm5",
"M": "m1",
"W": {
"WarmUpPeriodDurationInMinutes": 5,
"OnlyStartEvaluatingAfterWarmUpPeriodEnds": false
}
},
{
"N": "warmup-demo-C-warm5",
"M": "m2",
"W": {
"WarmUpPeriodDurationInMinutes": 5,
"OnlyStartEvaluatingAfterWarmUpPeriodEnds": false
}
},
{
"N": "warmup-demo-D-warm5-full",
"M": "m2",
"W": {
"WarmUpPeriodDurationInMinutes": 5,
"OnlyStartEvaluatingAfterWarmUpPeriodEnds": true
}
}
]
出力の N、M、W はクエリで付けた表示用の短縮名で、API が返すフィールド名は AlarmName、MetricName、WarmUpConfiguration です。早期終了の指定を省略した B と C でも、false が明示されていました。ウォームアップを指定しなかった A は、WarmUpConfiguration 自体が null でした。
作成直後の状態
20 秒間隔のポーリングで状態を追いました。
aws cloudwatch describe-alarms --alarm-name-prefix warmup-demo --query 'MetricAlarms[].[AlarmName,StateValue,EvaluationState]' --output text
経過秒はポーリング時に付与した列です。以降の列はアラーム名・StateValue・EvaluationState の順です。以下は t+3〜43 秒の結果です。
t+3s warmup-demo-A-nowarmup INSUFFICIENT_DATA None
t+3s warmup-demo-B-warm5 INSUFFICIENT_DATA IN_WARM_UP
t+3s warmup-demo-C-warm5 INSUFFICIENT_DATA IN_WARM_UP
t+3s warmup-demo-D-warm5-full INSUFFICIENT_DATA IN_WARM_UP
t+23s warmup-demo-A-nowarmup INSUFFICIENT_DATA None
t+23s warmup-demo-B-warm5 INSUFFICIENT_DATA IN_WARM_UP
t+23s warmup-demo-C-warm5 INSUFFICIENT_DATA IN_WARM_UP
t+23s warmup-demo-D-warm5-full INSUFFICIENT_DATA IN_WARM_UP
t+43s warmup-demo-A-nowarmup ALARM None
t+43s warmup-demo-B-warm5 INSUFFICIENT_DATA IN_WARM_UP
t+43s warmup-demo-C-warm5 INSUFFICIENT_DATA IN_WARM_UP
t+43s warmup-demo-D-warm5-full INSUFFICIENT_DATA IN_WARM_UP
メトリクスが欠損している状況と breaching の設定は、4 つのアラームで共通です。ウォームアップを指定していない A は、t+23 秒のポーリングではまだ INSUFFICIENT_DATA でしたが、次の t+43 秒のポーリングでは ALARM でした。同じ時点で B / C / D はウォームアップ中のままでした。ウォームアップを指定していない A の EvaluationState は null で、テキスト出力では None と表示されます。
早期終了とフル待機
同じ 20 秒間隔で追うと、既定どおり早期終了する B と C は、t+190 秒のポーリングで既に評価が始まっていました。フル待機の D だけがウォームアップ中のままでした。
t+169s warmup-demo-B-warm5 INSUFFICIENT_DATA IN_WARM_UP
t+169s warmup-demo-C-warm5 INSUFFICIENT_DATA IN_WARM_UP
t+169s warmup-demo-D-warm5-full INSUFFICIENT_DATA IN_WARM_UP
t+190s warmup-demo-A-nowarmup ALARM None
t+190s warmup-demo-B-warm5 OK None
t+190s warmup-demo-C-warm5 ALARM None
t+190s warmup-demo-D-warm5-full INSUFFICIENT_DATA IN_WARM_UP
t+232s warmup-demo-A-nowarmup OK None
t+232s warmup-demo-B-warm5 OK None
t+232s warmup-demo-C-warm5 ALARM None
t+232s warmup-demo-D-warm5-full INSUFFICIENT_DATA IN_WARM_UP
t+317s warmup-demo-C-warm5 OK None
t+317s warmup-demo-D-warm5-full INSUFFICIENT_DATA IN_WARM_UP
t+338s warmup-demo-A-nowarmup OK None
t+338s warmup-demo-B-warm5 OK None
t+338s warmup-demo-C-warm5 OK None
t+338s warmup-demo-D-warm5-full OK None
ウォームアップなしの A は、t+43 秒以降のポーリングで ALARM が続き、データが届いた後の t+232 秒のポーリングで OK に戻っていました。既定どおり早期終了する B は、データが届いた後、5 分の満了を待たずに t+190 秒のポーリングで ALARM を経由せず OK になっていました。C の早期終了設定も同じですが、対象メトリクスはスパイクを含む m2 です。評価開始が早かったため、ウォームアップ期間中に送った 95 を検知して ALARM になりました。
フル待機を指定した D は、t+317 秒の時点ではまだウォームアップ中で、次の t+338 秒で OK になっていました。5 分（300 秒）の満了後に評価が始まっていました。その時点の値は 10 に戻っていたため、INSUFFICIENT_DATA から OK へ直接遷移し、スパイクは検知しませんでした。
状態遷移の履歴からも、この違いを確認できます。
4 アラームの状態遷移履歴
aws cloudwatch describe-alarm-history --alarm-name <アラーム名> --history-item-type StateUpdate --query 'reverse(AlarmHistoryItems[].{T:Timestamp,S:HistorySummary})' --output json
T / S も表示用の短縮名で、API が返すフィールド名は Timestamp / HistorySummary です。
--- warmup-demo-A-nowarmup ---
[
{
"T": "2026-09-01T23:39:52.933000+09:00",
"S": "Alarm updated from INSUFFICIENT_DATA to ALARM"
},
{
"T": "2026-09-01T23:42:52.928000+09:00",
"S": "Alarm updated from ALARM to OK"
}
]
--- warmup-demo-B-warm5 ---
[
{
"T": "2026-09-01T23:42:16.303000+09:00",
"S": "Alarm updated from INSUFFICIENT_DATA to OK. State now evaluated with the full set of metrics matching the query"
}
]
--- warmup-demo-C-warm5 ---
[
{
"T": "2026-09-01T23:42:15.880000+09:00",
"S": "Alarm updated from INSUFFICIENT_DATA to ALARM. State now evaluated with the full set of metrics matching the query"
},
{
"T": "2026-09-01T23:44:15.879000+09:00",
"S": "Alarm updated from ALARM to OK"
}
]
--- warmup-demo-D-warm5-full ---
[
{
"T": "2026-09-01T23:44:28.840000+09:00",
"S": "Alarm updated from INSUFFICIENT_DATA to OK. State now evaluated with the full set of metrics matching the query"
}
]
D の履歴には ALARM が 1 件もありません。前節のとおり、評価開始時点の値が 10 だったためです。B も ALARM の履歴は 1 件もありません。B は m1 を対象としており、評価開始後に閾値を超えるデータがなかったためです。B と D のどちらも、ウォームアップ期間中は StateUpdate の履歴エントリが追加されず、最初のエントリは評価が始まった時点のものでした。ウォームアップ中はずっと INSUFFICIENT_DATA のままなので、履歴に残る状態変化自体が起きません。この場合、アラーム履歴に状態遷移が記録されていなくても異常ではありません。
送信停止後の挙動
t+780 秒でメトリクスの送信を停止し、その後の状態を先ほどの describe-alarms で確認しました。+2min / +3min は、送信停止からの経過時間です。
--- +2min ---
warmup-demo-A-nowarmup OK None
warmup-demo-B-warm5 OK None
warmup-demo-C-warm5 OK None
warmup-demo-D-warm5-full OK None
--- +3min ---
warmup-demo-A-nowarmup ALARM None
warmup-demo-B-warm5 ALARM None
warmup-demo-C-warm5 ALARM None
warmup-demo-D-warm5-full ALARM None
送信停止から約 3 分後のポーリングで、4 アラームすべてが ALARM になっていました。EvaluationState は 4 アラームとも null のままで、この時点まで IN_WARM_UP へ戻ることはありませんでした。運用中に発生した欠損の扱いは、従来どおり treat missing data の設定で決まります。
まとめ
CloudWatch アラームでは、作成時に静観期間を指定できるようになりました。これにより、treat missing data の設定を変えずに、作成直後のメトリクス未到着による誤発報を抑えられます。OnlyStartEvaluatingAfterWarmUpPeriodEnds の指定で、データが早く届いた時点で評価を始めるか、期間の満了まで待つかを選べます。
たとえば、IaC で EC2 を起動した後にアプリケーションをデプロイする構成では、アプリケーションが起動してカスタムメトリクスを送信できるようになるまで、メトリクスが欠損します。treat missing data を breaching にしているアラームでも、作成時にウォームアップ期間を指定すれば、この初期化中だけは ALARM への遷移を抑えられます。
これは、アプリケーションの起動待ちに合わせて CloudWatch アラームの評価開始に猶予を持たせる用途に向いています。ただし、ELB のターゲットヘルスチェックや Auto Scaling の初期化グレースピリオドを置き換える機能ではありません。ウォームアップが適用されるのは作成時の 1 回だけなので、運用中の欠損には、引き続き treat missing data の設定で備える必要があります。
参考リンク
