Systems Manager の運用自動化(マネージドノード・Run Command・Automation・Patch Manager)

一言まとめ

EC2 を管理下に置く条件は SSM Agent・アウトバウンド経路・IAM ロールの 3 つ。Run Command は OS 内で、Automation は AWS API 側で動く。Patch Manager はベースライン(何を)・パッチグループ(誰に)・メンテナンスウィンドウ(いつ)の 3 部品で組む。

作成 · 更新 · #aws#systems-manager#automation#soa-c03
目次 11 sections
  1. 01 マネージドノード化の 3 条件
  2. DHMC(デフォルトホスト管理設定)の例外
  3. 02 ドキュメントタイプと実行場所
  4. 03 Session Manager
  5. 04 Run Command の安全装置
  6. 05 Patch Manager の 3 部品
  7. 06 State Manager と Inventory
  8. 07 Parameter Store / AppConfig / Secrets Manager
  9. 08 AMI 作成: SSM Automation か EC2 Image Builder か
  10. Auto Scaling 配下をダウンタイムなしで入れ替える
  11. 09 自動修復への接続
  12. 10 関連
  13. 11 更新履歴

調査時点: 2026-07。

AWS Systems Manager(略称 SSM)は、EC2 やオンプレミスのサーバーをまとめて管理し、コマンド実行・接続・パッチ適用などを行う運用管理サービス。

マネージドノード化の 3 条件#

SSM コンソールにインスタンスが出ない、Session Manager で接続できないときの確認点。

  1. SSM Agent が OS 内で稼働している(Amazon Linux 2023 や主要 AMI にはプリインストール)
  2. アウトバウンド経路がある。インターネット経由(NAT)か、閉域なら VPC エンドポイント ssm / ssmmessages / ec2messages
  3. IAM ロール(インスタンスプロファイル)に AmazonSSMManagedInstanceCore が含まれる

オンプレミスや他社クラウドの VM も、SSM Agent を入れて「ハイブリッドアクティベーション」すれば EC2 と同様に管理できる。

DHMC(デフォルトホスト管理設定)の例外#

DHMC を有効にするとリージョン内の EC2 が自動でマネージド化されるが、対象は「IAM インスタンスプロファイルが何も付いていない EC2」だけ。S3 読み取り用など独自ロールがすでに付いた EC2 は DHMC の対象外になり、そのロールに AmazonSSMManagedInstanceCore を手動で足す必要がある。

ドキュメントタイプと実行場所#

ドキュメントは Automation / Command / Session / Policy の 4 タイプ。混同しやすいのは Command と Automation。

タイプ実行場所前提用途
Command(Run Command、State Manager)ゲスト OS の内部SSM Agent が正常起動していることyum update、OS 内の設定変更、ミドルウェア再起動
AutomationAWS の API コントロールプレーン(OS の外側)Agent 不要。OS がハングしていても実行可EC2 停止 / 起動、スナップショットから AMI 作成、セキュリティグループ是正、Config の自動修復

Run Command は OS 内部用なので、セキュリティグループのようなインフラ設定は変更できない。

Session Manager#

SSM Agent がサービス側へアウトバウンド(HTTPS 443)でポーリングする設計のため、SSH(22)/ RDP(3389)のインバウンドを閉じたままシェル接続できる。踏み台と鍵の管理が不要になる。

Run Command の安全装置#

  • 同時実行数(Concurrency): 「同時に 10 台まで」「全体の 20% ずつ」のように台数か割合で制御し、パッチ適用時の負荷集中や一斉ダウンを防ぐ
  • エラーしきい値(Error threshold): 「3 台(または 15%)失敗したら残りをキャンセル」のフェイルセーフ
  • 実行ログは S3 や CloudWatch Logs に自動集約できる

Patch Manager の 3 部品#

部品決めること設定内容
パッチベースライン何を適用するか深刻度、自動承認の遅延日数、明示的な承認 / 拒否リスト
パッチグループ誰に適用するかPatch Group という特別なタグキーを EC2 に付けてグループ化
メンテナンスウィンドウいつ実行するか週末深夜などの時間枠に AWS-RunPatchBaseline を登録

State Manager と Inventory#

  • State Manager: マネージドインスタンスの設定やインストール状態を、定義したポリシー通りに自動維持する
  • Inventory: OS 構成やインストール済みアプリを一覧収集する。収集であって、ポリシーに対する適合判定の機能はない(判定は AWS Config)

Parameter Store / AppConfig / Secrets Manager#

サービス性質向く用途
Parameter Store値の静的な置き場。即時反映。標準パラメータは無料CloudWatch Agent 設定 JSON の一元管理、固定の設定値、頻繁に変えない秘密(SecureString)
AppConfigアプリ設定の「安全な配布」。Validators で事前検証し、線形 / カナリアで段階的に配布、Bake Time 中に CloudWatch アラームが鳴れば自動ロールバック機能フラグ、運用中アプリの設定変更
Secrets Managerライフサイクル管理付きの機密情報。自動ローテーション、ランダム生成。有料DB マスターパスワード、外部サービス認証情報

CloudFormation からの参照方法(ssm-secure と secretsmanager の動的参照)は CloudFormation と CDK を参照。

AMI 作成: SSM Automation か EC2 Image Builder か#

比較SSM AutomationEC2 Image Builder
目的汎用タスクの自動化。AMI 作成は一機能(AWS-UpdateLinuxAmi など)AMI / コンテナイメージのライフサイクルパイプライン
自動テストなし(自作)標準搭載(ビルド・テスト・検証)
他アカウント・リージョン配信自作スクリプト標準搭載(Distribution)
選ぶ場面単発のシンプルな AMI 更新起動テストの自動化、マルチアカウント / リージョン共有

Auto Scaling 配下をダウンタイムなしで入れ替える#

  1. SSM Automation または Image Builder でパッチ適用済みの AMI を作る
  2. 起動テンプレートの新バージョンに新 AMI ID を指定する
  3. Auto Scaling の「インスタンスの更新(Instance Refresh)」でローリング置換する

AWS Config にデプロイ機能はなく、Lambda で CloudFormation を多段操作するワークフローも標準機能で済む以上は選ばない。

自動修復への接続#

Config の Non-compliant 検知、GuardDuty の脅威検知、CloudTrail / EventBridge のイベントから SSM Automation ランブックを起動する構成が、人手を介さない是正の基本形。パターンは EventBridge と自動修復 にまとめた。

関連#

更新履歴#

  • 2026-07-18: 初版(ローカル調査ノート)
  • 2026-10-17: Wiki へ移植、概念ページとして再構成。冒頭に定義を追加

同じトピック — AWS