---
title: "AWS Systems Manager（SSM）とは？機能一覧・料金・Session Managerの使いどころ"
url: "https://www.issoh.co.jp/tech/details/3145/"
published: 2024-07-25
updated: 2026-07-27
categories: ["AWS"]
publisher: "株式会社一創"
---

# AWS Systems Manager（SSM）とは？機能一覧・料金・Session Managerの使いどころ

AWS Systems Manager は、EC2 インスタンスやオンプレミスのサーバーを、SSH の鍵配布も踏み台サーバーも使わずに一元管理するためのサービス群です。名前が示すほど輪郭がはっきりしないのは、Session Manager や Patch Manager といった性格の違う機能が20以上ぶら下がった「傘」だからで、検索でも「SSM」「System Manager」「SystemManager」と表記が割れます（いずれも同じ AWS Systems Manager を指します）。そして2026年6月30日、オンプレミスや他クラウドのサーバーを管理するときの料金体系が構造ごと変わりました。

## まとめ：AWS Systems Managerの要点

- Systems Manager は単一機能ではなく、ノード／変更管理／アプリケーション／運用の4カテゴリに分かれたツール群。旧称 Amazon Simple Systems Manager と Amazon EC2 Systems Manager の名残で略称は SSM。
- EC2 インスタンスに対しては、Session Manager・Run Command・Patch Manager・State Manager・Inventory・Fleet Manager などの主要機能に追加料金がかからない。
- 課金されるのは Parameter Store の Advanced パラメータ、Automation のステップ実行、OpsCenter、Incident Manager など。「SSM は無料」と丸めると見積りを外す。
- 2026年6月30日に advanced-instances tier が廃止され、ハイブリッド／マルチクラウドノードの1,000台上限とノード単位課金が消えた。代わりに2026年9月30日から、それらのノードでの Session Manager が1セッション0.05USD、Run Command が1呼び出し0.002USD の従量課金になる。
- Session Manager のセッションログは、ポートフォワーディングと SSH 経由の接続では記録されない。監査要件がある環境ではここが穴になる。

## AWS Systems Managerの正体｜20以上のツールを束ねる傘サービス

### SSMという略称の由来とマネージドノードの定義

AWS Systems Manager は、公式ドキュメントに「以前は Amazon Simple Systems Manager (SSM) および Amazon EC2 Systems Manager (SSM) と呼ばれていました」と記載されているとおり、旧称の頭文字が現在も略称・API 名・エージェント名（`amazon-ssm-agent`）に残っています。検索で見かける「SSM」「AWS SSM」「システムマネージャー」はすべて同じサービスです。

Systems Manager の操作対象は**マネージドノード**と呼ばれ、EC2 インスタンス、自社データセンターのオンプレミスサーバー、AWS IoT Greengrass コアデバイス、AWS IoT および AWS 以外のエッジデバイス、他クラウド環境を含む仮想マシンが該当します。EC2 以外をハイブリッドアクティベーションで登録すると、コンソール上でノード ID が `mi-` で始まります。ここが Systems Manager を「EC2 の管理ツール」と誤解しやすい点で、実際にはオンプレミスや他クラウドの Linux／Windows も同じ操作画面に載せられます。

### Systems Managerが置き換える運用作業

従来のサーバー運用では、踏み台サーバーの維持、SSH 鍵の配布と棚卸し、パッチ適用スクリプトの実行、設定ファイルの配布がそれぞれ別の仕組みで動いていました。Systems Manager はこれを、SSM Agent と AWS API の経路に集約します。インバウンドのポート開放が不要になるため、EC2 のセキュリティグループから22番・3389番の許可を落とせるのが実務上いちばん大きい変化です。

ノードが Systems Manager の管理下に入っているかは、AWS Config のマネージドルール `ec2-instance-managed-by-systems-manager` で継続的に評価できます。ルールベースで統制する方法は[AWS Configとは？設定変更の記録・ルール評価・料金の考え方と導入判断を実装者目線で解説【2026年時点】](/tech/details/15616/)で扱っています。

## 機能一覧と、やりたいことからの選び方

### 公式の4カテゴリと主な機能

公式ドキュメントは Systems Manager のツールを次の4カテゴリに分類しています。名前だけ見ても用途が読めない機能が多いため、カテゴリごとに押さえるのが近道です。

| カテゴリ        | 主なツール                                                                                                                                     | 役割                         |
| ----------- | ----------------------------------------------------------------------------------------------------------------------------------------- | -------------------------- |
| ノードツール      | Fleet Manager / Session Manager / Run Command / Patch Manager / State Manager / Inventory / Compliance / Distributor / Hybrid Activations | ノードへの接続・コマンド実行・パッチ適用・状態維持  |
| 変更管理ツール     | Automation / Change Manager / Change Calendar / Maintenance Windows / Quick Setup / Documents                                             | 作業の自動化・承認フロー・実施可能時間帯の統制    |
| アプリケーションツール | Parameter Store / AppConfig / Application Manager                                                                                         | 設定値と機能フラグの保管・配信、リソースの一覧管理  |
| 運用ツール       | OpsCenter / Explorer / Incident Manager / CloudWatch Dashboards（2026年4月30日で終了）                                                            | 運用作業項目の集約、ダッシュボード、インシデント対応 |

この一覧には期限付きの項目が2つ混ざっています。運用ツールの CloudWatch Dashboard は、公式ドキュメントの告知どおり**2026年4月30日以降は利用できません**。ダッシュボードの作成・閲覧は Amazon CloudWatch コンソール側に一本化されました。変更管理ツールの Change Manager も、**2025年11月7日以降は新規顧客の受け付けを終了**しています。既存利用者は継続できますが、これから承認フローを組むなら別の手段を選ぶ必要があります。2024年以前に公開された解説記事はどちらも現役として載せているため、機能一覧をそのまま引き写さないでください。

### 用途から引く早見表

「サーバーに入りたい」「一斉にコマンドを流したい」といった目的から逆引きすると、選ぶべき機能は絞れます。

| やりたいこと          | 使う機能                                | EC2         | ハイブリッドノード（2026年9月30日〜） |
| --------------- | ----------------------------------- | ----------- | ---------------------- |
| 踏み台なしでシェルに入る    | Session Manager                     | 追加料金なし      | 0.05 USD／セッション         |
| 複数ノードへ一斉にコマンド実行 | Run Command                         | 追加料金なし      | 0.002 USD／呼び出し         |
| OSパッチを定期適用する    | Patch Manager + Maintenance Windows | 追加料金なし      | 追加料金なし                 |
| 設定を定義した状態に保つ    | State Manager                       | 追加料金なし      | 追加料金なし                 |
| 導入ソフトの棚卸し       | Inventory / Compliance              | 追加料金なし      | 追加料金なし                 |
| DB接続情報やAPIキーを保管 | Parameter Store                     | Standardは無料 | Standardは無料            |
| 復旧手順をワークフロー化    | Automation                          | ステップ課金      | ステップ課金                 |
| ソフトウェアパッケージを配布  | Distributor                         | ストレージ課金     | ストレージ課金                |
| 作業申請と承認を回す      | Change Manager（新規受付終了）              | 課金あり        | 課金あり                   |

まず着手するなら Session Manager と Patch Manager の2つです。Session Manager は EC2 に対して追加料金がかからないうえ、踏み台サーバー1台分の EC2 稼働費と、22番インバウンドの許可・SSH 鍵の配布という運用そのものを同時に落とせます。Patch Manager は Maintenance Windows と組めば適用作業が手から離れます。Parameter Store の設計方針（Standard と Advanced の使い分け、Secrets Manager との住み分け）は[パラメータストアとは？AWS Parameter Storeの料金・使い方・Secrets Managerとの違いを解説](/tech/details/3412/)に切り出しています。

## Session Manager：接続の仕組みとログの落とし穴

### 接続に必要な3つの前提

Session Manager でノードに接続するには、対象ノードで SSM Agent が動作していること、ノードに Systems Manager 権限を持つ IAM ロール（EC2 ではインスタンスプロファイル、オンプレミスや他クラウドではハイブリッドアクティベーション）が割り当たっていること、そして SSM のエンドポイントへ到達できることの3点が揃っている必要があります。プライベートサブネットに置いた EC2 でも、NAT ゲートウェイ経由か、`ssm`・`ssmmessages`・`ec2messages` の VPC エンドポイントを用意すれば接続できます。インバウンドの穴を開けずにシェルへ入れるのは、この経路がすべてアウトバウンド起点だからです。

ノードがコンソールに出てこないときは、リージョンの取り違えとエンドポイント疎通の2つを先に疑うと切り分けが早く済みます。接続が切れたノードは `Connection Lost` の状態が30日続くと Fleet Manager コンソールの一覧から表示されなくなり、原因を解消すれば一覧に戻せます。

エージェント側の導入手順、プリインストール済み AMI の範囲、ノードが管理対象に出てこないときの切り分けは[SSM Agentとは？できること・インストール・踏み台不要のSession Manager接続まで](/tech/details/1467/)で詳しく扱っています。IAM ロールとポリシーの設計そのものに迷う場合は[AWS IAMとは？仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティスを実装者目線で解説](/tech/details/15427/)を参照してください。

### セッションログが残らない条件

Session Manager はセッション中に入力したコマンドとその出力を、Amazon S3 と Amazon CloudWatch Logs に記録できます。CloudWatch Logs にはセッション中の逐次ストリーミングも可能で、Systems Manager コンソールからは**過去30日間の接続レポート**を生成できます。「誰がいつどのノードに入ったか」の監査証跡は、この機能で取ります。

ただし公式ドキュメントは明確な例外を挙げています。**ポートフォワーディングまたは SSH 経由で接続した Session Manager のセッションでは、ログが記録されません**。AWS CLI と Session Manager エンドポイントの間に確立された TLS 接続の内側で全データが暗号化され、Session Manager はトンネルとしてしか機能しないためです。RDS へのポートフォワーディングや、SSH over Session Manager を常用している環境では、操作ログが一切残らないまま「Session Manager にしたから監査できている」と誤認しがちです。この経路を使うなら、記録はノード側の auditd や SSH のログで別途確保してください。

Linux と macOS のノードでは、`screen` ユーティリティが入っていないとログデータが切り詰められます。Amazon Linux 2、AL2023、Ubuntu Server は既定で導入済みですが、RHEL などでは手動が必要です。ディストリビューションに応じてどちらか一方を実行してください。

```
sudo yum install screen
```

```
sudo apt-get install screen
```

ログにパスワードなどの機密文字列を残さないための入力方法も、ドキュメントで推奨されています。セッション中に機密データを打つ場面では、Linux と macOS では次のコマンドを使います。

```
stty -echo; read passwd; stty echo;
```

Windows では PowerShell の以下を使います。

```
$Passwd = Read-Host -AsSecureString
```

なお Windows Server 2012 以前のノードはログの整形が最適化されず、Windows Server 2012 R2 以降が推奨されます。macOS インスタンスについては、Systems Manager がサポートする機能はファイルシステムの表示のみです。

### セッション中の操作を起点にした後続アクションの自動実行

セッションログを有効にすると、Amazon SNS 通知の生成に加えて、セッション中に行われた操作を起点として AWS Lambda 関数の実行、AWS CodePipeline のパイプライン開始、Run Command ドキュメントの実行といった後続アクションを自動的に走らせられます。ログインそのものを検知したい場合は、CloudTrail に記録される `StartSession` を Amazon EventBridge のルールで拾う構成にします。ログを後から grep する運用にすると気づくのが遅れるため、通知側に寄せるのが実務的です。

## 料金：無料の範囲と、実際に課金される部分

### EC2なら主要機能は追加料金なし

EC2 インスタンスに対する Run Command、Session Manager、State Manager、Fleet Manager、Patch Manager、Inventory、Compliance、Application Manager、Maintenance Windows の利用には、追加料金がかかりません。踏み台サーバーの EC2 費用と運用工数がそのまま浮くため、Session Manager への移行はコスト面でも判断が早い部類です。

一方で課金される機能は次のとおりです（米ドル建て。リージョンで異なるため、見積り時は公式の料金ページで確認してください）。

| 機能                            | 課金単位           | 単価          |
| ----------------------------- | -------------- | ----------- |
| Parameter Store（Advanced）     | パラメータ1件・1か月    | 0.05 USD    |
| Parameter Store API           | インタラクション1万回    | 0.05 USD    |
| Automation                    | 1ステップ          | 0.002 USD   |
| Automation（aws:executeScript） | 1秒             | 0.00003 USD |
| OpsCenter                     | OpsItem 1,000個 | 2.97 USD    |
| OpsCenter API                 | リクエスト1,000件    | 0.039 USD   |
| Distributor                   | ストレージ 1GB・1か月  | 0.046 USD   |
| Incident Manager              | 応答計画1件・1か月     | 7 USD       |

金額が効いてくるのは Parameter Store の Advanced と Automation です。Advanced は1パラメータあたり月0.05USD なので、環境ごとに数百件を Advanced で持つと無視できない額になります。Advanced が必要になるのは、値のサイズが Standard の上限4KB を超える場合か、パラメータポリシーで有効期限を管理したい場合です（Advanced の上限は8KB）。どちらにも当てはまらないなら Standard のままにしてください。

### 2026年のハイブリッドノード料金改定

オンプレミスや他クラウドのサーバーを管理する場合の料金は、2026年に構造ごと変わりました。2024年以前に公開された解説記事は、いずれも改定前の前提で書かれています。

| 時期               | ハイブリッド／マルチクラウドノードの扱い                                        |
| ---------------- | ----------------------------------------------------------- |
| 〜2026年6月29日      | advanced-instances tier（有料）が必要。ハイブリッドノードは1,000台上限           |
| 2026年6月30日〜9月29日 | tier廃止。登録数の上限なし・登録料なし。Session ManagerとRun Commandの利用も課金されない |
| 2026年9月30日〜      | Session Manager 0.05 USD／セッション、Run Command 0.002 USD／呼び出し   |

2026年6月30日に advanced-instances tier が廃止され、非 EC2 マシンで Session Manager を使うために有料階層を有効化する必要はなくなりました。ハイブリッドマネージドノードの1,000インスタンス制限も同時に撤廃されています。代わりに9月30日から従量課金が始まり、公式の試算例では、ハイブリッドノード200台に対して各ノード月4回の Run Command 呼び出しと1回の Session Manager セッションを実行した場合、合計11.60USD です。EC2 インスタンスでの利用には引き続き追加料金がかかりません。

公式の料金ページは、この移行期間中はハイブリッド／マルチクラウドノードでの Session Manager と Run Command の利用が課金されないと明記しています。オンプレミスサーバーの Systems Manager 登録を検討しているなら、2026年9月29日までに接続性と権限まわりを検証しておくと、費用を発生させずに評価を終えられます。

## Systems Managerに寄せないほうがよい4つの条件

Systems Manager は万能ではありません。次のいずれかに当てはまるなら、全面移行は避けたほうが確実です。EC2 側のネットワーク設計から見直す場合は[AWS環境構築の手順｜VPC・EC2・IAM・セキュリティグループの初期設計を解説](/tech/details/15359/)もあわせて確認してください。

- **操作ログの完全な保全が監査要件になっていて、接続手段がポートフォワーディングや SSH 経由に限られる環境**。前述のとおりこの経路のセッションはログが残らず、要件を満たせません。ノード側での記録が前提になります。
- **macOS を本格運用している環境**。サポートされる機能がファイルシステムの表示のみのため、Linux／Windows と同じ運用は成立しません。
- **Ansible や Chef で構成管理が回っており、冪等性のあるコードとテストが資産になっている場合**。Run Command と State Manager に置き換えても管理対象が増えるだけで、得られるのは実行基盤の差分に留まります。接続手段だけ Session Manager にして、構成管理は残す形が現実的です。
- **2026年9月30日以降、ハイブリッドノードで対話セッションを1日に何度も張る運用**。1セッション0.05USD は少数なら誤差ですが、100台で毎日2セッションなら月300USD になります。Run Command での非対話実行に寄せるほうが安くなります。

逆に、EC2 中心の環境で踏み台サーバーを維持している状態は、Session Manager へ移す判断が最も明快です。追加料金がなく、22番ポートのインバウンド許可と鍵の配布運用を同時に廃止できます。

## よくある質問

### AWS Systems Managerとは何ですか？

EC2 インスタンス、オンプレミスサーバー、他クラウドの仮想マシン、エッジデバイスを一元的に運用管理するための AWS のサービス群です。単一機能ではなく、ノードツール・変更管理ツール・アプリケーションツール・運用ツールの4カテゴリに20以上のツールが含まれます。旧称 Amazon Simple Systems Manager／Amazon EC2 Systems Manager の名残で SSM と略されます。

### AWS Systems Managerの料金はいくらですか？

EC2 インスタンスに対する Session Manager、Run Command、Patch Manager、State Manager、Fleet Manager、Inventory などの利用は追加料金なしです。課金対象は Parameter Store の Advanced パラメータ（1件あたり月0.05USD）、Automation のステップ実行（1ステップ0.002USD）、OpsCenter（OpsItem 1,000個あたり2.97USD）、Incident Manager（応答計画1件あたり月7USD）などです。単価はリージョンで異なるため、公式の料金ページで確認してください。

### AWS Systems Manager Session Managerとは？

ブラウザまたは AWS CLI から、マネージドノードのシェルに接続できる機能です。通信がすべてノード側からのアウトバウンドで完結するため、踏み台サーバー、インバウンドの22番・3389番の開放、SSH 鍵の配布がいずれも不要になります。接続できるユーザーの制御は IAM、API 呼び出しの記録は CloudTrail が担い、セッション中の操作は S3 や CloudWatch Logs に記録できます。

### ハイブリッド環境のサーバーもSystems Managerで管理できますか？

できます。ハイブリッドアクティベーションで登録すると、オンプレミスサーバーや他クラウドの仮想マシンが `mi-` で始まる ID のマネージドノードとして扱われます。2026年6月30日に advanced-instances tier が廃止され、登録台数の上限（従来1,000台）とノード単位の課金はなくなりました。2026年9月30日からは、これらのノードでの Session Manager が1セッション0.05USD、Run Command が1呼び出し0.002USD の従量課金になります。

### Session Managerのセッションログはどこに保存されますか？

Amazon S3 と Amazon CloudWatch Logs を出力先に指定できます。CloudWatch Logs にはセッション中のストリーミング出力も可能で、コンソールからは過去30日間の接続レポートを生成できます。ただしポートフォワーディングと SSH 経由の接続ではログが記録されません。また Linux／macOS では `screen` が未導入だとログが切り詰められます。

## 関連記事

- [SSM Agentとは？できること・インストール・踏み台不要のSession Manager接続まで](/tech/details/1467/)
- [パラメータストアとは？AWS Parameter Storeの料金・使い方・Secrets Managerとの違いを解説](/tech/details/3412/)
- [AWS IAMとは？仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティスを実装者目線で解説](/tech/details/15427/)
- [AWS Configとは？設定変更の記録・ルール評価・料金の考え方と導入判断を実装者目線で解説【2026年時点】](/tech/details/15616/)
- [AWS Control Towerとは？マルチアカウント統制の仕組みと導入判断](/tech/details/15623/)

---

出典: [AWS Systems Manager（SSM）とは？機能一覧・料金・Session Managerの使いどころ](<https://www.issoh.co.jp/tech/details/3145/>)（株式会社一創）
