AWS Systems Manager完全ガイド：Session Manager・Patch Manager・Automationを軸に、GCP OS Config（VM Manager）/Azure Update Manager（Arc）と比較して学ぶ運用設計
先に結論（この記事の要点）
AWS Systems Manager は、AWS・オンプレミス・マルチクラウドにまたがるサーバー（ノード）を、ひとつの考え方で「見える化・遠隔操作・パッチ・自動化」できる運用プラットフォームです。統合コンソールのもとに、Run Command、Session Manager、Automation、Patch Manager、Inventory など複数の機能が揃っています。:contentReference[oaicite:0]{index=0}
特に実務で効くのは次の3点です。
- 入口の整理：Session Manager によって、踏み台（bastion）や不要な受信ポート公開を減らしつつ、中央集権的なアクセス制御と監査ログを取りやすくできます。:contentReference[oaicite:1]{index=1}
- 継続的な健全性：Patch Manager とメンテナンスウィンドウで、パッチ適用やスキャンを計画的に回し、適用状況（コンプライアンス）を追えるようにします。:contentReference[oaicite:2]{index=2}
- 仕組み化：Automation（ランブック）や Run Command（ドキュメント）で、日々の運用を「人の手順」から「再現可能な手続き」に移せます。:contentReference[oaicite:3]{index=3}
比較対象として、GCP は OS Config（VM Manager）でパッチやOSインベントリを提供し、インベントリはエージェントが定期スキャンしてデータを送信する仕組みです。:contentReference[oaicite:4]{index=4}
Azure は Update Manager が、Azure・オンプレ・他クラウドのマシン（Azure Arc 接続）まで含めて更新コンプライアンスの監視と更新スケジュールを扱う統合サービスとして説明されています。:contentReference[oaicite:5]{index=5}
また、Azure Automation の旧 Update Management は 2024-08-31 で終了し、Azure Update Manager への移行が推奨されています。:contentReference[oaicite:6]{index=6}
この記事が役に立つ方（具体的に）
サーバー運用は、誰かの「頑張り」だけで回していると、夜間対応や属人化で必ず苦しくなります。Systems Manager は、運用をチームの資産に変えるための道具箱です。特に、次の方に向けて書いています。
-
小〜中規模のプロダクトで、サーバー台数が増えてきたバックエンド開発者の方
まだ“手作業SSH”で何とかなる時期を過ぎた頃、台数が増えるほど「同じ操作を安全に繰り返す」難しさが一気に上がります。Systems Manager を入れると、作業の再現性が上がり、ミスや抜け漏れが減ります。 -
SRE/運用担当として、監査・セキュリティの説明責任が増えてきた方
「誰が、いつ、どのサーバーで、何をしたか」を後から追える状態は、セキュリティ対策だけでなく、障害対応の品質にも直結します。Session Manager の監査・ログ設計が、運用の背骨になります。:contentReference[oaicite:7]{index=7} -
マルチクラウドやハイブリッドを見据え、共通の運用レイヤーを作りたいアーキテクトの方
GCP の OS Config、Azure の Arc + Update Manager と並べて考えることで、「運用の共通語彙（パッチ、インベントリ、リモート実行、監査）」を揃えやすくなります。:contentReference[oaicite:8]{index=8}
1. AWS Systems Managerとは：ノード運用のための“統合コンソール＋ツール群”
AWS Systems Manager は、ノード（例：EC2、オンプレ、他クラウドVMなど）を、大規模に一元管理するためのサービスです。統合されたコンソール体験のもと、ノードの閲覧、診断、修復、そして Run Command・Session Manager・Automation・Parameter Store など複数のツールをまとめて使える、と公式に説明されています。:contentReference[oaicite:9]{index=9}
ここで大事なのは、Systems Manager が「単機能のサービス」ではなく、運用で必要になりがちな機能を束ねた“運用プラットフォーム”だという点です。ログ監視やアラート、デプロイの仕組みは別途あっても、サーバーの中に入って作業する・パッチを当てる・状態を揃える、といった行為は最後に必ず残ります。その最後の部分を、より安全に、より再現可能にするための土台が Systems Manager です。
また、クォータ（上限）も機能別に整理されており、Patch Manager、Session Manager、Inventory、Automation など各ツールにサービスクォータがあることが一覧で示されています。規模が増えたときは、技術的な上限を早めに把握するのが事故防止に効きます。:contentReference[oaicite:10]{index=10}
2. まず押さえる基本用語：マネージドノード、SSMドキュメント、スケジュール実行
2-1. マネージドノード（Managed node）
Systems Manager の対象になるサーバーは「マネージドノード」として扱われます。AWS内だけではなく、オンプレやマルチクラウドも含めて運用対象にできる、という説明が “What is AWS Systems Manager?” に含まれています。:contentReference[oaicite:11]{index=11}
実務的には、まず「どのサーバーをマネージドノードにするか」を決めるのが第一歩です。全台を対象にするのか、重要な一部から始めるのか。移行の順番を決めておくと、運用が混乱しにくいです。
2-2. SSMドキュメント（Documents）
Systems Manager の多くの操作は「ドキュメント」を実行する形になります。Run Command で使うコマンドドキュメント、Automation で使うランブックなど、実行の型をドキュメントとして管理し、パラメータを差し替えて繰り返す運用に向いています。AWSの解説資料でも、ドキュメントをどう実行するかの中心に Run Command がある、という位置づけが示されています。:contentReference[oaicite:12]{index=12}
2-3. 定期実行：State Manager と Maintenance Windows
運用で本当に効くのは「手動実行」より「定期実行」です。AWSの運用管理向け資料では、Run Command や Patch Manager を定期実行する制御として State Manager が活躍すること、またメンテナンスウィンドウでスケジュールに沿ってタスク実行を組めることが示されています。:contentReference[oaicite:13]{index=13}
「何を、いつ、誰に」実行するかを、設定として残す。これができるだけで、運用はかなり穏やかになります。
3. Session Manager：踏み台を減らし、アクセスを“監査可能な作業”にする
3-1. Session Managerの価値は「入口の再設計」
Session Manager は、マネージドノードへ安全にアクセスするための仕組みとして、受信ポートを開けたり踏み台ホストを維持したりせずにアクセスできる、と公式ドキュメントで説明されています。さらに、IAMポリシーで中央集権的にアクセス制御できる点も同じ文脈で述べられています。:contentReference[oaicite:14]{index=14}
これは運用の現場だと、次の痛みを解消します。
- SSH鍵の配布とローテーションがつらい
- 踏み台が単一障害点になりやすい
- “誰の作業か”がログで追えない
- インシデント時に、緊急アクセスの統制が崩れる
Session Manager を軸にすると、「アクセスは手段ではなく、統制された運用プロセス」という扱いに近づきます。
3-2. 監査ログ：何が残り、何が残らないかを先に理解する
Session Manager はセッション活動の監査について、CloudTrail で記録される API 操作の記録と、セッション内の操作ログ（CloudWatch Logs / S3 への記録）という二層で整理されます。公式の監査ドキュメントでは、EventBridge 連携は CloudTrail に記録された API 操作の記録に依存する、と説明されています。:contentReference[oaicite:15]{index=15}
また、セッションログを CloudWatch Logs や S3 に出力する手順や注意点、そして「ポートフォワーディングやSSH経由の接続ではログ取得に制限がある」ことも明記されています。:contentReference[oaicite:16]{index=16}
実務の設計では、次のように“ログの設計”を先に決めるのがおすすめです。
- 監査の主目的が「いつ誰が接続したか」なのか
- 主目的が「セッション内で何を実行したか」なのか
- どの保存先（S3/CloudWatch Logs）を正式な保管場所にするか
- 保持期間（保存コスト）と、改ざん耐性（監査要件）をどう両立するか
ここが曖昧だと、あとで「ログが足りない」「多すぎて見られない」が起きやすいです。
3-3. サンプル：踏み台を減らす“入口の型”
入口を整理するための、よくある最小構成の考え方です。
- サーバーはプライベートサブネットに配置
- 受信ポートは原則としてアプリの入口（LB等）からのみ許可
- 運用アクセスは Session Manager を正式経路にする
- セッションログを CloudWatch Logs または S3 に集約し、保持と権限を明確化する:contentReference[oaicite:17]{index=17}
この型に寄せていくだけで、「踏み台の保守」「鍵配布」「SG穴あけ運用」が減り、チームの心理的負担が下がります。
4. Run Command：サーバー操作を“ドキュメント化”して安全に繰り返す
Run Command は、マネージドノード上でコマンドを実行するための仕組みとして、SSMドキュメントを実行する中心的な方法です。AWSのBlack Belt資料でも、ShellScript 実行や Ansible 実行などの例を含め、Run Command の用途が整理されています。:contentReference[oaicite:18]{index=18}
4-1. 実務での使いどころ
Run Command が輝くのは、次のような“同じことを何度もする”作業です。
- 重大インシデント時の一次調査（ログ収集、プロセス確認、ディスク逼迫確認）
- エージェントや設定の投入（監視エージェントの更新、設定ファイル配布）
- 緊急パッチの適用前後の健全性チェック（サービス稼働確認、依存関係の確認）
- 一時的な防御（FWルール調整、設定変更）
ここでのポイントは、作業手順を「個人のコマンド履歴」ではなく「SSMドキュメント」として残し、パラメータで環境差を吸収することです。これでレビュー可能になり、運用の品質が上がります。
4-2. サンプル：障害対応の“ログ収集ドキュメント”の発想
たとえば、障害時に毎回やる作業をテンプレ化します。
journalctlで直近30分のログを収集- CPU/メモリ/ディスクのスナップショットを取得
- 重要プロセスの状態を出力
- 収集物を決められた場所へ集約
これを Run Command で全対象に一斉実行できるようにしておくと、夜間対応のプレッシャーがかなり減ります。特に「何台に影響があるか分からない」障害で効果が出ます。
5. Patch Manager：パッチを“計画・適用・証跡”まで含めて運用する
パッチ運用は、やる気だけでは回りません。頻度、対象、失敗時の扱い、検証、そして説明責任までセットだからです。Patch Manager は、広範囲のノードへのパッチ適用を支える機能として説明されており、メンテナンスウィンドウで Scan や Scan and install を Run Command タイプのタスクとして定期実行できる、と公式ドキュメントで具体的に触れられています。:contentReference[oaicite:19]{index=19}
5-1. パッチ運用を“運用品質”として設計する観点
実務で先に決めておきたいのは、技術よりも方針です。
- 毎月の定例パッチ（何曜日・何時・どの程度の猶予）
- 緊急パッチ（脆弱性対応）の優先順位と、例外運用のルール
- 失敗したときの扱い（自動リトライ、手動介入、ロールバック可否）
- 適用後の検証（サービス再起動、ヘルスチェック、監視の確認）
- 報告形式（どの範囲が何％適用済みかをどう示すか）
Patch Manager は、これらを“仕組みとして回す”方向に押してくれます。ただし、最終的に事故を防ぐのは、方針と手順の合意です。
5-2. サンプル：月次パッチの最小テンプレ
- 週末深夜に「スキャン」だけ先に回す（影響を見える化）
- 別のメンテナンスウィンドウで「インストール＋再起動」を実施
- 事後に健全性チェックの Run Command を自動実行
- 結果を“適用率”“失敗台数”“失敗理由（典型パターン）”でまとめる
このテンプレは、環境が変わっても応用が効きます。
6. Automation：運用をワークフロー化し、変更を“手続き”にする
Automation は、運用手順をランブック（Automation runbook）として定義し、実行できる仕組みです。Systems Manager のツール群に Automation が含まれることは公式の概要にも明示されています。:contentReference[oaicite:20]{index=20}
Run Command が「単発または短い一連の操作」だとすると、Automation は「条件分岐や承認、ステップ実行を含む手続き」を得意とします。たとえば、次のような“変更管理”を、手作業ではなく手続きとして残せます。
- 対象ノードの事前チェック → バックアップ/スナップショット → 変更適用 → 事後チェック → 失敗時の通知
- 特定のタグが付いたノードだけに順番に作業する（段階ロールアウト）
- 監査向けに「この手順を実行した」という履歴を残す
運用の成熟度が上がるほど、「人がうまい」より「仕組みが正しい」が重要になります。Automation は、その足場になります。
7. Inventory / Fleet系：台数が増えたときの“把握コスト”を下げる
台数が増えるほど、意外と苦しいのが「現状把握」です。
- どのOSが何台で、どのバージョンか
- どのエージェントが入っているか
- どのパッケージが入っているか
GCP の OS inventory management では、OS Config エージェントがインベントリスキャンを実行し、その情報をメタデータサーバーや OS Config API、ログストリームへ送信すること、そしてこのスキャンが10分ごとに走ることが明記されています。:contentReference[oaicite:21]{index=21}
この発想は、AWSでも「エージェント＋集約＋可視化」で同じ方向を向いています。Systems Manager 側でインベントリやフリート管理を整えると、パッチ運用や脆弱性対応のスピードが上がります。なぜなら、対象が特定できると作業が半分終わるからです。
8. 料金の考え方：多くは追加料金なし、ただし“例外”を先に押さえる
Systems Manager の料金ページでは、機能の大部分は追加料金なしで利用できる一方、料金が発生する機能もあり、例としてジャストインタイムノードアクセス（Just-in-time node access）にはノード時間ベースの料金例が示されています。:contentReference[oaicite:22]{index=22}
また「追加料金はなく、Systems Manager によって作成または集約されたAWSリソースに対して支払う」という説明も、国別レートページに記載があります。:contentReference[oaicite:23]{index=23}
ここは誤解しやすいので、運用上は次のように整理すると安全です。
- Systems Manager を入れること自体で大きな固定費が増える、というよりは、
- 一部の機能（特に高度な統制やオプション）や、
- ログ保管（S3/Logs）、通知、実行に伴う周辺リソース
にコストが寄っていく
つまり、料金より先に「何を統制したいか」「どこまで自動化したいか」を決めて、そこから必要機能を選ぶ方が、コストも説明も安定します。
9. GCP・Azureとの比較：同じ“運用課題”を、どのサービスで解くか
ここからは、Systems Manager を「AWS固有の道具」ではなく、「運用課題を解くレイヤー」として、GCP/Azureに写像します。
9-1. GCP：OS Config（VM Manager）で“パッチとインベントリ”を回す
GCP では、VM Manager（OS Config API）を通じてパッチデプロイを開始し、VM Manager API が対象VM上の OS Config エージェントへパッチ開始を通知する、という流れが公式ドキュメントに書かれています。:contentReference[oaicite:24]{index=24}
また、OSインベントリはエージェントが定期スキャンして情報を送る仕組みで、スキャン周期が10分であることも明記されています。:contentReference[oaicite:25]{index=25}
このため、GCPでは「OS Config を基盤に、パッチ・インベントリ・構成管理を束ねる」という設計が自然です。AWSの Systems Manager と同様、エージェントが現場（VM）に居て、中央が状態を把握し、指示するモデルです。
違いとして理解しておくと良いのは、AWS Systems Manager が「リモートシェル（Session）」「ドキュメント実行（Run Command）」「手続き化（Automation）」など運用全般の道具箱として色が濃いのに対し、GCP側は「VMの保守（パッチ/インベントリ/構成）」の軸が中心になりやすい点です。ここはプロジェクトの運用課題に合わせて、どこまでを中央の仕組みに寄せるかで選択が変わります。
9-2. Azure：Arc + Update Manager で“統合的な更新管理”を作る
Azure Update Manager は、サーバーOSを実行するマシンの更新を管理・統制する統合サービスとして説明されており、Azure・オンプレ・他クラウドのマシン（Azure Arc 接続）まで含めて、Windows/Linuxの更新コンプライアンスを単一の画面で監視でき、リアルタイム更新やメンテナンスウィンドウでのスケジュール更新もできる、と公式に書かれています。:contentReference[oaicite:26]{index=26}
さらに Azure Arc 側には、RDPやSSHで直接ログインせずに、安全にスクリプトやコマンドを実行できる Run command（Arc-enabled servers）があり、個別ログイン不要でソフトウェア更新、FW設定、ヘルスチェック、トラブルシュートなどの管理作業を行える、と説明されています。:contentReference[oaicite:27]{index=27}
そして移行の注意点として、Azure Automation の旧 Update Management は 2024-08-31 で終了し、Azure Update Manager への移行が推奨される、という案内がMicrosoft側で出ています。:contentReference[oaicite:28]{index=28}
このため Azureでは、更新管理は Update Manager を中核に置き、ハイブリッド/マルチクラウドの接続面を Arc が担い、リモート実行は Arc の Run command のような機能で補う、という全体像が描きやすいです。AWSの Systems Manager と同じく「中央で統制し、現場でエージェントが動く」モデルですが、サービスの分割のされ方が少し違う、という理解がしやすいと思います。
9-3. まとめ：比較の“軸”を揃えると、選定が楽になる
クラウドが違っても、運用の論点はかなり共通です。
- パッチをどう回すか（計画・適用・証跡）
- サーバーに入る手段をどう統制するか（鍵、ポート、監査）
- 構成やインベントリをどう把握するか
- 手順をどう再現可能にするか
AWSでは Systems Manager が “運用の箱”として幅広く担い、GCPでは OS Config（VM Manager）が保守の軸を担い、Azureでは Update Manager と Arc を中心に統合していく、という絵が描けます。:contentReference[oaicite:29]{index=29}
10. 導入設計のチェックリスト：最初の1〜2週間で決めたいこと
Systems Manager を「入れただけ」で終わらせないために、最初に合意しておくと効く項目です。
- 公式な運用アクセス経路を決める
- 例：通常運用は Session Manager を正式経路、例外は申請制
- ログの保管先と保持期間を決める
- セッションログを CloudWatch Logs/S3 どちらへ、何日保持するか:contentReference[oaicite:30]{index=30}
- Run Command のドキュメント運用ルール
- “本番で直接コマンド”を禁止し、ドキュメント経由に寄せるのか
- パッチ運用の型
- 月次の定例、緊急対応、メンテナンスウィンドウの設定方針:contentReference[oaicite:31]{index=31}
- 自動化の粒度
- 最初は「調査・収集」から自動化するのか、「変更適用」まで自動化するのか
- 権限設計（最小権限）
- 誰がどの操作をしてよいかを、役割単位で整理する
- 台数増加を見据えたタグ設計
- 対象選択（環境、役割、オーナー、重要度）にタグが効くように整える
この7つを先に決めると、運用の「揉めどころ」がかなり減ります。
11. 誰がどう得をするか（具体的な効果）
11-1. バックエンド開発者の方
- 障害対応で「とりあえず入って確認」が減り、代わりに「決まったドキュメントを実行して、結果を集める」に寄せられます。夜間対応の品質が安定しやすいです。
- 手順がドキュメント化されることで、チーム内レビューが可能になり、属人化を抑えられます。
11-2. SRE/運用担当の方
- アクセス経路の統制と監査ログ整備がやりやすくなり、セキュリティ部門・監査対応の説明材料になります。Session Manager は受信ポートや踏み台なしの安全なアクセスを提供する、と公式に説明されています。:contentReference[oaicite:32]{index=32}
- パッチが「担当者の努力」ではなく「仕組み」で回るようになると、適用漏れが減り、脆弱性対応のリードタイムが短くなります。:contentReference[oaicite:33]{index=33}
11-3. テックリード/アーキテクトの方
- 1台の運用から“フリート運用”へ移るタイミングで、運用レイヤーの統一ができます。
- GCPの OS Config や Azure の Update Manager/Arc と並べて語れるため、将来の移行や併用が必要になったときに、設計思想の再利用がしやすくなります。:contentReference[oaicite:34]{index=34}
12. まとめ：Systems Managerは、運用を「安全に繰り返す」ための基盤
AWS Systems Manager は、AWS・オンプレ・マルチクラウドのノードを、統合コンソールと複数ツールで一元管理する運用基盤です。Run Command、Session Manager、Automation、Patch Manager といった道具が揃い、日々の作業を再現可能にしてくれます。:contentReference[oaicite:35]{index=35}
GCPでは OS Config（VM Manager）がエージェントを通じたパッチとインベントリを担い、Azureでは Update Manager と Arc を中心に、ハイブリッド/マルチクラウドの更新管理とリモート実行を統合していく流れがあります。:contentReference[oaicite:36]{index=36}
最初の一歩としておすすめなのは、次のどれか1つに絞ることです。
- Session Manager を正式な運用経路にする（入口の統制）
- 月次パッチの型を Patch Manager＋メンテナンスウィンドウで回す（継続的な健全性）
- 障害対応の定番コマンドを Run Command ドキュメント化する（再現性のある運用）
小さく始めて、うまく回った型を広げていく。Systems Manager は、その成長の仕方がいちばん美しくハマるサービスだと思います。
参考リンク（公式・一次情報中心）
- AWS Systems Manager とは（公式ドキュメント） :contentReference[oaicite:37]{index=37}
- Session Manager の監査（公式ドキュメント） :contentReference[oaicite:38]{index=38}
- Session Manager のログ設定（公式ドキュメント） :contentReference[oaicite:39]{index=39}
- Patch Manager（公式ドキュメント） :contentReference[oaicite:40]{index=40}
- Systems Manager 料金（公式） :contentReference[oaicite:41]{index=41}
- GCP OS inventory management（公式ドキュメント） :contentReference[oaicite:42]{index=42}
- GCP Patch deployment overview（公式ドキュメント） :contentReference[oaicite:43]{index=43}
- Azure Update Manager 概要（公式ドキュメント） :contentReference[oaicite:44]{index=44}
- Azure Arc: Run command（公式ドキュメント） :contentReference[oaicite:45]{index=45}
- Azure Automation Update Management の終了と移行（Microsoft Tech Community） :contentReference[oaicite:46]{index=46}