CloudWatch アラームを時間帯で抑制する手順

夜間や早朝のバッチ処理が走るたびに「CPU 使用率が閾値を超えました」という CloudWatch アラームが飛んでくる。RDS / Aurora を運用していると、かなりの頻度で遭遇する悩みです。負荷が上がること自体は設計どおりで、対応する必要はない。けれど通知は鳴り続けるので、当番のスマートフォンは毎晩震えるし、そのうち誰もアラームを見なくなる。いわゆるアラート疲れの典型パターンです😇

この記事では「CloudWatch アラームを特定の時間帯だけ止めたい」という要件に対して、CloudWatch 側に何ができて何ができないのかをはっきりさせたうえで、実際に使える手順（CLI と EventBridge Scheduler）、運用者が誤解しやすい挙動、そして抑制以外の選択肢との使い分けまで整理します。

🎯 結論：アラームアクションを時間帯で無効化して通知だけを止める

先に結論を書きます。CloudWatch メトリクスアラームには、「この時間帯は評価しない」という設定項目はありません。メンテナンスウィンドウのような概念がアラーム側に用意されていないため、「夜 1 時から 3 時までアラームを止める」というチェックボックスを探しても見つかりません。

代わりに使えるのが、アラームアクションの無効化です。DisableAlarmActions API を呼ぶと、そのアラームは状態が遷移してもアクション（SNS 通知、Auto Scaling アクション、Systems Manager アクションなど）を実行しなくなります。EnableAlarmActions で元に戻ります。この 2 つをバッチ開始前・終了後に呼び出すようスケジュール実行すれば、実質的に「時間帯による通知抑制」が実現できます。

⚠️ 止まるのはアクションだけで、メトリクスの評価とアラーム状態の遷移は裏で動き続けます。ここを取り違えると運用中に混乱するので、後半の「よくある誤解」で改めて詳しく触れます。

今すぐ試せる disable-alarm-actions / enable-alarm-actions

手元で試すなら CLI が最短です。まず対象アラームの現在の設定を確認します。

aws cloudwatch describe-alarms \
  --alarm-names <アラーム名> \
  --query "MetricAlarms[].{Name:AlarmName,State:StateValue,ActionsEnabled:ActionsEnabled,Period:Period,EvalPeriods:EvaluationPeriods,Threshold:Threshold}"

ActionsEnabled が true なら、アクションが有効な状態です。ここでアクションを無効化します。

aws cloudwatch disable-alarm-actions --alarm-names <アラーム名>

複数指定もできます。

aws cloudwatch disable-alarm-actions \
  --alarm-names <アラーム名1> <アラーム名2> <アラーム名3>

元に戻すときは次のコマンドです。

aws cloudwatch enable-alarm-actions --alarm-names <アラーム名>

実行後にもう一度 describe-alarms を叩いて、ActionsEnabled が false / true に切り替わっていることを必ず確認してください。この値が「通知が飛ぶか飛ばないか」を決めているフラグです。

なお、これらの API はアラームの閾値や評価設定には一切触りません。アラームを削除したり、閾値を上げ下げしたりするわけではないので、元に戻すときに設定を復元する必要がない点は運用上ありがたいところです✨

この方法が向くケースと、向かないケース

向いているのは、次のような条件が揃っているケースです。

• 負荷上昇の時間帯が事前に決まっている（cron で起動するバッチなど）
• 負荷上昇が想定内で、上がること自体は問題ではない
• そのアラームを一時的に無視しても運用上の判断を誤らない

逆に、次のようなケースでは別の手を考えたほうがいいでしょう。

• バッチの終了時刻が日によって大きくブレる。抑制解除の時刻を固定できないため、解除が早すぎれば通知が鳴り、遅すぎれば無監視の時間が延びます
• 同じアラームがバッチ時間帯以外でも鳴っている。この場合そもそも原因がバッチではないので、抑制は問題を覆い隠すだけです
• アラームアクションに自動復旧処理（Auto Scaling やイベント連携）を紐づけている。アクションを無効にすると通知だけでなくその自動処理も止まります。通知用アラームと自動処理用アラームは分けておくのが安全です

抑制は不要な通知を減らすための運用テクニックであって、根本対策ではありません。閾値設計そのものが実態に合っていない場合は、後述する期間・評価期間数の見直しのほうが筋の良い解決になります。

🔍 なぜバッチ時間帯にCPU使用率アラームが鳴るのか、どう切り分けるか

抑制を入れる前に、「本当にバッチ起因なのか」を確かめておく必要があります。ここを飛ばして抑制だけ入れてしまうと、実は別の問題だったときに検知が遅れます。

メトリクスアラームが ALARM に遷移する条件（期間×評価期間数×閾値）

CloudWatch のメトリクスアラームは、次の 3 つのパラメータの組み合わせで判定します。期間（Period）はメトリクスを集計する 1 データポイントの長さ、評価期間数（EvaluationPeriods）は判定に使うデータポイントの個数、閾値（Threshold）と比較演算子はどの値をどう超えたら異常とみなすかを決めます。

さらに「M / N」方式（EvaluationPeriods のうち DatapointsToAlarm 個が閾値超過なら ALARM）を使うと、スパイクの拾い方を細かく制御できます。

RDS / Aurora の CPUUtilization は、インスタンス全体の CPU 使用率を集計したものです。バッチ処理のように一定時間まとまって負荷がかかるタイプのワークロードは、評価期間数を何個に設定していても、その全部が閾値超過で埋まってしまいます。単発のスパイクなら評価期間数を増やせばかわせますが、バッチは「連続して高い」ので、期間や評価期間数をいじるだけでは逃げ切れないことが多い。これが「抑制」という発想が出てくる理由です。

欠測データの扱い（TreatMissingData）も併せて確認しておきましょう。設定によっては、データが来ないときに ALARM 側に倒れることがあります。

バッチ処理でデータベースのCPUが跳ね上がる内部的な理由

「バッチだから CPU が上がる」で片づけず、何が CPU を使っているのかを一段掘り下げておくと、抑制すべきか対処すべきかの判断がしやすくなります。PostgreSQL 系（Aurora PostgreSQL / RDS for PostgreSQL）を前提にすると、バッチ処理中に CPU を押し上げる要因は主に次のようなものです。

• 大量の行を読むクエリのタプル処理。シーケンシャルスキャンや大きなソート・ハッシュ結合は、I/O 待ちよりも CPU 上でのタプル比較・整列にコストがかかります。work_mem を超えるソートが一時ファイルに落ちると I/O も増え、両方が悪化します
• WAL の生成とバッファ管理。一括 INSERT / UPDATE / DELETE は WAL レコードを大量に生成します。WAL の書き出し、共有バッファからの追い出し、チェックポイント処理が重なると、バックグラウンドプロセスの CPU 消費も無視できなくなります
• MVCC による不要タプルの蓄積と autovacuum。大量 UPDATE / DELETE は不要タプル（dead tuple）を大量に作ります。閾値を超えると autovacuum ワーカーが起動し、テーブルスキャンとインデックスの整理を行うため、バッチ本体とは別に CPU を使います。バッチ直後に CPU が下がらない場合、autovacuum が走り続けている可能性があります
• 実行計画の変化。投入データ量が増えて統計情報と実態がずれると、オプティマイザがインデックススキャンからシーケンシャルスキャンへ切り替わることがあります。同じバッチなのに日によって CPU の山の形が違うときは、実行計画の揺れを疑う価値があります

Aurora の場合、ストレージ層が分離されていてチェックポイントの考え方がコミュニティ版と異なるなど、エンジンによる差もあります。とはいえ「タプル処理と WAL 生成が CPU を食う」という基本構図は共通です。

このあたりの内部挙動と切り分けの全体像は、RDS・Aurora 運用・トラブル解決ガイド｜仕組み・障害切り分け・性能監視の全体像に整理してあります。

バッチ起因か別の問題かを確かめる3つの確認

現場での切り分けは、次の順番で進めると無駄がありません。

1. アラームの設定内容（期間・評価期間数・閾値）を確認する

前述の describe-alarms で、いま何をもって異常としているのかを把握します。そもそも閾値が実態に対して低すぎる、あるいは期間が短すぎて一瞬のスパイクを拾っている、というケースは珍しくありません。

2. バッチのスケジュールとアラーム発生時刻が一致しているかを確認する

アラーム履歴を時系列で並べて、バッチの起動時刻・終了時刻と重なっているかを見ます。

aws cloudwatch describe-alarm-history \
  --alarm-name <アラーム名> \
  --history-item-type StateUpdate \
  --start-date <開始日時> \
  --end-date <終了日時> \
  --query "AlarmHistoryItems[].{Time:Timestamp,Summary:HistorySummary}"

OK → ALARM の遷移時刻がバッチ開始の直後に、ALARM → OK がバッチ終了の直後に来ていれば、相関は濃厚です。

3. バッチ時間帯以外でも同じアラームが発生していないかを確認する

💡 これが一番大事な確認です。バッチ時間帯以外でも同じアラームが出ているなら、それはバッチとは別の問題です。日中の通常業務でも CPU が張り付いているなら、インスタンスサイズが足りていないか、非効率なクエリが定着しているか、あるいはコネクション数の増加や統計情報の劣化といった別の要因が絡んでいます。この場合に時間帯抑制だけを入れると、本来対処すべき問題を見えなくしてしまいます。

リードレプリカを併用している構成では、バッチ中にライターの CPU が上がってレプリカへの反映が遅れるケースもあります。レプリカ側の遅延監視についてはAuroraレプリカラグ監視｜AuroraReplicaLagも併せて確認しておくと、全体像が掴みやすくなります。

⏰ EventBridge Scheduler で抑制の有効化・解除を自動化する

CLI で動くことを確認したら、次は自動化です。毎晩手で叩くわけにはいきませんし、叩き忘れたら意味がありません。

Amazon EventBridge Scheduler は、cron 式やレート式でスケジュールを定義し、AWS SDK の API を直接ターゲットとして呼び出せます（ユニバーサルターゲット）。Lambda 関数を書かずに DisableAlarmActions / EnableAlarmActions を呼べるので、構成がシンプルになります。

バッチ開始前・終了後に実行する cron 式スケジュールの組み方

作るのは 2 本のスケジュールです。バッチ開始の少し前に disable-alarm-actions を実行するものと、バッチ終了の少し後に enable-alarm-actions を実行するものです。

⚠️ 抑制開始はバッチ開始より前に、抑制解除はバッチ終了より後に置くのが基本です。アラームは「期間 × 評価期間数」ぶんのデータポイントを見てから遷移するため、バッチ終了ちょうどに解除すると、終了直後に残っている高負荷のデータポイントで ALARM に遷移し、通知が飛んでしまうことがあります。バッチの実測所要時間をもとに、前後のマージンを決めてください。

CLI での作成例は次のとおりです。

aws scheduler create-schedule \
  --name <スケジュール名-disable> \
  --schedule-expression "cron(<分> <時> * * ? *)" \
  --schedule-expression-timezone "Asia/Tokyo" \
  --flexible-time-window '{"Mode":"OFF"}' \
  --target '{
    "Arn": "arn:aws:scheduler:::aws-sdk:cloudwatch:disableAlarmActions",
    "RoleArn": "<スケジューラ用IAMロールのARN>",
    "Input": "{\"AlarmNames\":[\"<アラーム名>\"]}"
  }'

解除側も同様に、ターゲットを enableAlarmActions に変えて作成します。

aws scheduler create-schedule \
  --name <スケジュール名-enable> \
  --schedule-expression "cron(<分> <時> * * ? *)" \
  --schedule-expression-timezone "Asia/Tokyo" \
  --flexible-time-window '{"Mode":"OFF"}' \
  --target '{
    "Arn": "arn:aws:scheduler:::aws-sdk:cloudwatch:enableAlarmActions",
    "RoleArn": "<スケジューラ用IAMロールのARN>",
    "Input": "{\"AlarmNames\":[\"<アラーム名>\"]}"
  }'

実務で効いてくるポイントが 2 つあります。

💡 ひとつはタイムゾーンの明示です。EventBridge Scheduler はスケジュールごとにタイムゾーンを指定できます。JST で運用しているなら Asia/Tokyo を指定しておくと、UTC との換算ミスを防げますし、運用ドキュメントも JST のまま書けるので引き継ぎが楽になります。

もうひとつはフレキシブルタイムウィンドウを OFF にすることです。この機能を有効にすると、指定時刻から一定の幅の中でランダムに実行されます。抑制の開始・解除では「確実にこの時刻より前／後」が求められるため、Mode: OFF にして時刻を固定するほうが安全です。

バッチが平日のみなら、cron 式の曜日フィールドで実行日を絞れます。休日にだけ通知が抑制されたままになる、という事故を避けられます。

スケジューラに渡す IAM ロールと必要な権限

EventBridge Scheduler は、指定した IAM ロールを引き受けてターゲットの API を呼び出します。したがって必要なのは次の 2 つです。

まず信頼ポリシーで、scheduler.amazonaws.com が sts:AssumeRole できるようにします。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "scheduler.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

次にアクセス許可ポリシーで、対象アラームに対する cloudwatch:DisableAlarmActions と cloudwatch:EnableAlarmActions を許可します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudwatch:DisableAlarmActions",
        "cloudwatch:EnableAlarmActions"
      ],
      "Resource": "arn:aws:cloudwatch:<リージョン>:<アカウントID>:alarm:<アラーム名>"
    }
  ]
}

⚠️ 権限は対象のアラーム ARN に絞ってください。ワイルドカードで全アラームを許可してしまうと、設定ミスやロールの流用によって、本来止めてはいけないアラームまで無効化できてしまいます。抑制対象のアラームが複数ある場合は、ARN を列挙するか、命名規則に沿ったプレフィックスで絞るのが現実的です。

信頼ポリシーには aws:SourceAccount や aws:SourceArn の条件を加えて、想定したスケジュールからのみ使われるように制限しておくとさらに堅くなります。

検証環境で意図どおり抑制されているか確認する

本番でぶっつけ本番はやめましょう。検証環境で次の流れを一度通してから本番へ入れるのが安全です。

1. 検証環境のデータベースに対して、閾値を意図的に低く設定したテスト用のメトリクスアラームを作る。すぐに ALARM に遷移する状態を作れるので、通知の有無を短時間で確認できます
2. 手元から disable-alarm-actions を実行し、describe-alarms で ActionsEnabled が false になることを確認する
3. その状態で負荷をかけ、アラーム状態は ALARM に遷移するが SNS 通知は届かないことを確認する
4. enable-alarm-actions を実行し、ActionsEnabled が true に戻ることを確認する
5. EventBridge Scheduler のスケジュールを、直近の時刻で一度だけ動くように作って実行させ、describe-alarms の ActionsEnabled が想定どおり切り替わることを確認する

💡 5 の確認では、スケジュールが失敗していないかも見てください。IAM ロールの権限不足やターゲット ARN の誤記があると、スケジュール自体は登録できても実行時に失敗します。EventBridge Scheduler にはデッドレターキュー（DLQ）を設定できるので、失敗イベントを SQS に流して検知できるようにしておくと確実です。

解除漏れ・抑制漏れを防ぐための作り込み

この仕組みで一番怖いのは、解除が漏れてアラームが無効のまま放置されることです。無効のまま数日過ぎ、その間に本物の障害が起きても誰も気づかない、という事態は避けなければなりません。対策としては次のような作り込みが有効です。

• 解除側スケジュールの失敗検知。EventBridge Scheduler に DLQ を設定し、DLQ にメッセージが入ったら通知する。解除処理が失敗したこと自体をアラート化します
• ActionsEnabled の定期監査。日中の任意の時刻に describe-alarms を実行し、ActionsEnabled が false のアラームが存在しないかを確認する仕組みを入れる。Lambda + EventBridge Scheduler で組めます
• 抑制対象アラームの一覧化。どのアラームをいつ抑制しているかを、Infrastructure as Code（CloudFormation / Terraform など）で管理し、コードを見れば抑制設計がわかる状態にする。コンソールで手作業したものは、時間が経つと誰も理由を説明できなくなります
• 抑制中の代替監視。後述しますが、抑制する CPU アラームとは別に、抑制しない監視（接続数、レプリカラグ、エラーログ、バッチジョブ自体の成否）を残しておきます

🤔 よくある誤解：アクションを無効にしてもアラームの評価は止まっていない

ここが運用担当者への周知で一番つまずくポイントです😇

バッチ中もコンソールが ALARM 表示のままになる

DisableAlarmActions で止まるのはアクションの実行だけです。メトリクスの評価は継続され、閾値を超えればアラームは通常どおり OK → ALARM に遷移します。したがって、バッチ時間帯の CloudWatch コンソールには、ALARM 状態のアラームが表示されたままになります。

これを知らない運用者がダッシュボードを見ると、「アラームが赤いのに通知が来ていない。監視が壊れているのでは」と騒ぎになります。抑制を導入するときは、次の点をセットで周知してください。

• 抑制しているのは通知であり、検知ではない
• 対象のアラーム名と、抑制している時間帯
• コンソールで ALARM 表示になっていても、その時間帯であれば想定どおりであること
• 抑制時間帯外で ALARM が出ていたら、それは調査対象であること

運用ドキュメントに「抑制対象アラーム一覧（アラーム名 / 抑制時間帯 / 抑制する理由 / 解除漏れ時の連絡先）」の表を置いておくと、引き継ぎ時の事故が減ります。

また、アラーム履歴（describe-alarm-history）には抑制中の状態遷移もそのまま記録されます。あとから「あの日は本当にバッチの負荷だけだったのか」を振り返れる点は、むしろメリットです。アクションを無効にしていても、CPU の推移をメトリクスで検証できます。

スケールアップ運用を繰り返すとライターのAZが入れ替わる

抑制ではなくスケールアップで対処する選択をした場合の話ですが、あわせて知っておきたい挙動なのでここで触れます。

Aurora でライターとリーダーの両方のインスタンスクラスを変更する場合、先にリーダーを変更し、そのリーダーへ手動でフェイルオーバーしてから、旧ライター（現リーダー）を変更する順序が推奨されます。ライターのインスタンスクラスを直接変更すると自動ではフェイルオーバーせず、変更が完了するまで書き込みができない時間が発生するためです。

aws rds failover-db-cluster \
  --db-cluster-identifier <クラスター識別子> \
  --target-db-instance-identifier <昇格させるリーダーの識別子>

⚠️ ここで注意したいのは、この手順でスケールアップとスケールダウンを繰り返すと、そのたびに書き込みを担うインスタンスが入れ替わるという点です。ライターを特定の AZ に置くことを前提にした構成（アプリケーションサーバーと同一 AZ に寄せてレイテンシを抑えている、など）では、この AZ の入れ替わりを織り込んでおく必要があります。バッチのたびにライターの AZ が変わる運用は、クロス AZ 通信の増加や、想定外の経路での接続を招くことがあります。

フェイルオーバーが起きたときの確認手順はRDS Multi-AZ フェイルオーバー原因の確認手順にまとめています。意図した手動フェイルオーバーなのか、基盤側の事象なのかを切り分けられるようにしておくと安心です。

🔀 抑制以外の選択肢：閾値の見直し、スケジュールスケールアップ、Aurora Serverless v2

時間帯抑制は有効な手段ですが、状況によっては別のアプローチのほうが運用コストが低く済みます。

期間と評価期間数を調整して一時的なスパイクを拾わない

まず検討すべきは、アラーム設定そのものの見直しです。期間（Period）を長くする、評価期間数（EvaluationPeriods）を増やす、あるいは「M / N」方式で DatapointsToAlarm を調整することで、一時的な負荷上昇をアラームの対象から外せます。

判断基準はシンプルで、「その状態が何分続いたら人が動く必要があるのか」を言語化することです。CPU が数分高いだけで対応することはない、というなら、その「数分」より長い評価条件にすべきです。逆に「10 分続いたら調査を始める」という運用なら、期間 × 評価期間数がそれに近くなるように設定します。

ただし前述のとおり、バッチは「連続して高い」ワークロードです。バッチの所要時間をまたぐほど評価期間を延ばすと、今度は本物の障害の検知が遅れます。バッチの所要時間と、許容できる検知遅延を比べて、両立しないなら時間帯抑制に切り替える。この順序で判断してください。

もう一つの方向として、「CPU 使用率が高いこと」ではなく「業務影響が出ていること」を監視対象にする手もあります。バッチ時間帯でも影響が出るなら鳴ってほしいわけで、そうであればクエリのレイテンシ、接続数の枯渇、レプリカラグ、エラーログのパターンなど、より直接的な指標を監視したほうが、抑制の必要すら減ることがあります。

インスタンスクラス変更はリーダー先行＋手動フェイルオーバーが基本

「バッチの前後でインスタンスクラスを上げ下げする」というアプローチもあります。CPU が足りないなら足せばいい、という直球の対処です。

ただし、インスタンスクラスの変更には停止時間を伴います。前節で述べたとおり、ライターを直接変更すると変更完了まで書き込みができません。そのため、リーダーを先に変更 → そのリーダーへ手動フェイルオーバー → 旧ライターを変更、という順序を取るのが基本になります。

それでも手動フェイルオーバー自体で一瞬の接続断は発生します。アプリケーション側にリトライ処理がない場合、バッチの途中でエラーになる可能性があります。またスケールアップ／ダウンを毎日繰り返せば、その回数だけ接続断とライター AZ の入れ替わりが起きます。CPU アラームを黙らせるために毎晩フェイルオーバーするのは、本末転倒でしょう😅

スケジュールスケールアップが妥当なのは、バッチ処理そのものが CPU 不足で時間内に終わらない、というように実害が出ている場合です。単に通知がうるさいだけなら、抑制か閾値見直しのほうが低リスクです。

停止時間を避けたい場合の Aurora Serverless v2

停止時間を避けつつ負荷に応じたキャパシティを確保したい場合の選択肢が Aurora Serverless v2 です。処理を中断することなく、負荷に応じて自動的にスケーリングされるため、バッチの前後で手動のクラス変更やフェイルオーバーを挟む必要がありません。

⚠️ ただし、導入すれば CPU アラームが鳴らなくなるという話ではありません。キャパシティが自動調整されるということは、CPU 使用率というメトリクスの意味合い自体が変わるということでもあります。監視の設計も併せて見直す必要があり、最小・最大キャパシティの設定や課金の考え方も従来のプロビジョンドインスタンスとは異なります。移行を検討する場合は、対応するエンジンバージョンや制約事項を含め、公式ドキュメントで最新の情報を確認してください。

❓ よくある質問

CloudWatch アラームを特定の時間帯だけ停止できる？

「評価を停止する」という意味ではできません。CloudWatch メトリクスアラームには、時間帯を指定して評価そのものを止める設定はありません。代わりに DisableAlarmActions / EnableAlarmActions でアクション（通知・自動処理）の実行だけを時間帯に応じて切り替えることで、実質的な通知抑制を実現します。切り替えの自動化には EventBridge Scheduler の cron 式が使えます。

アクション無効化中にアラームが解消したら、復旧通知は届く？

アクションが無効な間は、アラーム状態がどう変化してもアクションは実行されません。ALARM → OK の遷移もアクションの対象なので、復旧通知（OK アクション）も届きません。

実務上の意味を考えると、これは「抑制中に起きた ALARM → OK のペアがまるごと通知されない」ということです。したがって抑制解除後に、その時間帯に何が起きていたかをアラーム履歴とメトリクスで振り返る運用を入れておくと安心です。抑制解除の時点でまだ閾値を超え続けていれば、状態は ALARM のままなので、解除後に通知が飛ぶかどうかは実装依存の挙動を含みます。検証環境で実際の動きを確認してから本番に入れてください。

抑制している時間帯に本当の障害が起きたらどう気づく？

これは抑制を導入するときに必ず設計すべき点です。考え方は「抑制するアラームと、抑制しないアラームを分ける」ことに尽きます。

• CPU 使用率の閾値アラームは抑制するが、より高い閾値の「異常レベル」アラームは抑制しない。たとえば通常のバッチ負荷では到達しない水準に別アラームを作り、こちらは常時有効にしておく
• CPU 以外の指標は抑制しない。接続数の枯渇、ストレージ空き容量、レプリカラグ、DB 接続失敗などは、バッチ中でも異常であれば通知すべきです
• バッチジョブ自体の成否を監視する。バッチが異常終了した、想定時間を超えて終わらない、といったジョブ側の監視は、データベースのメトリクス監視とは独立して持っておきます
• 抑制時間帯を最小限にする。バッチの前後に取るマージンは、必要最低限に留めます

抑制は「特定のアラーム 1 本をその時間帯だけ黙らせる」ものであって、監視全体を止めるものではない。そういう設計にしておくことです。

複数のアラームをまとめて無効化できる？

できます。disable-alarm-actions / enable-alarm-actions は --alarm-names に複数のアラーム名を渡せます。EventBridge Scheduler のターゲット入力でも、AlarmNames を配列で指定すれば一括で切り替えられます。

一括指定をするなら、アラームの命名規則を先に整えておくことを勧めます。たとえば抑制対象のアラーム名に共通のプレフィックスを付けておけば、describe-alarms --alarm-name-prefix <プレフィックス> で対象を一覧化でき、IAM ポリシーの Resource もプレフィックスで絞れます。対象が増えたときの管理コストがまったく違ってきます。

⚠️ なお、アラーム名を動的に取得して一括操作するスクリプトを組む場合は、意図しないアラームまで拾わないかを必ず確認してください。プレフィックスの付け間違いで本番の重要アラームを無効化してしまうと、その事実自体に誰も気づけません。

📝 まとめ：抑制は「通知の制御」であって「監視をやめること」ではない

この記事の要点を整理します。

• CloudWatch メトリクスアラームに「時間帯を指定して評価を止める」設定はない。代わりに DisableAlarmActions / EnableAlarmActions でアクションの実行だけを切り替える
• 自動化は EventBridge Scheduler の cron 式 + ユニバーサルターゲットが最もシンプル。タイムゾーンを明示し、フレキシブルタイムウィンドウは OFF、IAM ロールの権限は対象アラーム ARN に絞る
• 抑制を入れる前に、「バッチ時間帯以外でも同じアラームが出ていないか」を必ず確認する。出ているなら別の問題であり、抑制では解決しない
• アクションを無効にしてもアラームの評価と状態遷移は続く。バッチ中もコンソールは ALARM 表示のままになる点を運用者に周知する
• 抑制以外にも、期間・評価期間数の調整、スケジュールスケールアップ、Aurora Serverless v2 という選択肢がある。インスタンスクラス変更は停止時間を伴い、リーダー先行＋手動フェイルオーバーが基本。繰り返すとライターの AZ が入れ替わる点にも注意
• 抑制するアラームと抑制しないアラームを分け、抑制時間帯でも異常を検知できる経路を必ず残す

通知が鳴り続けて誰も見なくなった監視は、設定されていない監視と大差ありません。不要な通知を減らすこと自体は、監視品質を上げる正しい取り組みです。ただしそれは「止めた時間帯に何が起きても気づけない状態」を作ることとは違います。何を止め、何を残すのかを明示的に設計したうえで抑制を入れてください。

なお、CloudWatch や EventBridge Scheduler、Aurora の仕様は変わることがあります。API の挙動、cron 式の書式、IAM の要件、Aurora Serverless v2 の制約などは、実装前に必ず AWS の公式ドキュメントで最新の情報を確認してください。