図解が好きな垣見（かきみ）です。

AWS Systems Manager の機能を使って管理ノードに入れるソフトウェアを一括管理できる「Distributor」機能についてイラスト付きでまとめました。

※この記事は「2025 Japan AWS Jr. Champions 夏のQiitaリレー」の41日目の記事です。
最初の記事はこちら↓

どんな時に使う？
Distributor概要
環境・注意点
Distributorの利用手順
応用
おわりに

概要

Systems Manager公式

AWS Systems Manager Distributorとは、 SSMの機能の内ノード管理機能 の一種です。

ソフトウェアをパッケージドキュメントとして管理することで、ソフトウェアを EC2 インスタンスやオンプレミスのサーバーに配布してインストール / アンインストールすることが可能になります。

Run Command や State Manager を使⽤して⼀回限りもしくはスケジュールに従った配付が可能で、複数のOSが異なるインスタンスにおけるソフトウェアのバージョンやライフサイクルを管理できます。

複雑なので図式化しました。全体像のイメージとしてはこんな感じです。
（※後半の実践編で改めて触れます）

また、パッケージドキュメントの定義を他のアカウントに配布することもできます。これにより、組織全体で使うソフトウェアやバージョンを管理することが可能になります。

どんな時に使う？

一度に複数の（OSが異なる）AWS Systems Manager マネージドインスタンスに対して、AWS で公開されたパッケージを含む既存のソフトウェアパッケージをインストール、アンインストール、アップデートしたいとき
AWS Systems Manager のマネージドインスタンスを最新のソフトウェアパッケージで最新の状態に保つ責任がある管理者
Organizations全体で使用するソフトウェアパッケージをそろえたい場合

引用元：

※なお、開発時にチーム内で依存関係にあるソフトウェアを共有できるAWS CodeArtifactとはユースケースが異なるものになります。

AWS CodeArtifactについて詳しくは以下をご覧ください。

手順概要

手順は大きく【パッケージ化】と【実行】に分かれることになります。

①「パッケージ化」について

S3に、ソフトウェアを使えるように特定形式で用意する必要があります。これが「ソフトウェアのパッケージ化」です。

パッケージの種類

ソフトウェアのパッケージ化にはいくつかの方法があります。

もともとAWSがパッケージとして用意しているもの（Amzon所有 / 連携した3rdParty）をそのまま使う方法と、ユーザーが独自に用意して使う方法です。

ここでは後者を扱います。

Amazon所有↓

3rdParty↓

パッケージ化に必要なもの

ユーザーが独自にソフトウェアをパッケージ化するとき、

ソフトウェアファイル（.rpm、.msi、.deb）
インストール・アンインストール（・アップデート[※1]）に使う際のスクリプト（.sh、.ps1）を含むOS別のzipファイル
zipファイルリストやOSとファイルの紐づけを行うマニフェストファイル（.json）

を用意してS3に入れておく必要があります。パッケージ化が済んだらこのS3は消して問題ありません。

※1: アップデートは省略可

パッケージ化の方法

簡単（Simple）な方式・高度（Advanced）な方式があります。

簡単な方式の場合はS3バケットを事前作成し、手元にOSごとのソフトウェアファイルを用意するだけで、あとはSystems Manager側でその他ファイルを用意してくれます。

高度な手順の場合、S3バケットを事前作成し、全ての必要なファイルを自分で用意してバケットに入れておく必要があります。

AWS公式のサンプルパッケージはこちらをクリックするとダウンロード可能です。

基本的に 簡単な方式で可能な場合はそちらの方が楽 かと存じます。複雑なインストールスクリプトを開発してファイルごと管理したい場合などは複雑な方式の方が適する場合もあるかもしれません。

②「実行」について

Run Command （一度きりの手動実行） や State Manager （スケジュール実行） などSystems Managerの機能を使⽤して、各ノードEC2へのソフトウェア管理を行います。

アクションの中身は「①パッケージ化」の段階で用意したパッケージの中身で決まり、対象ノードやログ取得の設定などを行います。

本手順のイメージ

以下のように進めます。

ソフトウェア（Nginx）をパッケージ化する（SSMアカウント）
EC2アカウントへの共有
ノードへのアクション実行（EC2アカウント）
a. 手動実行
b. 自動（スケジュール）実行

本手順では管理組織（Organizations管理アカウントからSSMのサービス委任をしたアカウント。SSMアカウントと呼びます）と利用組織（EC2アカウントと呼びます）の二つのアカウントを用意します。

まずはSSMアカウントでソフトウェアのパッケージを登録し、

そのパッケージをSSMアカウントからEC2アカウントに共有して、

EC2アカウントで対象EC2にソフトウェアのインストールを行います。

補足

先述の「パッケージの種類」で、ソフトウェアのパッケージ化はもともとAWSがパッケージとして用意しているもの（Amzon所有 / 連携した3rdParty）があると述べました。

例えば、New RelicやTrendMicro-CloudOne-WorkloadSecurityなど、AWSと連携した3rdParty製ツールの場合は簡単に配布可能です。

「パッケージ化」が既に終わっているので、以下手順の「3. ノードへのアクション実行（EC2アカウント）」の手順から始まると考えていただければと思います。

New Relicの監視用エージェントにも対応しているようです。
- ※New Relic側の記載
AWS Systems Manager ディストリビューターで、Deep Securityエージェントを自動セットアップ：こちらの手順では、TrendMicro-CloudOne-WorkloadSecurityのエージェントのアップデート自動化の方法を紹介しています。こちらの手順では「c1ws」というタグがついていればエージェントをインストールするように設定していますが必要であれば置き換えてください。

環境・注意点

環境

アカウント
- SSMアカウント：ソフトウェア（今回はNginx）を管理するアカウント。Organizations管理アカウントからSSMのサービス委任をしたアカウント
- EC2アカウント：ソフトウェアがインストールされるEC2インスタンスを保有するアカウント
利用するAWSサービス
- S3（SSMアカウント）
- Systems Manager Distributor（SSMアカウント）
- EC2 インスタンス（EC2アカウント）
- Systems Manager Run Command（EC2アカウント）
- Systems Manager State Manager（EC2アカウント）
EC2 インスタンスの種類
- Amazon Linux 2023（ami-0b6e7ccaa7b93e898）

前提

本手順は以下の環境を前提としています。

ターゲットEC2はSystems Managerのマネージドインスタンス（SSM Agent 2.3.274.0以上）である
配布したいソフトウェア（rpm, deb, msiファイル）の準備（本手順ではNginxとしています）
EC2およびSSMを操作できるAWS IAM権限
SSMのVPCエンドポイント(com.amazonaws..ssm)が各メンバーアカウントにある
S3バケットの作成（SSMを利用するアカウント側）
その他Distrobutor利用の前提について、詳しくは最新の公式情報をご覧ください
- Systems Manager では、Distributor を使用した Oracle Linux マネージドノードへのパッケージの配布は2025/8/13現在サポートされていません。
- Systems Managerコンソール（本手順で記載の手順）ではなくAWS CLIまたはAWS Tools for PowerShellを使用する場合、それぞれの最新リリースをインストールしてください。
S3にディストリビューターのログを出力するには、インスタンスに割り当てられたインスタンスプロファイル (EC2 インスタンスの場合) または IAM サービスロール (ハイブリッドアクティベーションマシン) にS3バケットへの書き込み権限が必要になります。
- さらに、指定された S3 バケットが別の AWS アカウントにある場合には、マネージドノードに関連付けられたインスタンスプロファイルまたは IAM サービスロールにバケットへの書き込みに必要なアクセス許可があることを確認してください。
- （参考：公式 - コンソールを使用したパッケージの 1 回インストールまたは更新）

その他注意事項

今回は Nginx を対象ソフトウェアとします。
また、先述のパッケージ化作業については「高度な方式」ではなく「簡単な方式」で実行します。
AWS アカウントは今回のケースでは2つですが、1つでも3つ以上でも可能です。パッケージのアカウント間共有は必須ではありません。
サポートされているパッケージのプラットフォームとアーキテクチャの情報についてはこちらをご覧ください。

料金

以下はブログ記載時の引用です。
正式には最新ぺージを確認してください。

AWS パッケージ	料金
AWS パッケージ	無料
サードパーティー所有パッケージ	無料

非 AWS パッケージ	料金
ストレージ	1 か月あたり 0.046 USD/GB
Get または Describe API コール	Get または Describe API コール 1,000 回あたり 0.025 USD
データ転送 (リージョン外またはオンプレミスの転送のみ)	ディストリビューターから転送されたデータ 1 GB あたり 0.900 USD

ディストリビューターの料金の例

100 の Amazon EC2 インスタンスと 25 のオンプレミスインスタンスがあり、それぞれ、3 つの AWS パッケージと 100 MB の非 AWS パッケージを毎月更新する必要があるとします。1 日に 2 回更新をチェックした場合、非 AWS パッケージに対して 15,000 の Get/Describe API コールが行われます。

月額料金は以下のようになります。

125 インスタンス間での 3 つの AWS パッケージの配信にかかるコスト = 0 USD
ストレージ: 2 つの非 AWS パッケージの保存にかかるコスト = 2 * 100 MB * 1 GB あたり 0.046 USD = 0.0092 USD
Get、Describe API コール: 15,000 API コールにかかるコスト = 15,000 * API コール 1,000 回あたり 0.025 USD = 0.375 USD
データ転送: 25 のオンプレミスインスタンスでの 2 つの非 AWS パッケージの更新にかかるコスト = 25 * 2 * 100 MB * 1 GB あたり 0.90 USD = 4.50 USD
合計月額コスト = 0.0092 USD + 0.375 USD + 4.50 USD = 4.88 USD またはインスタンスあたり 0.0391 USD

手順

1. ソフトウェアをパッケージ化する（SSMアカウント）

ディストリビューターの利用には、マネージドインスタンスで Systems Manager が実行するアクションを定義する JSON または YAML 形式のドキュメント（SSM ドキュメント）によって対象のソフトウェアを定義する必要があります。

1-1. S3バケットを作成

SSMアカウントに任意の名前の専用S3バケットを作成します。既にある場合は飛ばしてください。

1-2. ソフトウェアファイルの用意

各OSごと、対応する対象ソフトウェアファイルを用意します。

例えばAmazon Linux 2023向けのNginxについてnginx-1.26.3-1.amzn2023.0.1.x86_64.rpmなどを用意します。バージョンは入れたいバージョンを用意してください。

補足

高度な方式の場合、ここで以下が追加で必要になります。

インストール・アンインストールスクリプトを作成
インストール・アンインストールスクリプトとソフトウェアファイルをまとめて対象OSごとにzip化
zipファイル単位でsha256 ハッシュ値チェックサム取得
マニフェストファイル（manifest.json）の作成
1-1で作成したS3バケットに入れる

詳しくはこちらの公式手順を参考にしてください。

1-3. Systems Manager Distributorへ登録

AWS Systems Manager > 左ペイン「ディストリビューター」 > 「パッケージの作成」を選択します。

「簡単」・「高度」のうち 「簡単」 を選びます。
詳細
- 名前：パッケージ名を入力（最大 128 文字）
- バージョン名 - オプション：任意の英数字列（ソフトウェアのバージョンなど、最大 512 文字）
場所：
- Bucket name format：任意
- S3 バケット名/S3 バケットの URL：先ほど作成したS3バケット名を選択または入力してください
  - キープレフィックスも任意で指定可能です

ソフトウェアをアップロード：
- 「ソフトウェアを追加」>ローカルからソフトウェアファイル（rpm、msi、deb）を選択
- プラットフォームのバージョン：指定または「_any」
- ターゲットプラットフォーム：amazon, redhad, centos...などから選択
- アーキテクチャ：x86_64、arm64、364または「_any」...などから選択
スクリプト
- インストールスクリプト：自動で入力されるので必要であればカスタマイズしてください
- アップデートスクリプト（「スクリプトを更新」）：デフォルトではない状態になっているので必要であれば入力してください
- アンインストールスクリプト：自動で入力されるので必要であればカスタマイズしてください

ソフトウェアを追加：違うOSも管理したい場合などはここを押してソフトウェアを追加します。設定内容は先ほどの繰り返しです

マニフェスト
- 「マニフェストを生成」をクリックするとアップロードした情報からマニフェストが生成されます。上記情報を更新するたび再生成が必要になります

「パッケージの作成」を選択します。

終わりました。

「自己所有」のパッケージとして追加されます。

S3バケットにもファイルが自動で追加されています。

なお、エラーステータスがある場合は以下のように追加情報欄に記載されます。

2. EC2アカウントへの共有

このままSSMアカウント上でEC2ノードにスクリプトを実行することもできますが、別アカウントにこのソフトウェアパッケージを共有することもできます。

2-1. 共有

SSMアカウントで作成したパッケージを選択します。

スクロールして「アクセス権限」エリア > 編集を選択します。

共有アカウントID を選択し、（EC2アカウントの）アカウントIDを入力して「追加」を選択 > 保存を押します。
複数入力可能です。

2-2. 確認

EC2アカウントに移動し、AWS Systems Manager > ディストリビューターを選択します。
「自分と共有」というパッケージとして、所有者がSSMアカウントになっているパッケージがあります。

※リージョンごとに管理されるので、SSMアカウントで作ったリージョンで確認してください。

3. ノードへのアクション実行（EC2アカウント）

EC2アカウント側で、共有されたソフトウェアをインストールしていきます。

※ 対象インスタンスが、Systems Manager マネージドインスタンスとなっていることが前提となります。

3-a. 手動実行

AWS Systems Manager > ディストリビューター > 作成したパッケージを選択 > 1回限りのインストールを選択します

ディストリビュータ仕様のRun Command の画面に遷移しますので、必要なパラメータを入力し、実行します。
なお、画面を更新すると入力されている選択が解除される恐れがあります。

コマンドドキュメント
- AWS-ConfigureAWSPackageを使うのはディストリビュータの標準なのでそのままでよいです。

コマンドのパラメータ
- Action：[必須]Install / UnInstall / （Upgrade）
- Installation Type：Uninstall and reinstall / In-place update（何故か二つありましたが一つとして考えて良いです）
- Name：[必須] install/uninstallするパッケージ名。（存在しないパッケージ名だとエラーになるのでデフォルトのままいじらないでください）
- Version：バージョン。指定しない場合は最新バージョンをインストール、また現在のバージョンをアンインストールする
- Additional Arguments： install, uninstall, update スクリプトの追加パラメータ

ターゲット
- インスタンスタグの指定 / インスタンスを手動で選択する / リソースグループの選択

その他のパラメータ
- コメント
- タイムアウト（秒）
レート制御
- 同時実行数
  - ターゲット/割合
- エラーのしきい値
  - エラー数
  - 割合（％）

出力オプション
- コマンド出力のS3バケットへの書き込み（必要な場合事前にS3バケットを作成しておいてください）
- コマンド出力を Amazon CloudWatch Logs に書き込む

CloudWatch alarm設定
SNS通知設定
AWS CLI利用時のコマンド

「実行」をクリックします。

成功するとこんな感じです。

EC2側でもインストールが確認できました。

今回はインストールでしたが、「コマンドのパラメータ」の「Action」でUnInstallを選べば同様にアンインストールできます。

ターゲットインスタンスIDをクリックすると、ログを簡易的に確認することもできます。（こちらは失敗の場合の出力）

3-b. 自動（スケジュール）実行

EC2アカウント > AWS Systems Manager > ディストリビューター > 共有されたパッケージ（nginx）を選択 > スケジュールへのインストールを選択します。

ステートマネージャー（State Manager）の画面に遷移します。
必要なパラメータを入力してください。

名前：何でもいいです
ドキュメント：基本デフォルトのAWS-ConfigureAWSPackageのままにしてください

パラメーター
- 一回限りの実行と同じです。
- Action：[必須]Install / UnInstall / （Upgrade）
- Installation Type：Uninstall and reinstall / In-place update
- Name：[必須] install/uninstallするパッケージ名。（存在しないパッケージ名だとエラーになるのでデフォルトのままいじらないでください）
- Version：バージョン。指定しない場合は最新バージョンをインストール、また現在のバージョンをアンインストールする
- Additional Arguments： install, uninstall, update スクリプトの追加パラメータ

ターゲットの選択
- インスタンスタグの指定 / インスタンスを手動で選択する / リソースグループの選択 / すべてのインスタンスを選択

スケジュールを指定
- スケジュールあり
  - CRONスケジュールビルダー
    - デフォルト30分ごと / 時間単位 / 毎日
  - Rateスケジュールビルダー
    - 毎X分（最小30分） / 時間 / 日
  - CRON/Rata式
- スケジュールなし

詳細オプション
- コンプライアンスの重要度
  - 非常事態 / ミディアム / 高い / 低い
- 変更カレンダー
Rate control

出力オプション
- S3 への書き込み
CloudWatch alarm

「関連付けの作成」を押して実行します。

出来ました。

「実行履歴」から実行結果などを見ることが出来ます。

応用

このディストリビューター機能を用いて、AWSOrganization 内で一元的なパッケージ管理ができる自動化されたソリューションもあります。

運用を考える際はご検討ください。

AWS Systems Manager Distributor と AWS Systems Manager State Manager を使用した一元的なパッケージ管理の自動化

おわりに

Systems Managerには面白い機能がたくさんありますが、なかなか理解が難しいですよね。

本ブログがお役に立てれば幸いです。