[アップデート] AWS Systems Manager の Automation で Change Calendar を統合して許可されている期間以外はブロック出来るようになりました

いわさ

2023.02.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

いわさです。

本日のアップデートで SSM の Automation の設定に Change Calendar を統合することが出来るようになりました。

Change Calendar を統合することで、カレンダー上でブロックされている時間帯の Automation の実行をデフォルトで拒否することが出来るようになりました。
これによって、意図しない時間帯にワークロードへ影響を与える変更が発生してしまうリスクを下げることが出来るようになります。

SSM Automation と Change Calendar については以下の記事に全てまとまっています。

抜粋すると、Automation は AWS リソースに対する一連の操作を実行できる Runbook と呼ばれるドキュメントを使うことでオペレーションの自動化や簡略化を行うことが出来ます。

Change Calendar は Automation やメンテナンスウィンドウなどの変更作業を許可する期間/禁止する期間を設定することで、実行を制御出来る機能です。
今回のアップデートと何が違うのか？という感じもすると思いますが、従来は Runbook ドキュメント内のステップでカレンダーをチェックするステップが明示的に必要でした。

以下の記事ではカスタム Runbook にカレンダーのチェックを追加して、許可された期間内で実行出来るようにしています。

今回アップデートで追加された統合機能は「Automation 全てに対して、指定したカレンダーを関連付けて、許可されてない時間帯は一切の Automation 実行を禁止する。」というものです。

設定方法

設定方法は簡単で、Automation の設定タブでカレンダーを指定するだけです。

新たに「Observe change controls」が追加されており、ここで機能の有効・無効設定と、対象カレンダーを設定することが出来ます。

カレンダーはひとつまで選択出来ます。
また、対象カレンダーはいつでも変更可能で、統合自体もいつでも無効に変更することも出来ます。

なお、保存時の設定は以下のアクションが実行されていました。

{
:
    "eventTime": "2023-01-31T20:55:59Z",
    "eventSource": "ssm.amazonaws.com",
    "eventName": "UpdateServiceSetting",
    "awsRegion": "ap-northeast-1",
    "sourceIPAddress": "203.0.113.1",
    "userAgent": "AWS Internal",
    "requestParameters": {
        "settingId": "/ssm/automation/safety-control/change-calendars",
        "settingValue": "hogecalendar"
    },
:
}

本日時点の v1.27.61 の以下ドキュメントではこの SettingId について記述がありませんでしたが、そのうち追加されそうな気がしますね。

ブロックされると「Cannot Start Automation Execution because calendar(xxxx) is in CLOSED state」が発生する

ブロックされた時間帯

カレンダーを統合したので Automation 実行してみます。
今回統合したカレンダーは Default Open の設定になっています。

そのため、以下のようにイベントを作成すると、イベント期間中はブロックされる時間帯となります。

ここで、デフォルトで提供されている EC2 インスタンス再起動の Runbook を実行してみましょう。

次のメッセージが表示されて、実行に失敗しました。

Cannot Start Automation Execution because calendar(xxxx) is in CLOSED state

このようにユーザーにカレンダーでブロックされた時間帯であることが示されます。

オープンされた時間帯

統合中のカレンダーの設定を変更し Default Closed にしてましょう。

そうすると、先程のイベント時間中のみ実行が許可されます。

先程と同様に Automation を実行してみると、今度は成功しました。良いですね！

Change Manager でもちゃんとブロックされる

SSM には Change Manager という機能もあって、オペレーションタスクへ承認ワークフローを実装することが出来ます。

この機能を使うと Change Manager で承認された際に Runbook が実行される場合があります。
この時どういう動きになるのか気になったので試してみました。

まず、変更リクエスト自体は問題なく作成出来ます。
ブロックされた時間帯で承認後即実行でのタスクリクエストを送信しました。

承認者側で承認してみましたが、問題なく承認されました。
特にエラーも発生しません。
リクエストでは即時実行がリクエストされているので、承認後すぐに実行されるはずです。

Change Manager 上のタスクを見てみると、タスクの実行に失敗していました。
タスク上は手動実行と同じメッセージが表示されていますね。
自動実行の場合でも同じようにブロック出来ていることが確認出来ました。

さいごに

本日は SSM Automation で Change Calendar を統合して許可されている期間以外がブロック出来るようになったので使ってみました。

Automation でオペレーションタスクを実行していて本番ワークロードを実行している環境で、一切のメンテナンスタスクを許可したくない重要な時間帯に設定しておくと、誤った Automation の実行でワークロードへ影響を与えるリスクを下げることが出来ます。
従来はドキュメントのステップで構成する必要がありましたが、Automation の共通設定として簡単に設定出来るようになったので使いやすくて良いですね。

AWS