はじめに
2026年2月10日、Amazon CloudWatch に Alarm Mute Rules という待望の新機能がリリースされました。
こんな経験はありませんか？
- 毎週日曜深夜のメンテナンス中に、分かりきったアラートが大量にSlackへ飛んでくる
- 夜間バッチ処理の時間帯にCPUアラームが毎日鳴って、チームがアラートを無視する文化に…
Alarm Mute Rules は、まさにこうした問題を解決するための機能です。
Alarm Mute Rules とは
アラームの「通知アクション」だけを指定した時間帯に自動でミュートする機能 です。
ここで重要なのは、アラームの評価自体は止まらない ということです。
メトリクスの監視やアラーム状態の遷移は通常どおり行われ、SNS通知やAuto Scalingアクションなどの アクション実行だけがミュート されます。
従来の方法
-
disable-alarm-actionsで手動無効化 → 戻し忘れリスクが高い - Lambda + EventBridge で自動化スクリプト → 自前で開発・運用が必要
- SNSフィルタリングポリシーで制御 → 設定が複雑で、アラームごとの柔軟な制御が難しい
アーキテクチャ概要
Alarm Mute Rules の動作の流れを図で見てみましょう。
ポイント: ミュート終了後の自動アクション実行
ミュートウィンドウが終了した時点で、対象のアラームがまだ ALARM 状態（またはミュート中に遷移した状態）のままであれば、ミュートされていたアクションが自動的にトリガーされます。これにより、メンテナンス中に発生した本当の問題を見逃すことがありません。
Mute Rule の構成要素
Alarm Mute Rules は大きく Targets（対象アラーム） と Rule（スケジュール定義） と の2つで構成されます。
Expression（スケジュール式）
2種類の指定方法があります。
① cron 式（定期的なミュート）
標準的な cron 構文で繰り返しスケジュールを定義します。
② at 式（1回限りのミュート）
特定の日時に1回だけミュートする場合に使います。
Duration（ミュート期間）
ISO-8601 形式で指定します。最小 1分（PT1M）、最大 15日（P15D）です。
Mute Rule のステータス
実際に動かしてみた
ここからは、AWS CLI を使って Alarm Mute Rules を実際に設定してみます。
前提: テスト用のアラームを作成
まず、動作確認用の CloudWatch アラームを作成します。
aws cloudwatch put-metric-alarm \
--alarm-name "TestCPUAlarm" \
--alarm-description "テスト用 CPU アラーム" \
--metric-name CPUUtilization \
--namespace AWS/EC2 \
--statistic Average \
--period 300 \
--threshold 80 \
--comparison-operator GreaterThanThreshold \
--evaluation-periods 1 \
--alarm-actions "arn:aws:sns:ap-northeast-1:123456789012:my-alert-topic"
シナリオ: 毎週日曜深夜のメンテナンスウィンドウ
毎週日曜 AM2:00〜AM6:00（JST）の定期メンテナンス中にアラーム通知をミュートします。
aws cloudwatch put-alarm-mute-rule \
--name "WeeklySundayMaintenance" \
--description "毎週日曜深夜の定期メンテナンス中にアラームをミュート" \
--rule '{
"Schedule": {
"Expression": "cron(0 0 * * SUN)",
"Duration": "PT2H",
"Timezone": "Asia/Tokyo"
}
}' \
--mute-targets '{
"AlarmNames": ["TestCPUAlarm"]
}'
実行すると、ルールが作成されステータスは SCHEDULED になります。次の日曜 AM0:00（JST）になると自動的に ACTIVE に遷移し、指定したアラームのアクションがミュートされます。
動作確認: アラーム状態を手動で変更してテスト
set-alarm-state コマンドを使うと、実際にメトリクスが閾値を超えなくてもアラーム状態を手動で変更してテストできます。
aws cloudwatch set-alarm-state \
--alarm-name "TestCPUAlarm" \
--state-value ALARM \
--state-reason "Mute Rule の動作テスト"
ミュートルールが ACTIVE であれば、アラームは ALARM 状態に遷移しますが、SNS通知は発火しません。CloudWatch コンソールのアラーム履歴で、状態遷移が記録されていることを確認できます。
注意点・制限事項
- 1ルールあたり最大100アラーム
- OK / ALARM / INSUFFICIENT_DATA すべての状態の全アクション・全状態がミュート対象
まとめ
「メンテナンス中のアラート通知を止めるために Lambda を書いている」という方は、ぜひ Alarm Mute Rules への移行を検討してみると良いかなと思いました。運用の負荷がぐっと軽くなるはずです。