運用の自動修復設計 EventBridgeとSystems Manager Automationで復旧を無人化する

「障害のたびに担当者が手順書を開いて対応している」という運用を、いかに自動化するか。DOP-C02では検知から復旧までを人手を介さずに閉じる構成が頻出します。ここでは検知手段と実行手段の組み合わせ方を整理します。

覚え方は「何で気づく・何を実行する・失敗したらどうする」の3つの観点

自動修復は必ずこの3つの要素で構成されます。気づく手段はCloudWatchアラーム、EventBridgeイベント、Configの非準拠、ヘルスイベントなど。実行する手段はSystems Manager Automation、Lambda、Step Functions、Auto Scalingの置き換え。そして失敗時の扱いはリトライ、デッドレターキュー、人への通知です。問題文がどの要素を欠いているかを見れば、補うべき選択肢が分かります。

気づく：EventBridgeとCloudWatch

EC2の状態変化、ECSのタスク停止、AWS Healthの計画メンテナンス通知などはEventBridgeのイベントとして流れてきます。メトリクスのしきい値超過はCloudWatchアラームです。使いどころとしては、「インスタンスのステータスチェックが2回連続で失敗したら」のような条件はCloudWatchアラーム、「特定のAPI呼び出しが行われたら」のような条件はCloudTrail経由のEventBridgeルールになります。

実行する：Systems Manager Automation

Automationドキュメント（ランブック）は、EC2の再起動、EBSスナップショットの取得、AMIの作成、パッチ適用といった一連の手順を宣言的に定義でき、承認ステップやレート制御も組み込めます。使いどころは「復旧手順が複数ステップにわたる」「途中に人の承認を挟みたい」「複数アカウントとリージョンへ同時に適用したい」場合。単純な1動作ならLambda、分岐や長時間の待機があるならStep Functionsという使い分けになります。

そもそも壊れたら捨てる：Auto Scalingとヘルスチェック

最も堅牢なのは、異常なインスタンスを直さずに置き換える設計です。Auto ScalingグループにELBヘルスチェックを設定しておけば、アプリケーション層で応答しなくなったインスタンスは自動的に終了し、新しいインスタンスが起動します。使いどころは、ステートレスなWeb層やAPI層。選択肢に「インスタンスを再起動する」と「Auto Scalingで置き換える」が並んでいる場合、ステートレスなら後者が推奨される構成です。

チェックリスト

• EventBridgeルールのイベントパターンとスケジュールの違いを説明できる
• Systems Manager Automationのランブックに承認ステップとレート制御を組み込める
• Auto ScalingのEC2ヘルスチェックとELBヘルスチェックの違いを説明できる
• CloudWatchアラームのEC2アクション（停止、終了、再起動、復旧）を区別できる
• 自動修復が失敗した場合の通知経路（SNS、デッドレターキュー）を設計に含められる

まとめ

自動修復は「検知・実行・失敗時の扱い」の3点セットで設計します。壊れたものを直すより置き換えるほうが確実、という原則を軸に、要件に応じてランブックやワークフローを積み上げていきましょう。 理解度の確認にはクイズが便利です。試験範囲や申し込みの最新情報はAWS認定 公式ページもあわせて確認してください。