https://xp-cloud.jp/blog/2026/03/26/100000

こんにちは。kanazawaです。
運用自動化を進める中で、祝日や年末年始など
「特定の期間だけ自動実行を止めておきたい」というケースもあるかと思います。
このような場合で活用できるのがAWS Systems Manager Change Calendarです。
今回はAWS Systems Manager Change Calendarの概要と、SSM Automationに組み込んだ例をご紹介します。

AWS Systems Manager Change Calendarとは

AWS Systems Manager Change Calendar(以降Change Calendarとします)とは、AWS Systems Managerの機能の1つで、指定したアクション（Systems Manager Automation Runbookなど）を実行する、またはしない日付と時刻の範囲を設定できるサービスです。
Change Calendarでは、これらの範囲を「イベント」と呼びます。

ユースケース

Change Calendarの利点として、公式ドキュメントでは以下のように説明されています。

変更を適用する前に確認する

適切な時間帯にのみ変更を適用する

カレンダーの現在または今後の状態を取得する

この特性を活かすと、以下のようなユースケースが考えられます。

年末年始や大型連休中のシステム変更を停止したい
大型リリース前夜など、システムを安定させておきたい期間がある
システム管理者が不在の期間中に自動処理が走ることを防ぎたい
月次・年次バッチ処理の実行期間中は他の変更を抑制したい

Change Calendarの作成

それでは、AWSコンソール画面からカレンダーを作成してみます。

AWS Systems Manager > カレンダーの変更を開きます。
※コンソール画面の言語表示設定を日本語にしており、「Change Calendar」→「カレンダーの変更」のようにそのまま日本語訳された表現があります。
「変更カレンダー」をクリックします。
カレンダー名と説明を入力します。
カレンダータイプを選択します。
今回は「デフォルトで開く」を選択します。通常時はOPEN状態で、イベントとして登録した期間中のみCLOSED状態になります。
「Add change management events to the calendar」はオプションです。チェックを入れると、カレンダーの月表示にメンテナンスウィンドウや自動化ワークフローなどの既存スケジュールが表示されるようになります。今回はチェックなしで進めます。
「カレンダーを作成」をクリックします。

カレンダータイプについての補足
Change Calendarには2種類のタイプがあります。

デフォルトで開く（Open by default）：
通常時はOPEN状態で、イベントとして登録した期間中のみCLOSED状態になります。「特定の期間だけ止めたい」という場合に適しています。
デフォルトで閉じる（Closed by default）：
通常時はCLOSED状態で、イベントとして登録した期間中のみOPEN状態になります。「特定の期間だけ許可したい」という用途に適しています。

イベントの登録

カレンダーを作成しただけでは、アクションの許可・禁止は機能しません。
少なくとも1つのイベントを登録する必要があります。

「イベントを作成」をクリックします。
イベント名と説明を入力します。
Advisoryはチェックなしで進めます。チェックを入れると実行制御が無効になり、カレンダー上の表示のみに機能が限定されます。
開始日時・終了日時を入力します。
タイムゾーンを環境に合わせて設定します。
「繰り返し」にチェックを入れると、毎日や毎月特定の曜日などの繰り返しを設定できます。
以下の例では、毎月第3水曜日の0:00～0:30で設定したイベントです。
「予定されたイベントを作成」をクリックします。

実践：RunbookにChange Calendarを組み合わせる

構成の概要

それでは実践として、Runbookと組み合わせた活用例をご紹介します。
Runbookは、こちらの記事で作成したインスタンスタイプ変更処理を使用します。

フローは以下の通りです。

Change Calendarにイベント（変更禁止期間）を登録する
Change CalendarのOPEN/CLOSED状態が変化するとEventBridgeがイベントを検知する
状態がOPENになったタイミングでEventBridgeがRunbookを起動する
Runbookがインスタンスタイプの変更処理を実行する

カレンダー・イベントの設定値

カレンダー

項目	値
カレンダー名	maintenance-schedule
カレンダータイプ	DEFAULT_OPEN
Add change management events to the calendar	無効

イベント

項目	値
イベント名	mon_3rd
説明	毎月第3月曜日のメンテナンス時間
Advisory	無効
開始時刻	22:00:00
終了時刻	22:30:00
タイムゾーン	Asia/Tokyo
繰り返し	毎月第3月曜日

通常時はChange CalendarがOPEN状態のため、EventBridgeのスケジュールに従ってRunbookが実行されます。変更禁止期間中はCLOSED状態になるため、EventBridgeはRunbookを起動しません。期間が終了して状態がOPENに戻ると、再びRunbookが実行されるようになります。

EventBridgeの設定

Amazon EventBridge > ルールを開き、「ルールを作成」をクリックします。
ルール名と説明を入力します。
イベントパターンは以下で設定します。

{
  "source": ["aws.ssm"],
  "detail-type": ["Calendar State Change"],
  "resources": ["arn:aws:ssm:ap-northeast-1:123456789010:document/maintenance-schedule"],
  "detail": {
    "state": ["OPEN"],
    "event": ["mon_3rd"]
  }
}

4.ドキュメント名やインスタンスIDなどの各種パラメータを入力します。 5.「ルールを作成」をクリックします。

動作確認

カレンダーの状態確認

まず現在のカレンダーの状態をAWS CLIで確認します。
※get-calendar-stateには1秒あたり10リクエストのクォータがあります。

aws ssm get-calendar-state \
  --calendar-names "<カレンダー名>"

実行すると以下のように情報が取得できます。

{
    "State": "OPEN",
    "AtTime": "2026-03-25T01:22:50Z",
    "NextTransitionTime": "2026-04-19T15:00:00Z"
}

StateがOPENであること、NextTransitionTimeで次に状態が変わる日時も確認できます。

Runbookの実行結果を確認

設定した時刻になると、EventBridgeがChange Calendarの状態がOPENになったことを検知してRunbookを起動します。
AWS Systems Manager > 自動化から実行履歴を確認します。
意図した時刻にRunbookが起動しなかった場合は、EventBridgeルールの「モニタリング」タブからメトリクスを確認することができます。

補足

DEFAULT_OPENの場合、イベント終了時刻にOPENに戻るタイミングでRunbookが起動します。
EventBridgeのイベントパターンで、resourcesにカレンダーのARNを指定しているため、同じアカウントに別のカレンダーが存在しても影響はありません。
EventBridgeのイベントパターンで、detail.eventにイベント名を指定することで、同じカレンダー内に複数のイベントがある場合でも特定のイベントのみをトリガーにできます。

まとめ

今回はChange Calendarの概要と実際の活用例をご紹介しました。
個人的に、Change CalendarとEventBridgeを組み合わせて制御することで、既存のRunbookに条件分岐などの修正をする必要がない点は大きなメリットであると感じます。
複数のRunbookに対してカレンダーを使い分けるなど、より柔軟な運用にも応用できると思います。
また、サードパーティのカレンダーからイベントにインポートすることも可能なため、スケジュールの管理は使い慣れたカレンダーで、変更がある場合にインポートという運用も考えられます。
運用の自動化を進めている方や、改善を検討されている方はぜひ試してみてください。