Instiq
第1章 · 監視・ロギング・修復·v2.0.0·更新 2026/6/5·読了目安 約9分

変更要約: SOA-C02 第1章を Associate 級に深掘り(比較表・シナリオ・FAQ・ひっかけ+深掘り段落、図を日本語化)

1.3自動修復(EventBridge と Systems Manager)

この節の要点

EventBridge によるイベントルーティングと Systems Manager Automation(ランブック)による自動修復、Systems Manager の運用機能(パッチ管理・Run Command・パラメータストア)を理解します。

異常を検知したら、可能な対応は自動化して人手を減らすのが運用のベストプラクティスです。EventBridgeSystems Manager Automation が定番の組み合わせです。

1.3.1自動修復の流れ

イベント/アラーム(CloudWatch/Config)→EventBridge ルール(パターンにマッチ)→SSM Automation(ランブック/Lambda)→修復(再起動/パッチ)という、検知からルーティング、ランブック実行、自動修復までの流れを示した図。
自動修復のパイプライン
  • EventBridge:CloudWatch アラームや AWS Config の検知などのイベントをルールで振り分け、修復処理へつなぐ。
  • Systems Manager Automationランブックで再起動・パッチ・設定修正などを自動実行する。
  • Systems Managerの運用機能:Patch Manager(パッチ適用)、Run Command(一括コマンド実行)、Parameter Store(設定/シークレット)。
試験ポイント

「検知をトリガーに自動修復=EventBridge→SSM Automation(ランブック)」「多数のインスタンスへ一括コマンド=Run Command」「パッチ適用の標準化=Patch Manager」 は SOA で頻出です。SSH せず SSM 経由で運用するのが定石です。

運用自動化は「検知→ルーティング→実行」の流れで考えます。EventBridge は CloudWatch アラーム・AWS Config の準拠違反・各サービスのイベント・スケジュール(cron)を イベントルール でマッチし、ターゲット(SSM Automation・Lambda・SNS・Step Functions 等)へ振り分けます。実際の修復は Systems Manager Automationランブック(あらかじめ用意された手順、独自定義も可)が担い、再起動・パッチ・設定修正などを無人で実行します。Systems Manager の運用機能も頻出です:Run Command(多数のインスタンスへ SSH なしで一括コマンド)、Patch Manager(パッチベースラインとメンテナンスウィンドウで適用を標準化)、State Manager(望ましい状態を維持)、Session Manager(ポートを開けずにシェルアクセス・監査可能)、Parameter Store(設定値や SecureString のシークレット)。これらは SSM エージェント+適切な IAM ロール(インスタンスプロファイル)で動き、SSH/RDP を開けずに運用できるためセキュリティ面でも推奨されます。AWS Config の 自動修復(remediation) からランブックを直接呼ぶ構成もよく問われます。

やりたいこと使うもの
検知をトリガーに自動修復EventBridge → SSM Automation
多数インスタンスへ一括コマンドRun Command
パッチ適用の標準化Patch Manager
ポートを開けずシェル接続Session Manager

シナリオ:暗号化されていない EBS が作られたら自動で是正したい。 AWS Config ルールで非準拠を検知→EventBridge(または Config の自動修復)で SSM Automation ランブックを起動し、是正やタグ付け・通知を無人実行。インスタンス操作は Session Manager / Run Command を使い SSH を開けません。

補足

Q. 検知から自動修復は? EventBridge→SSM Automation(ランブック)。Q. SSH を開けずに運用したい。 Session Manager / Run Command(SSM エージェント+IAM ロール)。Q. パッチ適用の標準化は? Patch Manager。Q. 設定値/シークレットの保管は? Parameter Store。

注意

混同に注意:
①SSM が「インスタンスに見えない」原因の定番は SSM エージェント未導入IAM ロール(インスタンスプロファイル)不足
②自動修復のルーティングは EventBridge、実行はランブック——役割を取り違えない。
③Session Manager はインバウンドポート開放不要・操作を CloudTrail/ログに残せる。

補足

SSM を使うにはインスタンスに SSM エージェントと適切な IAM ロールが必要です。これにより SSH を開けずに安全に運用できます。

1.3.2この節のまとめ

  • 自動修復=EventBridge→SSM Automation(ランブック)
  • 運用はRun Command/Patch Manager/Parameter Storeを活用

進捗の記録にはログインが必要です。

理解度チェック

(軽い確認用)

Q1. 特定のイベント検知をトリガーに、再起動などの修復を自動実行したい。最も適した組み合わせはどれですか?

Q2. 多数の EC2 インスタンスへ一括でコマンドを実行したい(SSH を開けずに)。何を使いますか?

Q3. OS のパッチ適用を標準化・自動化したい。Systems Manager の機能はどれですか?

理解度を確認第1章「監視・ロギング・修復」の問題を解く