はじめに
こんにちは！
株式会社ＢＦＴ名古屋支店・インフラ女子（？）のやまぐちです。
最近Systems Managerの素晴らしさに改めて気づかされています。運用の自動化ってここまで進んでいるんだなぁと驚きを隠せないのですが、「誰かの承認後に○○する」というランブックを試してみたので興味のある方は読んでいただけると嬉しいです。
承認後にEC2インスタンスを起動する
なんで承認が必要なの？
承認を挟むワークフローを実装するのは、「勝手な操作をさせない」という監査目的が多いのではないでしょうか。
今回のEC2インスタンスの起動であれば、例えばそのEC2インスタンスを使うチームには起動停止の権限を与えておらず、起動時間（費用）の把握のために上長承認が必要、といったケースが考えられそうです。
Code Pipelineで承認のステージを実装した際に「これは素晴らしい…！」と感動しましたが、同じことがSystems Managerでもできるなんて、これを使わない手はないですね。
前提条件
それでは実際に実行する前に必要な環境をチェックし、さくっと実装していきましょう。
- SNSのトピックが作成済であること
- サブスクリプションも完了していること
- 承認できるIAMユーザが作成済みであること
- 複数人設定できる
- 承認者がAWS Systems Managerの承認を行う権限を有していること（具体的には「AmazonSSMAutomationApproverAccess」があればよさそう）
- 起動したいインスタンスが作成済みで停止していること
- 実行対象がSystems Managerのマネージドインスタンスであること
オートメーションで実装してみよう
Systems Managerの [ 自動化 ] メニューから [ オートメーションの実行 ] を押します。
[ AWS-StartEC2InstanceWithApproval ] を選択し、[ 次へ ] を押します。
起動したいインスタンスを選択し、Approvers(どのIAMユーザに承認させるか)、SNS TopicArnを入力、[ 実行 ] を押します。
[ approval ] ステップのステータスが [ 待機中 ] となりました。設定したトピックから送信される宛先にメールが届いているか確認します。
今回はメーリングリスト宛てに送信しました。承認するにはApproveのリンクを押せば良さそうです（欲を言えば何の承認かわかるといいけど…）。
承認可否を送信するページに飛びました。実行対象などは実行IDのリンクから確認できそうですがちょっとわかりにくそうですね。[ 送信 ] を押します。
[ approval ] ステップのステータスが [ 成功 ] となり、[ startInstances ] ステップが [ 進行中 ] となりました！しばらくするとステータスは [ 成功 ] に変わります。
目的のインスタンスが起動していることを確認できました！簡単ですね～
実装のポイント
ここで一番のポイントは「誰」が承認できるか、の設定箇所です。今回のようにメーリングリスト宛てにメールを送った場合、メーリングリストのメンバーでも権限のある人だけが承認できます。
また、弊社の環境ではAssumeRoleを使った権限付与でAWSを使っていますが、Approversに私のIAMユーザ名をいれただけでは送信ボタンを押せませんでした。
正しくは、AssumeRole経由での私のユーザ名となり、以下のように指定する必要がありました。
arn:aws:sts::<AWSアカウントID>:assumed-role/<ロール名>/<IAMユーザ名>
この辺りはうまく権限が与えられていない場合のエラーメッセージに権利を持っているのは～～だよ、とARNを表示してくれるのでわかりやすくてよかったです。
終わりに
こうして承認のプロセスが入ったワークフローがあると何かと便利です。自分で自動化ドキュメントを作成する際にもある程度コードをコピーして使えるがオートメーションのいいところですね！
2022/05時点で承認を含むオートメーションはインスタンスの作成・起動・停止・再起動・削除、CloudFormationの削除・更新、Amazon WorkSpace（仮想デスクトップ）のリカバリーなどが用意されています。
興味のある方はぜひ使ってみてください！
以上、ここまで読んでいただきありがとうございました～ ^ ^
