変更要約: DOP-C02 第5章を深掘り（比較表・シナリオ・FAQ・ひっかけ・深掘り段落を各節に追加、図を日本語版に対応）
5.2自動修復とランブック
検知から修復までの自動化——SSM Automation（ランブック）、Config 自動修復、Lambda 修復、Auto Scaling の自己修復——を理解します。人手を介さず逸脱を是正します。
インシデントは自動で修復できれば MTTR（平均復旧時間）が下がります。ランブックや Config 自動修復で、決まった是正を機械的に実行します。
5.2.1自動修復の仕組み
- SSM Automation（ランブック）：事前定義の修復手順を一括実行（例: 公開 S3 の非公開化、インスタンス隔離）。
- Config 自動修復：ルール違反に修復アクションを関連付け、自動で是正する。
- Lambda 修復：柔軟なロジックで是正。EventBridge から起動。
- Auto Scaling 自己修復：ヘルスチェック失敗インスタンスを自動置換。
「定型の修復手順＝SSM Automation ランブック」「Config 違反の自動是正＝Config 修復アクション」「柔軟な修復＝Lambda」「不健全インスタンス置換＝Auto Scaling」 は DOP-C02 で頻出です。検知→EventBridge→修復（SSM/Lambda）のパターンを押さえましょう。
「公開された S3 バケットを自動で非公開化」「未暗号化の EBS を検出して通知/是正」などは、Config ルール＋自動修復、または EventBridge＋SSM Automation で実装する典型例です。
DOP-C02 では「定型は自動で、判断が要るものは人を挟む」自動修復の設計が問われます。SSM Automation ランブックは YAML/JSON で mainSteps を定義し、aws:executeAwsApi・aws:invokeLambdaFunction・aws:branch（条件分岐）・aws:approve（承認ステップ）などのアクションを組み合わせます。AWS 管理のランブック（例: AWSConfigRemediation-*、AWS-DisablePublicAccessForS3Bucket）が多数用意され、カスタムも作れます。Config 自動修復は非準拠リソースに修復用ランブックを関連付け、検出時に自動実行（手動承認も選択可）し、失敗時のリトライも設定できます。Lambda 修復は複雑な条件や外部 API 連携が要る是正に向き、EventBridge から起動します。多段で状態を持つ復旧フローは Step Functions で可視化・リトライ・補償（ロールバック）を含めてオーケストレーションします。重要なのは冪等性（同じ修復を複数回実行しても安全）とガードレール——破壊的操作の前に承認や条件チェックを挟み、自動修復が暴走しないようにします。修復結果は CloudWatch/SNS で必ず通知し、監査のため CloudTrail と OpsItem に記録します。自己修復（Auto Scaling のヘルスチェック置換）はインフラ層の自動回復として、これらアプリ/構成層の修復と補完関係にあります。
| 修復の性質 | 手段 | 要点 |
|---|---|---|
| 定型の手順 | SSM Automation ランブック | AWS 管理/カスタム・承認ステップ可 |
| 構成違反の自動是正 | Config 修復アクション | ルールに関連付け・自動/手動 |
| 複雑な条件/外部連携 | Lambda | EventBridge から起動・柔軟 |
| 多段の復旧フロー | Step Functions | リトライ/分岐/補償を可視化 |
シナリオ：セキュリティポリシーで「公開された S3 は即座に非公開化、ただし本番データバケットは誤是正を避けるため承認を必須」にしたい。→ Config ルール（s3-bucket-public-*）違反を検知し、汎用バケットは AWS 管理ランブックで自動修復。本番タグの付いたバケットは aws:approve ステップ入りのランブックにルーティングし、担当者が承認してから是正。結果は SNS で通知し、CloudTrail に記録します。
FAQ：SSM Automation ランブックと Lambda、どちらで修復する？ 既製の AWS 管理ランブックで済む定型的な AWS 操作や、承認ステップ・複数 AWS API の手順化なら SSM Automation が簡単で監査も容易。独自ロジック・外部システム連携・細かなデータ加工が要るなら Lambda。両者を Step Functions で組み合わせることもよくあります。
ひっかけ：自動修復は便利ですが、冪等性とガードレールが無いと危険です。破壊的な是正（インスタンス終了、ポリシー変更）を無条件に自動実行すると、誤検知時に被害が拡大します。本番に影響する操作は 承認ステップや対象のタグ条件で保護するのが正解です。また Config の修復は「ルールに関連付け」が前提——ルールだけ作っても自動是正はされません。
5.2.2この節のまとめ
- 修復＝SSM Automation ランブック／Lambda
- 自動是正＝Config 修復アクション／自己修復＝Auto Scaling
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 公開設定になった S3 バケットを検出したら、自動で非公開に戻すという定型手順を実行したい。何を使いますか？
Q2. AWS Config のルール違反を検出したら、追加実装なしで自動的に是正させたい。何を使いますか？
Q3. 検知から修復までを自動化する一般的なパターンとして正しいものはどれですか？