AWS Systems ManagerのAutomationとChange Calendarが統合されました
AWS Systems Manager AutomationとAWS Systems Manager Change Calendarが統合されました。
これにより、カレンダーで指定した期間のみAutomationの実行を許可/拒否できるようになるので、検証してみました。
アップデート概要
- AWS Systems Manager AutomationとAWS Systems Manager Change Calendarが統合された
- これまでは、ドキュメントでカレンダーをチェックする処理をユーザが実装する必要があったが、今回のアップデートでオートメーションとカレンダーを関連付けることで、ユーザが実装することなく手軽に統合できるようになった
オートメーションを実行する
統合前にAutomationを実行して挙動を確認します。
テスト用のEC2インスタンスを用意します。
「AWS Systems Manager」→「オートメーション」→「オートメーションの実行」を押下します。
EC2インスタンスを再起動するドキュメント「AWS-RestartEC2Instance」が標準で用意されているので、今回はそれを使用します。
入力パラメータで用意したEC2インスタンスを選択して実行します。
しばらく待つと実行が完了します。
カレンダーを設定する
それでは、カレンダーを設定して先ほどの手順を実行してみます。
「オートメーション」→「設定」→「設定」を押下します。
「Turn on Change Calendar integration」にチェックを入れます。
「Create Change Calender」を押下します。
今回は、カレンダータイプを「デフォルトで開く」にして作成します。
カレンダータイプは以下の違いがあるので、要件に応じて設定するとよいです。
- 「デフォルトで開く」はイベント期間中は実行を拒否
例えば、メンテナンスやリリース作業の時間帯は実行拒否したい場合に、拒否する時間帯をイベントとして登録 - 「デフォルトで閉じる」はイベント期間中のみ実行を許可
例えば、実行頻度が低く限られた時間帯に実行許可したい場合に、許可する時間帯をイベントとして登録
カレンダーが作成できたので、イベントを作成してみます。
今回のカレンダータイプは「デフォルトで開く」なので、イベントスケジュールの時間帯は実行を拒否できます。
イベントが作成されました。
オートメーションの画面で作成したカレンダーを選択し、保存します。
オートメーションの実行拒否を確認
先ほどオートメーションを実行した手順で、「AWS-RestartEC2Instance」を実行してみます。
すると、「Cannot Start Automation Execution because calendar(test-calender) is in CLOSED state」と表示され実行が拒否されました。
Change Managerの実行拒否を確認
AWS Systems ManagerにはChange Managerという機能があり、オートメーションに承認機能を追加したものです。
このChange Managerも同様に実行拒否されるのか確認します。
Change Managerテンプレートを作成します。
ランブックは「AWS-RestartEC2Instance」を指定します。
このテンプレートでリクエストを作成します。
ランブックのパラメータは、テスト用のEC2インスタンスを選択します。
リクエストを作成しました。
指定した承認者の画面で、「承認」を押下します。
ステータスが「完了 (エラーあり)」と表示されています。
詳細を確認すると、「Failed to start runbook due to: Cannot Start Automation Execution because calendar(test-calender) is in CLOSED state」と表示され実行が拒否されました。
まとめ
オートメーションやChange Managerは便利ですが、メンテナンスやリリース作業時には実行して欲しくない要件があると思います。
これまでは、ドキュメントでカレンダーをチェックする処理をユーザが実装する必要がありましたが、今回のアップデートで手軽に統合ができるようになりました。
本番環境に対するリスク低減や内部統制の観点でも、非常に使い勝手が良い機能だと思います。
