AWS Systems Manager (SSM)

AWS Systems Manager は、EC2 インスタンス、オンプレミスサーバー、エッジデバイス、マルチクラウド上のサーバーを、管理対象ノードとして一元的に運用するためのサービスです。SSM Agent を通じてノードと Systems Manager が通信し、リモート接続、コマンド実行、パッチ適用、設定値管理、運用手順の自動化を行います。

SAA では、Systems Manager を単独の監視サービスとして覚えるよりも、EC2 を安全に運用するための設計部品として理解することが重要です。特に、踏み台サーバーや SSH/RDP のインバウンド開放を避ける Session Manager、フリートに対する一括操作を行う Run Command、アプリケーション設定を外部化する Parameter Store、パッチ適用を自動化する Patch Manager がよく出ます。

Point

• SSM = Systems Manager の略として使われます。
• 以前の名称に Simple Systems Manager や EC2 Systems Manager があり、CLI コマンドや IAM ポリシー、リソース名では今でも ssm という名前がよく出ます。
• 試験では「SSM Agent が入っていて、IAM ロールとネットワーク到達性がある EC2 を管理するサービス」と考えると整理しやすいです。
• 和訳
  • System: 仕組み、システム
  • Manager: 管理者、管理するもの
  • Weblio英和辞書「manager」

---

概要

Systems Manager の中心は、管理対象ノードです。EC2 インスタンスやオンプレミスサーバーに SSM Agent がインストールされ、ノード側から Systems Manager のエンドポイントへ通信できる状態になると、AWS 側から安全に運用操作を実行できます。多くの Amazon Linux AMI や Windows Server AMI では SSM Agent が事前に入っていますが、権限とネットワーク経路がなければ管理対象にはなりません。

SAA では「プライベートサブネットの EC2 に安全に接続したい」「複数インスタンスへ同じコマンドを実行したい」「設定値や AMI ID をアプリケーションから参照したい」「OS パッチ適用を管理したい」という問題文で登場しやすいです。Security Group で SSH を開ける、踏み台サーバーを増やす、手作業で各インスタンスへログインする、といった選択肢より、Systems Manager を選ぶ場面が多くあります。

観点	SAA での判断
接続	Session Manager でインバウンドポートなしに接続します。
一括操作	Run Command で複数ノードにコマンドを実行します。
設定値	Parameter Store で階層的に管理し、IAM と KMS で保護します。
パッチ	Patch Manager でスキャン、適用、コンプライアンス確認を行います。
自動化	Automation や State Manager で定型運用を標準化します。

Systems Manager は可用性を直接高めるロードバランサーではありません。アプリケーションの冗長化は Auto Scaling、ELB、マルチ AZ 配置などで行い、Systems Manager はその環境を安全かつ一貫して運用する役割を持ちます。

---

主要技術

①管理対象ノード、SSM Agent、IAM ロール

Systems Manager を使うには、対象ノードが管理対象ノードとして認識される必要があります。EC2 の場合は、SSM Agent、インスタンスプロファイルの IAM ロール、Systems Manager エンドポイントへのアウトバウンド通信が基本要件です。代表的な IAM 管理ポリシーは AmazonSSMManagedInstanceCore です。

必要なもの	役割	試験での見方
SSM Agent	ノード側で Systems Manager と通信するエージェント	古い AMI やカスタム AMI では導入状況を確認します。
IAM ロール	EC2 が Systems Manager に登録・通信する権限	ユーザー権限だけでなくインスタンス側の権限も必要です。
ネットワーク経路	SSM API へのアウトバウンド通信	プライベートサブネットでは NAT Gateway または VPC エンドポイントを検討します。
タグ	対象ノードのグルーピング	Run Command や Patch Manager の対象選択に使えます。

プライベートサブネットの EC2 でインターネットへ出したくない場合は、AWS PrivateLink の VPC エンドポイントを使います。代表的には Systems Manager 用の ssm、Session Manager のメッセージ通信用の ssmmessages、古い互換性や一部機能で使われる ec2messages、ログや暗号化を使う場合の CloudWatch Logs、S3、KMS などを検討します。

⚠️頻出: 「プライベートサブネットの EC2 に SSH したいが、パブリック IP や踏み台を置きたくない」という要件では、Session Manager を使います。ただし、SSM Agent、IAM ロール、アウトバウンド通信または VPC エンドポイントがそろっていないと接続できません。

---

②Session Manager

Session Manager は、管理対象ノードへブラウザや AWS CLI から対話的に接続する機能です。SSH キー、RDP の公開、踏み台サーバーを管理せずに、IAM で接続権限を制御できます。接続履歴や API 操作は CloudTrail に残り、セッションログは設定により CloudWatch Logs や S3 に出力できます。

比較	Session Manager	踏み台サーバー / SSH
インバウンドポート	原則不要	SSH/RDP の許可が必要になりやすい
認可	IAM ポリシーで制御	OS ユーザー、鍵、踏み台の管理が必要
監査	CloudTrail、CloudWatch Logs、S3 と連携	自前でログ設計が必要
運用負荷	踏み台や鍵配布を減らせる	鍵ローテーションや踏み台保守が必要

Session Manager はセキュリティ要件が強い設計で有効です。特定ユーザーだけ本番インスタンスに接続させる、接続操作を監査する、インスタンスをプライベートサブネットに置いたまま保守する、といった場面で選びます。

一方で、ネットワーク到達性をすべて不要にする魔法ではありません。管理対象ノードから Systems Manager へ通信できる必要があります。NAT Gateway を使うか、VPC エンドポイントを構成するかは、セキュリティ要件とコストで判断します。

Point

• Session は「接続して作業する一続きの時間」という意味です。
• Session Manager は「サーバーにログインする経路」を AWS 管理の仕組みに寄せる機能です。
• SSH の鍵を配る代わりに IAM で誰がどのノードへ接続できるかを制御します。
• 和訳
  • Session: 会期、一定時間の作業
  • Weblio英和辞書「session」

⚠️頻出: 「SSH ポート 22 を閉じたい」「踏み台を廃止したい」「プライベートサブネットの EC2 に管理者が接続したい」は Session Manager を疑います。

---

③Run Command、Automation、State Manager

Run Command は、管理対象ノードに対してリモートでコマンドを実行する機能です。1 台ずつログインせず、タグやリソースグループを使って複数ノードへ同じ操作を行えます。アプリケーションのインストール、ログ収集、設定変更、簡単な修復操作に向きます。

Automation は、AWS リソースに対する定型作業をランブックとして実行する機能です。例えば、AMI 作成、EC2 の再起動、パッチ手順、障害時の復旧操作などを手順化できます。State Manager は、ノードが望ましい状態を保つように関連付けを定期実行する機能です。

機能	主な用途	判断ポイント
Run Command	今すぐコマンドを実行	一回限りの一括操作、ログ収集、設定変更
Automation	手順化された運用作業を実行	複数ステップの定型作業、承認、復旧ランブック
State Manager	望ましい状態を維持	定期的な設定適用、エージェント導入、構成維持
Maintenance Windows	実行時間帯を制御	本番影響を避けるため、夜間や保守時間に実行

Run Command は便利ですが、結果は分散システムとして扱われるため、直後の状態確認で反映が遅れる可能性があります。また、大量ノードへ一斉実行すると影響が大きいため、同時実行数やエラーしきい値を設定して安全に展開します。

⚠️頻出: 「複数 EC2 に同じコマンドを実行」「ログをまとめて取得」「OS 設定を一括変更」は Run Command です。「複数ステップの復旧手順を標準化」は Automation、「定期的に状態を維持」は State Manager と切り分けます。

---

④Parameter Store

Parameter Store は、アプリケーション設定値や非ローテーションの秘密情報を階層的に保存し、IAM でアクセス制御する機能です。値の種類には String、StringList、SecureString があります。SecureString は AWS KMS で暗号化できます。

用途	選ぶサービス	理由
環境名、エンドポイント、AMI ID、非機密の設定	Parameter Store	階層名、バージョン、IAM 制御で扱いやすい
KMS で暗号化した軽量な設定値	Parameter Store SecureString	ローテーション不要の値に向きます。
DB パスワードや API キーを自動ローテーションしたい	AWS Secrets Manager	シークレットのライフサイクル管理に向きます。
段階的な機能設定やロールバックをしたい	AWS AppConfig	動的設定、検証、段階的デプロイに向きます。

Parameter Store は CloudFormation、Lambda、ECS、CodeBuild などから参照できます。例えば /prod/app/db/endpoint や /dev/app/log-level のように階層化すると、環境やアプリケーション単位で権限を分けやすくなります。

標準パラメータは多くの一般的な用途に向きます。より大きい値、より多いパラメータ、パラメータポリシー、クロスアカウント共有などが必要な場合は Advanced tier を検討します。Advanced tier や高スループット設定では追加料金が発生するため、コスト要件も確認します。

Point

• Parameter は「設定値」や「変数」と考えると理解しやすいです。
• SecureString は KMS で暗号化された値です。
• ただし、シークレットの自動ローテーションが主目的なら Secrets Manager を選びます。
• 和訳
  • Parameter: パラメータ、変数、条件
  • Secret: 秘密
  • Weblio英和辞書「parameter」

⚠️頻出: 「AMI ID をハードコードしたくない」「環境ごとの設定値を中央管理したい」は Parameter Store です。「DB 認証情報を自動ローテーションしたい」は Secrets Manager が優先です。

---

⑤Patch Manager と運用コンプライアンス

Patch Manager は、管理対象ノードの OS や一部アプリケーションのパッチ適用を自動化する機能です。パッチベースラインで、どの分類や重要度のパッチを承認するかを定義し、スキャンだけ行うか、スキャンしてインストールまで行うかを選べます。

構成要素	役割	SAA での注意
Patch baseline	承認するパッチの条件を定義	セキュリティ分類、重要度、承認までの日数などを考えます。
Patch policy	組織やリージョン横断のパッチ設定	マルチアカウントで一元管理したい場面に向きます。
Maintenance Window	実行時間帯を指定	本番影響を抑えるために使います。
Compliance	パッチ適用状況の確認	「準拠」は定義したベースラインに対する状態です。

Patch Manager はパッチ適用を自動化しますが、AWS がすべてのパッチを事前検証してくれるわけではありません。また、OS のメジャーバージョンアップを行う用途でもありません。試験では、セキュリティパッチを大規模に適用する、メンテナンス時間帯に実行する、準拠状況を確認する、といった問題文で選びます。

⚠️頻出: 「フリート全体にセキュリティパッチを適用」「パッチ準拠状況を確認」「保守時間帯に実行」は Patch Manager と Maintenance Windows の組み合わせです。

---

⑥他サービスとの連携と設計パターン

Systems Manager は、多くの AWS サービスと組み合わせて使います。SAA では、単体機能よりもアーキテクチャ上の組み合わせが問われます。

要件	組み合わせ	判断ポイント
プライベート EC2 に管理接続	Session Manager + VPC Endpoint	インバウンドなし、NAT なしでも設計できます。
セッション監査	Session Manager + CloudTrail + CloudWatch Logs / S3	誰が接続したか、何を実行したかを追跡します。
設定値参照	Parameter Store + IAM + KMS	アプリケーションから安全に設定を取得します。
パッチ運用	Patch Manager + Maintenance Windows + Tags	対象と時間帯を制御します。
障害対応手順	Automation + EventBridge	イベントを契機にランブックを起動できます。
EC2 起動設定	Parameter Store public parameters	最新 AMI ID を参照してハードコードを避けます。

プライベートサブネットで Systems Manager を使う設計では、通信経路の設計が重要です。NAT Gateway は広い外向き通信に使いやすい一方、VPC エンドポイントは AWS サービスへのプライベート接続を作れます。セキュリティ要件が強く、インターネット経由を避けたい場合は VPC エンドポイントを選ぶ設計が出やすいです。

⚠️頻出: Systems Manager は「EC2 が外から見えるようにするサービス」ではありません。ノード側から Systems Manager へ通信できるようにし、IAM で操作権限を与えることで、安全な運用操作を実現します。

---

試験対策

SAA では、Systems Manager は EC2 運用の安全性と自動化を問う文脈で出ます。問題文に「踏み台サーバーを避けたい」「インバウンドポートを開けたくない」「複数インスタンスへ一括実行したい」「プライベートサブネットの EC2 を管理したい」「設定値をハードコードしたくない」「OS パッチを自動化したい」とあれば、Systems Manager の機能を候補に入れます。

問題文のキーワード	優先して考える機能	理由
SSH/RDP を開けたくない	Session Manager	インバウンドポートや踏み台を減らせます。
プライベート EC2 に接続	Session Manager + VPC Endpoint	インターネットに出さずに管理できます。
複数ノードにコマンド	Run Command	タグなどで対象を指定して一括実行できます。
定型復旧手順	Automation	ランブックで運用手順を標準化できます。
設定値、AMI ID、環境変数	Parameter Store	階層管理、バージョン、IAM 制御が使えます。
DB パスワードのローテーション	Secrets Manager	Parameter Store よりシークレット管理に特化します。
パッチ適用と準拠確認	Patch Manager	スキャン、適用、コンプライアンス確認を扱います。

よくある誤答は、接続要件に対して踏み台サーバーを追加する選択肢です。踏み台は従来型の設計として成立する場合もありますが、「運用負荷を減らす」「インバウンドを閉じる」「IAM で統制する」「監査ログを AWS サービスに集約する」といった条件がある場合は、Session Manager がより適切です。

Parameter Store と Secrets Manager の比較も頻出です。単純な設定値や AMI ID、非ローテーションの暗号化値であれば Parameter Store が候補です。認証情報の自動ローテーション、専用のシークレット管理、より細かいシークレットライフサイクルが求められる場合は Secrets Manager を選びます。

Patch Manager では、パッチを当てるだけでなく、パッチベースライン、保守時間帯、スキャン結果、準拠状況をセットで考えます。「OS のメジャーバージョンアップ」や「アプリケーションの高可用性化」を直接行うものではないため、問題文の目的を確認します。

最後に、Systems Manager が動かない原因も試験で問われます。SSM Agent がない、インスタンスプロファイルに権限がない、プライベートサブネットから SSM エンドポイントへ到達できない、KMS 復号権限がない、CloudWatch Logs や S3 へのログ出力権限がない、といった切り分けを覚えておくと選択肢を消しやすくなります。

---

参考文献

• What is AWS Systems Manager? - AWS Systems Manager
• AWS Systems Manager Session Manager
• AWS Systems Manager Run Command
• AWS Systems Manager Parameter Store
• AWS Systems Manager Patch Manager
• AWS Systems Manager Automation
• AWS Certified Solutions Architect - Associate