[新機能]AWS Systems Manager Change Managerで変更管理のプロセスと承認フローを組めるようになったのでやってみた #reinvent

AWS上の様々なワークフローを組む時の変更管理のプロセスとして組み込むことが可能なSystems Managerの新機能Change Managerがリリースされました!
2020.12.16

こんにちは、臼田です。

皆さん、変更管理してますか?(挨拶

現在開催しているre:Invent 2020にてSystems Managerの新機能としてChange Managerがリリースされました!

Introducing AWS Systems Manager Change Manager | AWS News Blog

早速触ってどんな事ができるのか確認してみたいと思います。

Change Managerとは

端的に言うと、Change Managerは変更管理のためのサービスです。

ある作業を行うために、作業のリクエストを行い、承認者が承認したらプロセスが実行されるというものです。

より安全性のある業務フローを実装するための仕組みで、リリースブログの例ではITILv4やDevOpsなんかで利用するツールと同じ役割で利用できるとあります。

AWSにある程度熟知されている方は、既存でCodePipelineを利用した変更の承認プロセスを思い浮かべるかと思いますが、まさにそれと同じような役割のものです。

違いとしては、承認後の実行プロセスはAWS Systems ManagerのAutomation機能を用いて実行されるところです。CodePipelineはDevOpsの一環で利用されるイメージが強いかと思いますが、Automationはもっと幅広く様々な処理に利用することができ、CloudFormationの実行やEC2の作成やバックアップ、StepFunctions / Lambdaの実行など様々なオペレーションを実行できます。

つまり幅広い運用に対して変更管理のプロセスを組み込むことが可能です。

また、マルチアカウント連携の機能がデフォルトであり、AWS Organizationsと連携した複数アカウントにまたがる変更処理の適用やAWS SSOと連携したユーザー機能によりスムーズな利用が可能です。もちろんシングルアカウントでも利用可能です。

やってみた

結局文面だとよくわからないと思うのでやってみます。私もやってみるまでよくわからなかったので。

事前設定

Change ManagerのコンソールはSSMからアクセスできます。

Change Managerの使い始めには設定が必要です。「設定」タブへアクセスして「編集」を押します。

承認フローで利用するユーザーIDの選択をします。IAMかAWS SSOを選択できます。今回はシングルアカウントで行うためIAMを選択します。注意事項として、現状ではIAMを利用する場合IAM UserかIAM Groupしか利用できません。 つまりIAM Roleが利用できません。

選択すると確認が出ますので続行します。選択が終わったら下の方に行き設定を保存します。

実行用IAM Role作成

ChangeManagerからはSystems Manager Automationが実行されますが、これを実行するためのIAM Roleが必要になります。詳細はこちらにあります。

過去にこの部分を以下の記事に書きましたが、少し新しくなっているのもあるのでここで詳細に書いていきます。

コンソールでIAM Roleの画面からロールの作成を行います。

AWSサービスの中からSystems Managerを選択し、ユースケースもSystems Managerを選択して次へ進みます。

ポリシーはマネージドとして既存であるAmazonSSMAutomationRoleを選択します。実際には実行する内容に合わせたポリシーをここで追加することも可能です。

最後に適当にロール名を設定します。今回はChangeManagerAssumeRoleとします。

作成したら該当のロールの詳細画面を開き、ARNを控えておきます。インラインポリシーの追加を行います。

iam:PassRoleを追加します。サービスでIAM、アクションでPassRoleを選択してリソースでARNの追加を押します。

先程控えた作成したRole ARNを貼り付けます。

次へ進んで適当なポリシー名を入れて作成します。

これでRoleの準備は完了です。

承認リクエスト

それではいよいよ変更管理のプロセスを回してみます。

今回はデフォルトで用意されているAWS-HelloWorldChangeTemplateテンプレートを利用してみます。

テンプレートでは実行するランブック(Automationのドキュメント)やその内容が自由にMarkdownで記述されたテンプレート情報、承認ユーザー、通知先などが定義されていて、このテンプレートもバージョン管理できるようになっています。

AWS-HelloWorldChangeTemplateはお試し用なので、実行されるランブックはLambdaで"Hello World. Welcome to Change Manager"と出力するだけのものです。

やっていきましょう。Change Managerのテンプレートタブからテンプレートを選択して「リクエストを作成」します。

リクエストの作成では変更の内容やワークフローの実行タイミング、承認者などを設定します。

リクエストの詳細には自由にMarkdownの記述ができます。日本語も入りました。プレビュー機能で見え方の確認もできます。

ワークフローのタイミングは承認後即実行と、スケジュールがあります。以下はスケジュールのイメージを掴むためにスケジュール実行を選択していますが、今回は即実行を選択します。

続いて承認者です。承認者を追加ボタンから選択できます。リクエストを通知するSNSも選択できます。「通知を追加」を押さないと追加されないので注意。

ユーザー追加の画面は以下のような形で、前述の通りRoleはまだ選べません。

次の画面では実行Roleの選択があるので、先程作成したIAM Roleを選択します。マルチアカウントの場合のデプロイするアカウントや対象のリソースを選べますが今回は飛ばします。

確認画面です。まだ変更が直接行われるわけではなく、承認リクエストを飛ばすだけであることが強調されています。承認リクエストを送信します。

これでリクエストが飛びました。この画面でもテンプレート情報に日本語が適切に表示されています。

承認と変更

続いて承認者のフローをやってみます。

先程のSNSで私はSlack通知と連携していたので(Chatbotではない)以下のように通知が来ました。URLもあります。

URLにアクセスして内容を確認します。よければ「承認」します。

コメントを残すことが可能です。このコメントはあとから確認できるので変更管理の証跡を残せますね。

承認されました。変更プロセスが実行されます。

しばらくするとステータスが成功になりました。内容を確認するため「実行ID」からAutomationの結果を確認します。

SSM Automationの画面に来ました。実行されたステップから詳細を確認します。

テンプレートとして用意されていたLambdaの実行が行われ、出力として"Hello World. Welcome to Change Manager"が表示されていることが確認できます。

Change Managerに戻りタイムラインを確認します。一連の処理がいつ行われたかわかります。わかりやすいですね。

承認者やステータス、コメントも確認できます。

これで一連の動きが確認できました。

価格

Change Managerは利用費がかかります。詳細はSSMの価格へ。

変更リクエストごとに0.296ドル発生します。また各種API実行では1,000リクエストあたり0.039ドル発生します。

特に大きいのは1つのリクエストあたりの料金だと思うので、フローを組む場合には少し気にしたいですね。

とはいえこれらの管理をAWSの中で完結できることには非常に意義があるので、必要であれば使っていくといいでしょう。

また、連携して動く仕組みにももちろん費用がかかりますので注意して下さい。

まとめ

AWS Systems Manager Change Managerの動作を見てきました。

CI/CDに限らない業務的な変更管理も、承認フローを組み込んで自動化しながら利用できるので嬉しい新機能ですね。

特にマルチアカウントで利用できるところは素晴らしいです!ぜひ運用フローを自動化する際には使ってみてはいかがでしょうか?