同じアカウント・リージョンのEC2がstoppedになったら、通知を含む準備済みSystems Manager Automation runbookを開始したい。runbookはInstanceIdを必須入力とし、必要なIAMロールも準備済みである。
定期ポーリングを使わず、対象インスタンスIDを実行手順へ渡す構成にしたい。
最も適切な構成を2つ選べ。
EventBridgeルールでEC2のstoppedイベントを選び、Automation runbookをターゲットにする。イベントのインスタンスIDを入力に渡し、呼び出しと手順実行の権限を設定する。
詳細解説
定期的な確認であり、状態変更イベントに直接反応する要件には合わない。
イベントの構造とrunbookの入力名・型は異なる。イベント全文を渡すだけでは、必須のInstanceId入力を満たしたことにならない。
詳細モニタリングはメトリクスの粒度を変える設定であり、イベントからrunbookを起動する接続ではない。
状態変更イベントのパターンを使い、対象状態への遷移をポーリングせずに検知できる。
準備済みの通知・対応手順を起動する。ルールのターゲット入力と実行ロールの設定も必要になる。
公式資料で確認する
以下の項目を公式資料の記述と照合して確認します。
EventBridge EC2 state-change eventsとSSM Automationの公式説明を確認する。
参考にした公式資料
確認できる内容
イベント検知と修復手順の自動化を接続できる。
理解のポイント
- EventBridge
- EC2 state-change
- SSM Automation
確認時の注意
- 確認環境: AWS公式SOA-C03試験ガイドとAWS公式ドキュメントの確認
- AWS公式SOA-C03試験ガイドと各サービスの公式ドキュメントを確認する。
基礎のおさらい
検知条件と実行対象を接続する
sourceがaws.ec2、detail-typeがEC2 Instance State-change Notification、detail.stateがstoppedのイベントを選ぶ。$.detail.instance-idからIDを抽出し、runbookが要求するInstanceIdなどの入力名・型へ変換する。ターゲットを指定するだけでは必須入力は自動的に揃わない。サンプルイベントで入力変換を確認する。
呼び出し権限と手順の権限
EventBridgeがAutomationを開始するロールと、runbook内の通知・操作を実行する権限を区別する。対象操作に絞った権限を付け、実行結果も確認する。