AWS Systems Manager（SSM）

2026年3月29日2026年8月4日

AWS Systems Manager（SSM）の特徴

AWS Systems Manager（SSM）は、AWS 内のリソースだけでなく、オンプレミスやマルチクラウド環境でも一元的に表示、管理、および運用できます。SSM は 1つの単独機能ではなく、複数の管理ツールの集合体です。代表的なものに Run Command、Session Manager、Automation、Parameter Store、Patch Manager、State Manager などがあります。

リソースグループごとに運用データを確認できます。
AWS リソースだけではなくオンプレのサーバも管理できます。
各リソースグループをタグごとに管理・仕分けることができます。

Session Manager（セッションマネージャ）

Session Manager は、踏み台サーバーや SSH を使わずに、対象ノードへシェル接続できる機能です。ブラウザ、AWS CLI、または SDK からセッションを開始できます。操作開始・終了は CloudTrail で監査でき、セッション中に実行されたコマンドや出力のログは CloudWatch Logs や S3 に保存できます。これは Session Manager のセッションロギング機能で、CloudWatch Logs または S3 に保存します。Session Manager の設定で有効化できます。

Run Command（ランコマンド）

Run Command は、AWS Systems Manager（SSM）の機能の1つで、EC2などのサーバーに対して SSH/RDPでログインせずに、コマンドをリモート実行できる仕組みです。Run Command はマネージドノードに対して、一般的な管理タスクや一時的な設定変更を安全にリモート実行するための Systems Manager の機能です。

Parameter Store（パラメーターストア）

パラメーターストアは、正式には AWS Systems Manager Parameter Store で、アプリケーションやサーバーが使う設定値・接続情報・パスワードなどを、AWS上で一元管理するための仕組みです。

アプリケーションにはこういう設定値がよくあります。これらをアプリケーションのコード内に直接書くと危険です。

DB_HOST=aurora-cluster.xxxxx.ap-northeast-1.rds.amazonaws.com
DB_PORT=3306
DB_NAME=app_db
DB_USER=app_user
DB_PASSWORD=xxxxxxxx
ENV=prod

そこで、パラメーターストアを利用して以下のようにします。

SSM Parameter Store
  ├─ /prod/app/db/host
  ├─ /prod/app/db/name
  ├─ /prod/app/db/user
  ├─ /prod/app/db/password
  └─ /prod/app/api/endpoint

アプリケーション側は、必要なときに AWS API 経由で必要なパラメーター（値）を取得します。

パラメーターの種類

パラメーターには以下の3種類があります。

String　通常の文字列　暗号化なし
StringList　カンマ区切りの文字列リスト　暗号化なし
SecureString　パスワード・APIキーなどの機密値　KMSで暗号化あり

SecureString とは

SecureString は、Parameter Store に保存する値を AWS KMS で暗号化するタイプです。

使う対象は、例えば以下です。

DBパスワード
APIキー
外部サービスのトークン
ライセンスキー
秘密情報

Parameter Store は、SecureString パラメータを作成または変更する際に、AWS KMS keys を使用してそのパラメータ値を暗号化します。また、アクセス時に KMS キーを使用してパラメータ値を復号します。Parameter Store がアカウント用に作成した AWS マネージドキーを使用することも、独自のカスタマーマネージドキーを指定することもできます。

System Manager OpsCenter

OpsCenterでは、問題やインシデントを OpsItem として管理します。OpsItem には、影響リソース、関連イベント、優先度、ステータス、対応履歴、関連する Automation ランブックなどを紐づけられます。OpsCenter は運用担当者が AWS リソースに関する作業項目を表示・調査・解決するための中央の場所とになります。

たとえば、Security Hub や GuardDuty、Inspector などで検出された問題を OpsItem として集約し、担当者がそこから対応を開始するイメージです。

Systems Manager Automation

Systems Manager Automation で定例作業を自動化できます。

Amazon EC2 インスタンスおよび他の AWS リソースの一般的なメンテナンス（パッチの適用やアップデートなど）を自動化できます。

自動化のカスタムワークフローを作成することも可能で、あらかじめ AWS によって用意された定義済みのワークフローを使用することもできます。

Amazon CloudWatch Events を使用して自動化タスクおよびワークフローに関する通知を受信します。
AWS Systems Manager 管理画面より自動化の進捗状況および実行の詳細を監視します。
Systems Manager オートメーションドキュメントは、オートメーションワークフロー（Systems Manager がマネージドインスタンスおよび AWS リソースで実行するアクション）を定義します。
自動化には、いくつかの自動化ドキュメントが事前に定義されており、1 つ以上のAmazon EC2 インスタンスの再起動や、Amazon マシンイメージ (AMI) の作成といった一般的なタスクを実行する際に使用することができます。

Patch Manager

Patch Manager は、セキュリティ関連のアップデートと他のタイプのアップデートの両方でマネージドインスタンスのオペレーティングシステムとアプリケーションの両方にパッチを適用するプロセスを自動化します。

承認済みパッチおよび拒否済みパッチのリストに加え、リリースから数日以内にパッチを自動承認するためのルールを含むパッチベースラインを使用します。

パッチ適用を Systems Manager メンテナンスウィンドウタスクとして実行するようスケジュールすることで、パッチを定期的にインストールできます。

全体像

SSM Patch Manager の処理は、次のように分けると理解しやすいです。

① パッチベースライン
   「どのパッチをインストール対象として承認するか」

② 実行方法
   Patch Now / メンテナンスウィンドウ / パッチポリシー
   「いつ・どのインスタンスに実行するか」

③ AWS-RunPatchBaseline
   実際にスキャン・インストールするSSMドキュメント

④ OSの更新機能
   Windows Update / YUM / DNF / APT など

⑤ 結果
   実行ログ、パッチコンプライアンス、成功・失敗状態

Patch Manager 自体が独自にパッチファイルをインストールするのではありません。Windows では Windows Update API、Linux では YUM・DNF・APT など、各OSの標準的なパッケージ管理機能を呼び出します。

パッチベースラインとは

パッチベースラインは、簡単にいうと、そのサーバーに対して、どのパッチを「インストールしてよい」と判断するかを定義したルールです。

ベースラインでは、主に次を設定します。

対象OS
Product
Classification
Severity
自動承認までの日数
明示的に承認するパッチ
明示的に拒否するパッチ
コンプライアンス報告時の重要度

パッチベースラインそのものには、実行日時や対象インスタンスは設定しません。あくまで「パッチ選定ルール」です。

AWS定義済みベースライン

AWS が OS ごとに用意しているベースラインです。

例えば Amazon Linux 2 の定義済みベースラインは、概ね次のようなルールです。

Security 分類
Severity が Critical または Important
Bugfix 分類
リリースまたは更新から7日後に自動承認

Windows Server のデフォルトベースラインも、CriticalUpdates や SecurityUpdates のうち、Critical または Important のものを原則7日後に承認します。定義済みベースラインは直接変更できません。

カスタムベースライン

自社でルールを作るベースラインです。

例えば次のように設定できます。

OS         : Windows Server
Product    : WindowsServer2022
分類       : SecurityUpdates, CriticalUpdates
重要度     : Critical, Important
自動承認   : リリースから7日後

本番環境で適用対象を細かく制御したい場合は、通常カスタムベースラインを作成します。

どのベースラインが使用されるのか

Patch NowやAWS-RunPatchBaselineを実行すると、Patch Managerは次の順序でベースラインを決定します。

対象ノードにパッチグループがある
    ↓ Yes
パッチグループに関連付けたベースラインを使用

    ↓ No
対象OSのデフォルトベースラインを使用

例えば、Windows Serverのインスタンスにパッチグループが設定されていなければ、Windows用のデフォルトパッチベースラインが使用されます。

したがって、カスタムベースラインを作成しただけでは使用されない場合があります。

OSのデフォルトベースラインにする
パッチグループと関連付ける

のどちらかが必要です。

AWS-RunPatchBaselineとは

AWS-RunPatchBaseline は、AWS Systems Manager が用意しているAWS 管理の SSMドキュメントです。

対象サーバーを調査し、パッチベースラインのルールに従って、パッチのスキャンまたはインストールを実行する処理手順です。

Linux、macOS、Windows Server のマネージドノードに対応しています。

自動承認とは

ここは非常に重要です。

自動承認は、自動インストールではありません。

自動承認とは、そのパッチを、Patch Manager がインストール対象として選択してよい状態にするという意味です。

例えば次の設定があったとします。

分類             : SecurityUpdates
Severity         : Critical
自動承認までの日数 : 7日

8月1日にリリースされた Critical のセキュリティパッチは、原則として8月8日に「承認済み」になります。

しかし、8月8日に自動でインストールされるわけではありません。

実際のインストールには、別途次のいずれかが必要です。

Patch Nowを実行する
メンテナンスウィンドウを設定する
Quick Setupのパッチポリシーを設定する
Run CommandでAWS-RunPatchBaselineを実行する

つまり、次の関係です。

自動承認
＝インストール対象として許可する

スケジュール・Patch Now
＝実際にスキャンまたはインストールする

自動承認までの日数は0～360日で設定できます。パッチが途中で更新された場合、更新日を基準に待機期間が再計算されることがあります。

自動承認の2種類

指定日数後に承認

リリースまたは最終更新から7日後

定期運用向きです。

例えば、開発環境では1日後、本番環境では7日後という段階的な設定ができます。

指定日以前のパッチを承認

2026年7月31日以前にリリース・更新されたパッチだけを承認

こちらは承認範囲を特定の日付で固定したい場合に使います。

8月以降に新しいパッチが公開されても、自動的には承認対象になりません。検証済みの時点でパッチセットを固定したい場合に向いています。