はじめに

こんにちは、クラウドソリューション事業部の関谷です。
この度、2026 Japan All AWS Certifications Engineersに選出いただきました。資格で得た知識を実践でも活用できるようこれからも精進いたします！！

さて、今年のAWS Summitも終わりひと段落。暑くもなってきたし、そろそろ長期休暇に入る！という方もいるのではないでしょうか。旅行の計画を立てたり、実家への帰省を楽しみにしたりしている方も多いかと思います。

一方で、システム運用に携わっていると、長期休暇の前にはこんな不安がよぎりませんか。

定期実行しているパッチ適用やメンテナンス処理が、誰も見ていない休暇中に動いてしまわないか
休暇中に誰かがうっかり本番環境へデプロイしてしまわないか
「休暇期間中は変更禁止」というルールはあるけれど、運用手順書に書いてあるだけで、仕組みとしては何も止まっていない

せっかくの休みなのに、パソコンを開いてマネジメントコンソールを眺めてしまう……そんなお休みは避けたいものです。
そこで今回は、こうした不安を仕組みで解消してくれる AWS Systems Manager Change Calendar をご紹介します。
長期休暇前に設定しておくことで、「変更凍結期間」をAWS上で表現し、自動処理やデプロイをカレンダーに従って止めることができます。

AWS Systems Manager Change Calendarとは

Change Calendarは、AWS Systems Managerの機能のひとつで、「変更を実行してよい期間／してはいけない期間」をカレンダーとして定義できるサービスです。
カレンダーは常に OPEN（変更可） または CLOSED（変更不可） のどちらかの状態を持ち、他のAWSサービスや自作のスクリプトからこの状態を参照することで、「カレンダーがOPENのときだけ処理を実行する」といった制御が実現できます。
つまり、「休暇期間中は変更禁止」という運用ルールを、手順書上の約束事ではなく機械的に強制できる仕組みに変えられるのがChange Calendarを使用する利点です。

Change Calendarの仕組み

カレンダーの2つのタイプ

カレンダーを作成する際には、デフォルトの状態をどちらにするかを選びます。

タイプ	デフォルト状態	イベント期間中の状態	主な用途
デフォルトOPEN	OPEN（変更可）	CLOSED（変更不可）	普段は自由に変更できるが、休暇期間や繁忙期だけ凍結したい場合
デフォルトCLOSED	CLOSED（変更不可）	OPEN（変更可）	普段は変更禁止で、メンテナンスウィンドウ中だけ許可したい場合

「夏休み中だけ変更を止めたい」というユースケースでは、デフォルトOPENのカレンダーを作成し、休暇期間をCLOSEDイベントとして登録する形になります。

イベントの登録とインポート

Change CalendarはiCalendar形式（.icsファイル）をベースにしており、コンソールからイベントを登録できるほか、既存のカレンダーツールで作成した.icsファイルをインポートすることも可能です。会社の年間カレンダー（年末年始・GW・夏季休暇など）がすでに.icsで管理されているのであれば、それを取り込むだけで変更凍結カレンダーの土台ができあがります。

夏休み前に設定してみる

それでは実際に、夏季休暇（例：8月10日〜8月16日）を変更凍結期間として設定してみます。

Step1. カレンダーを作成する

AWSマネジメントコンソールからSystems Managerを開き、「Change Calendar」を選択して「カレンダーの作成」をクリックします。

名前：summer-vacation-freeze など分かりやすいもの
説明：「夏季休暇中の変更凍結カレンダー」
カレンダータイプ：デフォルトで開く（Open by default）

Step2. 休暇期間のイベントを登録する

作成したカレンダーを開き、「イベントの作成」から休暇期間を登録します。

イベントの名前：summer-vacation2026
開始：2026-08-10 00:00
終了：2026-08-17 00:00　（終了日時の指定に注意。8/16いっぱい凍結したい場合は8/17の0時を指定）
タイムゾーン：Asia/Tokyo

タイムゾーンの指定を忘れるとUTCで解釈され、凍結の開始・終了が9時間ずれるので要注意です。休み明けに出社したら「最後の9時間だけ凍結が早く解けていた」なんてことになったら悲しいですよね。

Step3. カレンダーの状態を確認する

登録が完了すると、カレンダーの詳細画面で現在の状態（OPEN/CLOSED）が確認できます。 CLIで確認する場合は get-calendar-state を使用します。

aws ssm get-calendar-state \
  --calendar-names "summer-vacation-freeze"

{
    "State": "OPEN",
    "AtTime": "2026-07-16T09:57:13Z",
    "NextTransitionTime": "2026-08-09T15:00:00Z"
}

NextTransitionTime で次に状態が切り替わる日時も確認できるので、「ちゃんと休暇初日に凍結が始まるか」を事前に確認できます。（今回の例の場合、8/10にCLOSEDに変更される）

他のサービスと組み合わせて「本当に止める」

カレンダーを作っただけでは、まだ何も止まりません。Change Calendarの状態を各サービスから参照させることで、はじめて「仕組みとして止まる」状態になります。ここでは代表的な連携パターンをご紹介します。

EventBridgeとの連携

EventBridgeでは、カレンダーの状態変化（OPEN⇔CLOSED）をトリガーにルールを起動できます。例えば以下のような使い方が考えられます。

凍結開始（CLOSEDへの遷移）をSlackに通知して、チーム全体に「これから凍結期間です」と周知する
凍結解除（OPENへの遷移）を検知して、休暇中に溜まった処理を再開させる

CI/CDパイプラインからの利用

GetCalendarState を呼び出し、CodePipelineの承認前チェックやデプロイスクリプトの冒頭でカレンダー状態を確認することで、CLOSEDならデプロイを中断させるといった制御も可能です。

これで「うっかり休暇中にデプロイしてしまう」事故も防げます。人間の注意力に頼らず、仕組みで守るのがポイントです。

運用時の注意点

最後に、実際に運用へ組み込む際に意識しておきたいポイントです。

タイムゾーンの確認：前述のとおり、UTCとJSTの取り違えは凍結期間のズレに直結します
緊急時の解除手順を決めておく：凍結期間中でも障害対応などでどうしても変更が必要になるケースはあります。カレンダーのイベントを削除／編集できる権限と手順をあらかじめ整理しておきましょう
参照させ忘れに注意：カレンダーは作っただけでは効果ゼロです。止めたい自動処理・パイプラインすべてがカレンダーを参照しているか、休暇前に棚卸ししておくと安心です