AWS RAM を使った AWS Organization 全体への Systems Manager ドキュメント共有

本記事は 2026 年 10 月 1 日に公開された “Share Systems Manager documents across your AWS Organization with AWS RAM” を翻訳したものです。

はじめに

Automation ランブックや Run Command ドキュメントといった AWS Systems Manager (SSM) ドキュメントを AWS Organization 全体で運用している場合、どのアカウントがそれらを実行できるかを決める必要があります。これまでは、ModifyDocumentPermission API を使って、ドキュメントごとに個々のアカウント ID のリストを指定して共有するしかありませんでした。この API で指定できるのは 1 ドキュメントあたり最大 1,000 アカウント ID（1 回の呼び出しでは 20 件）です。新しいアカウントをプロビジョニングしたり、組織単位 (OU) の構成を変更したりするたびに、誰かが手作業でそのリストを更新しなければなりませんでした。アカウント数が増えるほど、この保守作業も増えていきます。

AWS Systems Manager は、AWS Resource Access Manager (AWS RAM) を通じて組織全体または特定の OU に SSM ドキュメントを共有できるようになりました。リソース共有を作成してドキュメントを追加し、共有先となる組織または OU を選択します。アカウントが組織に参加したり組織から外れたりしても、共有の状態は自動的に同期されます。アカウント ID 単位ではなく組織構造単位でアクセスを管理できるようになり、アカウントごとの共有リストを維持する必要はなくなります。

今回のリリースで何が変わるかを、次の表にまとめます。

項目	変更前（アカウント ID による共有）	変更後（AWS RAM による共有）
共有先	個々のアカウント ID	組織、OU、または個々のアカウント
アカウント数の上限	1 ドキュメントあたり 1,000	1 リソース共有あたり最大 5,000 プリンシパル
メンバー構成の変更	手作業での更新が必要	組織 / OU のメンバー構成と自動で同期
組織外への共有	招待の仕組みなし	組織外のアカウントには AWS RAM の招待が必要
コスト	無料	無料

このブログでは、この共有モデルの仕組みを説明し、エンドツーエンドの例を通して手順を追い、大規模環境でこのパターンを運用するためのベストプラクティスを紹介します。

前提条件

このブログの例をそのまま試すには、次のものが必要です。

少なくとも 2 つのアカウントを持つ AWS Organization（中央アカウントと、OU 内のメンバーアカウント 1 つ）
AWS RAM で AWS Organizations とのリソース共有が有効になっていること（初回のみの設定作業です。AWS RAM ユーザーガイドの AWS Organizations 内でリソース共有を有効にするを参照してください）
中央アカウントで SSM ドキュメントと AWS RAM リソース共有を作成するための IAM 権限
SSM ドキュメント（Automation 型および Run Command 型）に関する基本的な知識

AWS RAM および SSM ドキュメントの共有に追加料金はかかりません。

AWS RAM によるドキュメント共有の仕組み

次の図は、SSM ドキュメントが所有元のアカウントから組織内のメンバーアカウントへ渡り、それらのアカウントで実行されるまでの流れを示しています。図のあとに続く番号付きの手順で、各段階を説明します。

アーキテクチャ図。AWS Organization の中で、1 つの AWS アカウントが SSM ドキュメントを保持し、そこから組織単位の AWS RAM 共有を作成する。その共有は組織内の 2 つのメンバーアカウントにつながり、各アカウントは共有された SSM ドキュメントを Systems Manager Automation または Run Command で実行する。

図 1. ドキュメントを所有するアカウントが、SSM ドキュメントを組織単位の AWS RAM リソース共有で共有し、組織内のメンバーアカウントが Automation または Run Command でその共有ドキュメントを実行する。

AWS RAM リソース共有を作成する。ドキュメントを所有するアカウントで、AWS RAM コンソールまたは CLI からリソース共有を作成します。このアカウントは、組織の管理アカウントや委任管理者である必要はありません。単に SSM ドキュメントを作成・所有しているアカウントでかまいません。管理アカウントまたは RAM の委任管理者で行う必要があるのは、前提条件に挙げた「AWS Organizations とのリソース共有の有効化」だけです。
SSM ドキュメントを追加する。1 つ以上の SSM ドキュメントをリソース共有に追加します。
マネージドアクセス許可 (managed permission) をアタッチする。AWS RAM は、共有されたドキュメントに対して利用側アカウントが実行できるアクションを定義したマネージドアクセス許可をアタッチします。既定では AWSRAMPermissionSsmDocument がアタッチされます。許可するアクションを絞り込みたい場合は、別のマネージドアクセス許可をアタッチするか、カスタマーマネージドアクセス許可を作成できます。
プリンシパルを選択する。ドキュメントの共有先として、組織全体、特定の OU、または個々のアカウントを選びます。
アクセスが許可される。組織内のアカウントであれば、アクセスは即座に有効になります。組織外のアカウントの場合は、利用側がまず AWS RAM の招待を承諾します。

共有されたドキュメントのすべてのバージョンが共有先のアカウントから利用できるため、バージョニングのために追加で設定することはありません。既定では、利用側はドキュメントの既定バージョンを実行し、新しい既定バージョンを公開すればその変更が自動的に反映されます。利用側は、実行時にバージョン番号を指定して特定のバージョンを実行することもできます。

# Create a resource share
aws ram create-resource-share \
  --name "central-ops-ssm-documents" \
  --principals "arn:aws:organizations::111111111111:ou/o-exampleorg/ou-ab12-workloads" \
  --resource-arns "arn:aws:ssm:us-east-1:222222222222:document/SSM-Automation-AD-Join" \
  --region us-east-1

--permission-arns を省略すると、AWS RAM が既定のマネージドアクセス許可 AWSRAMPermissionSsmDocument を自動でアタッチします。共有されると、メンバーアカウントは完全な ARN を指定してそのドキュメントを検出し、実行できるようになります。

ウォークスルー: 中央管理の Active Directory ドメイン参加ランブックの共有

Windows の EC2 インスタンスを Active Directory (AD) ドメインに参加させるのは、日常的な運用作業です。過去の 2 つのブログ、Simplifying Active Directory domain join with AWS Systems Manager と Event-driven Active Directory domain join with Amazon EventBridge では、1 つの Automation ランブックで、手動・スケジュール・イベントのいずれかによってインスタンスをドメインに参加（または離脱）させる方法を紹介しました。この例では、そのランブックをさらに一歩進めます。各アカウントにランブックをコピーするのではなく、中央のチームが一度だけ作成し、AWS RAM 経由でメンバーアカウントに共有します。ノードをドメインに参加させる必要のあるアカウントは、共有されたランブックを ARN で指定して実行し、保守すべきランブックは 1 つだけになります。

シナリオ

中央の ID 管理チームが、関連ブログで紹介した AD ドメイン参加ランブックを所有しています。このランブックは、対象インスタンスが Windows であることを確認し、Join か Unjoin の指定に応じて処理を分岐させ、コンピューターをドメインに追加する、または削除する PowerShell を実行し、結果をインスタンスにタグ付けして、再起動または停止します。このチームは以前、このランブックを 300 を超えるアカウント ID と共有し、組織に変更があるたびにリストを更新していました。AWS RAM による共有を使えば、Workloads OU に一度共有するだけで、その OU に現在属しているアカウントと今後追加されるアカウントのすべてがランブックを実行できます。

このランブックは、ssm-automation-custom-ad-domain-join-unjoin リポジトリで CloudFormation テンプレートとして公開されています。このテンプレートを中央アカウントにデプロイして、ランブック（この例では SSM-Automation-AD-Join という名前にします）と、AD の認証情報を保持する Secrets Manager のシークレットを作成します。

このランブックは、対象インスタンスにアタッチされたインスタンスプロファイルを使って Secrets Manager から AD の認証情報を読み取ります。共有されたランブックを実行する各メンバーアカウントでは、インスタンスにインスタンスプロファイルを設定しておく必要があります。ドメイン名・参加用アカウント・対象 OU を保持するシークレットへのアクセス権限が必要です。ランブックを共有してもこれらの認証情報は共有されないため、各アカウントが自分の AD シークレットにどう到達するかは別途設計してください。

AWS RAM でのランブックの共有

コンソールの場合:

中央アカウントで AWS RAM コンソールを開きます。
リソース共有を作成を選びます。
Name に名前を入力します（例: platform-ad-join-docs）。
リソースでリソースタイプとして SSM Documents を選び、SSM-Automation-AD-Join ランブックを選択します。
次へを選びます。
マネージド型アクセス許可では、既定の AWSRAMPermissionSsmDocument のままにします。利用側アカウントが実行できるアクションを絞り込みたい場合は、別のマネージド型アクセス許可を選びます。
次へを選びます。
プリンシパルにアクセス権限を付与するで、次の操作を行います。
1. プリンシパルで自分の組織内でのみ共有を許可を選びます。
2. プリンシパルタイプの選択で組織単位 (OU) を選びます。
3. ドキュメントの共有先となる OU ID を入力します。
4. 追加を選び、次へを選びます。
確認と作成で内容を確認し、リソース共有を作成を選びます。

AWS CLI の場合:

# Create a resource share
aws ram create-resource-share \
  --name "platform-ad-join-docs" \
  --resource-arns "arn:aws:ssm:us-east-1:222222222222:document/SSM-Automation-AD-Join" \
  --permission-arns "arn:aws:ram::aws:permission/AWSRAMPermissionSsmDocument" \
  --principals "arn:aws:organizations::111111111111:ou/o-exampleorg/ou-ab12-workloads" \
  --region us-east-1

--permission-arns 引数は省略可能です。省略した場合、AWS RAM が AWSRAMPermissionSsmDocument を自動でアタッチします。

CloudFormation の例:

Resources:
  ADJoinDocumentShare:
    Type: AWS::RAM::ResourceShare
    Properties:
      Name: platform-ad-join-docs
      AllowExternalPrincipals: false
      Principals:
        - arn:aws:organizations::111111111111:ou/o-exampleorg/ou-ab12-workloads
      ResourceArns:
        - !Sub arn:aws:ssm:${AWS::Region}:${AWS::AccountId}:document/SSM-Automation-AD-Join

CloudFormation を使えば、リソース共有を Infrastructure as Code として管理し、SSM ドキュメントと一緒にバージョン管理できます。

メンバーアカウントからのランブック実行

オンデマンドで実行する場合: Workloads OU 内のいずれかのメンバーアカウントから、ランブックの完全な ARN を指定し、DomainJoinActivity に Join を設定して、テスト用の Windows インスタンスをドメインに参加させます。

aws ssm start-automation-execution \
  --document-name "arn:aws:ssm:us-east-1:222222222222:document/SSM-Automation-AD-Join" \
  --parameters "InstanceId=i-0abc123def456,DomainJoinActivity=Join,AutomationAssumeRole=arn:aws:iam::333333333333:role/SSMAutomationRole" \
  --region us-east-1

ランブックはインスタンスが Windows であることを確認し、ドメインに参加させ、ADJoined=Join-complete のタグを付けて、インスタンスを再起動します。

起動時に自動実行する場合: コマンドを手作業で実行せず、インスタンスの起動に合わせてドメイン参加を行えます。共有したランブックを Event-driven Active Directory domain join with Amazon EventBridge のイベント駆動パターンと組み合わせます。メンバーアカウント側で EventBridge ルールを作成し、新しいインスタンスが running 状態になったときに共有ランブックを ARN で起動します。

ベストプラクティス

大規模環境で SSM ドキュメントを共有するための指針（バージョニング、ガバナンスのガードレール、移行を含む）は、AWS Systems Manager ユーザーガイドの Best practices for shared SSM documents を参照してください。

従来の共有方式からの移行

すでに ModifyDocumentPermission でアカウント ID のリストを指定してドキュメントを共有している場合も、最初からやり直す必要はありません。Systems Manager コンソールには移行をガイドする機能があり、既存の共有ドキュメントを AWS RAM リソース共有に変換できます。すでにそのドキュメントを利用しているアカウントのアクセスは中断されません。移行後は共有が組織の状態と同期して保たれ、アカウント ID のリストを保守していたスクリプトは廃止できます。手順の詳細は、AWS Systems Manager ユーザーガイドの Migrate an existing shared document to AWS RAM を参照してください。

クリーンアップ

ランブックの共有を停止するには、リソース共有からランブックを削除します。

aws ram disassociate-resource-share \
  --resource-share-arn "arn:aws:ram:us-east-1:222222222222:resource-share/abc123" \
  --resource-arns "arn:aws:ssm:us-east-1:222222222222:document/SSM-Automation-AD-Join"

リソース共有からランブックを削除すると、メンバーアカウントはその ARN を参照する実行を開始できなくなります。共有ランブックを対象にしている利用側アカウントの EventBridge ルールやスケジュールされたタスクは、次回の実行で失敗します。

サンプルの CloudFormation テンプレートからランブックをデプロイした場合は、ランブック、Secrets Manager のシークレット、およびそのスタックが作成した IAM リソースを削除するため、中央アカウントでそのスタックを削除してください。スタック削除時に共有ランブックが参照されていない状態にするため、先にリソース共有を削除してください。CloudFormation コンソールで対象のスタックを選んで削除を選ぶか、次のコマンドを実行します（スタック名は実際に使用したものに置き換えてください）。

aws cloudformation delete-stack \
  --stack-name SSM-Automation-Demo \
  --region us-east-1

まとめ

AWS RAM を通じて SSM ドキュメントを共有すれば、アカウントごとの共有リストを管理する運用上の負担がなくなります。このパターンは、初期セットアップ、パッチ適用、インシデント対応、構成を定めた通りに保つ運用など、あらゆる運用ユースケースに適用できます。中央アカウントで一度作成し、AWS RAM で組織または OU に共有し、メンバーアカウントは ARN を指定してそのドキュメントを実行する、という形です。

Simplifying Active Directory domain join with AWS Systems Manager と Event-driven Active Directory domain join with Amazon EventBridge と併せて読むことで、全体像がつながります。ドメイン参加ランブックを一度作成し、AWS RAM で組織全体に共有し、任意のメンバーアカウントから ARN で実行する、という流れです。

ぜひ試してみてください。すでに環境で使っているカスタム SSM ドキュメントや Automation ランブックを 1 つ選び、AWS RAM でサンドボックス用の OU に共有して、メンバーアカウントから完全な ARN を指定して実行してみましょう。そのアカウントにコピーを保持しなくてもドキュメントを実行できることを確認したら、現在チームで共有している残りのドキュメントにも同じパターンを広げてください。

著者について

Erik Weber

AWS Cloud Operations サービスの Sr. World-wide Specialist Solutions Architect。AWS Systems Manager、AWS Config、AWS CloudTrail、AWS Audit Manager を専門としています。仕事以外では、ハイキング、料理、サイクリングに情熱を注いでいます。

Ali Alzand

AWS の Senior Infrastructure Migration & Modernization Specialist Solutions Architect で、エンタープライズのお客様が Microsoft ワークロードを AWS に移行・モダナイズし、運用できるよう支援しています。Infrastructure as Code と、AWS Systems Manager、EC2 Image Builder、AWS CloudFormation を使った大規模な自動化を専門としています。また、Amazon EventBridge と AWS Lambda を使い、応答性が高く疎結合なイベント駆動アーキテクチャを設計しています。仕事以外では、友人とのバーベキューや、街で新しい料理を見つけることを楽しんでいます。

Daniel Liu

AWS の Sr. Technical Product Manager で、AWS Systems Manager を専門としています。お客様が大規模なクラウド運用をより簡単かつ安全に自動化できるようにすることに注力しています。仕事以外では、旅行、釣り、テニスを楽しんでいます。

Luis Rodriguez Montilla

AWS の Cloud Operations の Senior Specialist Solutions Architect で、クラウドプラットフォームエンジニアリングに 10 年以上携わってきました。AWS の大規模なグローバル企業のお客様が、ガバナンスとオブザーバビリティの課題を大規模な環境で解決できるよう支援しています。仕事以外では旅行とスポーツが好きで、空いた時間は家族や友人と過ごしています。

Yonghui Min

Amazon Web Services (AWS) の Software Development Manager で、AWS Systems Manager 内のチームを率いています。スケーラブルなクラウド管理ソリューションの構築に情熱を持ち、お客様が AWS 環境全体で運用ワークフローを簡素化・自動化できるよう支援することに注力しています。

翻訳はソリューションアーキテクトの村田が担当しました。

Amazon Web Services ブログ