AWS Marketplace の購入者を SCP で制限する方法と Private Marketplace の違いを整理してみた

AWS Marketplace の購入者を SCP で制限する方法と Private Marketplace の違いを整理してみた

AWS Marketplace の購入制限には SCP と Private Marketplace という 2 つの方法があります。この記事では、それぞれの違いや使い分けについて整理します。
2026.09.15

はじめに

以前、AWS Organizations の Service Control Policy(サービスコントロールポリシー、以降 SCP)を使って、AWS Marketplace 製品を購入できるユーザーを制限する方法を紹介しました。

https://dev.classmethod.jp/articles/aws-marketplace-subscribe-restriction-scp-iam-identity-center/

この方法では、通常の IAM ロールから実行する aws-marketplace:Subscribe を SCP で拒否し、購入用の許可セットから作成される IAM ロールだけを Deny 対象から除外します。

一方、AWS Marketplace には、組織内で購入可能な製品を承認済みカタログとして管理する Private Marketplace があります。

どちらも AWS Marketplace の購入制限に利用できますが、主に制御する対象が異なります。

  • SCP で購入者を制限する方法
    • どの IAM プリンシパルが購入操作を実行できるか
  • Private Marketplace
    • どの AWS Marketplace 製品を購入できるか

本記事では、この 2 つの方法について、制御対象、適用範囲、ユースケースの違いを整理します。

なお、本記事では分かりやすさのため「購入」と表現しますが、SCP では主に aws-marketplace:Subscribe アクションを制御します。

結論

2 つの方法の違いは以下です。

比較項目 SCP で購入者を制限する方法 Private Marketplace
適用単位 Root、OU、AWS アカウント 組織、OU、AWS アカウント
制御の軸 aws:PrincipalArn で購入用ロールを Deny 対象から除外 Experience で承認する製品
特定ユーザーへの一時的な購入権限付与 向いている 単独では向いていない
製品単位の承認 できない できる
OU や AWS アカウントごとに異なる製品を承認 できない できる
Organizations 管理アカウントへの適用 SCP では制限できない 組織全体を対象にした統制が可能
既存サブスクリプションの利用制限 直接制限しない 制限しない
サブスクライブ済み AMI からの EC2 起動制限 直接制限しない 制限しない

判断の軸は、制御したい対象です。

  • 誰が購入操作を実行できるかを制御する: SCP と IAM 権限
  • 何を購入できるかを制御する: Private Marketplace
  • 両方を制御する: 2 つを組み合わせる

2 つの方法で制御する対象

SCP では購入操作を実行できるロールを限定する

SCP で購入者を制限する方法では、aws-marketplace:Subscribe を実行できる IAM ロールを限定します。

例えば、通常の IAM ロールでは購入できないようにし、購入用の許可セットから作成される IAM ロールだけを SCP の Deny 対象から除外します。

  • 通常の IAM ロール

    • aws-marketplace:Subscribe を拒否
  • 購入用の許可セットから作成される IAM ロール

    • SCP の Deny 対象から除外

購入が必要になった場合は、対象ユーザーと対象 AWS アカウントに購入用の許可セットを割り当てます。

ユーザーが購入を申請

管理者が購入用の許可セットを割り当て

ユーザーが購入用の許可セットでログイン

AWS Marketplace 製品を購入

管理者が許可セットの割り当てを解除

この方法で制御するのは、購入対象の製品ではなく、購入操作を実行する IAM プリンシパルです。

購入用の許可セットから作成された IAM ロールは SCP の Deny 対象から除外されます。許可セット側の IAM ポリシーで aws-marketplace:Subscribe が許可されていれば、AWS Marketplace 製品をサブスクライブできます。

SCP は権限を付与するポリシーではありません。Organizations のメンバーアカウントにある IAM ユーザーや IAM ロールが利用できる権限の上限を定義します。SCP の Deny 対象から除外するだけでは購入できず、IAM ポリシーや許可セットでも購入操作を許可する必要があります。
https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_policies_scps.html

aws-marketplace:Subscribe には、AWS Marketplace 製品のサブスクライブに加えて、サブスクリプション検証が必要な製品へのリクエスト送信や、既存サブスクリプションの自動更新を有効化する操作も含まれます。

https://docs.aws.amazon.com/ja_jp/service-authorization/latest/reference/list_marketplace-agreement.html

なお、SCP は Organizations の管理アカウントには適用されません。管理アカウント内の IAM ユーザーや IAM ロールによる購入操作は、今回の方法では制限できません。

Private Marketplace では購入可能な製品を限定する

Private Marketplace は、承認済みの AWS Marketplace 製品をまとめたカタログを作成し、組織内のユーザーが購入できる製品を制御する機能です。

Private Marketplace では、Private Marketplace Experience(以降、Experience)を作成し、主に以下を設定します。

  • 購入を承認する AWS Marketplace 製品
  • Experience を適用する Audience
  • Experience のステータス

Audience には以下を指定できます。

  • AWS Organizations の組織全体
  • Organizational Unit(OU、組織単位)
  • AWS アカウント

Experience を Live にすると、Audience 内のユーザーは、その Experience で承認された製品だけを購入できます。

OU や AWS アカウントごとに異なる Experience を関連付けることで、購入可能な製品を分けることもできます。

https://docs.aws.amazon.com/ja_jp/marketplace/latest/buyerguide/private-marketplace-concepts.html

例えば、以下のような管理ができます。

開発 OU の Experience
  ├ 製品 A
  ├ 製品 B
  └ 製品 C

本番 OU の Experience
  ├ 製品 A
  └ 製品 B

この場合、開発 OU のユーザーは製品 A、B、C、本番 OU のユーザーは製品 A、B を購入対象として扱えます。

ただし、Private Marketplace は aws-marketplace:Subscribe の IAM 権限を付与する機能ではありません。

製品が Experience で承認されていても、利用する IAM プリンシパルにサブスクライブ権限がなければ購入できません。

AWS Marketplace のサブスクリプション管理用の AWS マネージドポリシーとしては、AWSMarketplaceManageSubscriptions が提供されています。このポリシーには、AWS Marketplace 製品をサブスクライブおよびサブスクライブ解除するための権限が含まれます。

https://docs.aws.amazon.com/ja_jp/marketplace/latest/buyerguide/buyer-security-iam-awsmanpol.html

Private Marketplace と IAM 権限の役割は以下のように分けられます。

  • Private Marketplace

    • その製品を組織として購入対象にしてよいか
  • IAM ポリシーや許可セット

    • その IAM プリンシパルが購入操作を実行してよいか

Private Marketplace の統制対象では、製品が Experience で承認され、かつ利用する IAM プリンシパルにサブスクライブ権限がある場合に購入できます。

製品承認の単位はユーザーではなく Audience

Private Marketplace の Audience は、組織、OU、AWS アカウントを単位として指定します。

IAM Identity Center の特定ユーザーやグループを Audience として直接指定する機能ではありません。

例えば、AWS アカウント 111111111111 に Experience を関連付けた場合を考えます。

AWS アカウント 111111111111
  ├ ユーザー A
  ├ ユーザー B
  └ ユーザー C

Private Marketplace
  → 製品 X を承認

この場合、ユーザー A、B、C は同じ Experience によって統制され、Private Marketplace 上では製品 X が共通して承認済みになります。

実際に製品 X を購入できるかどうかは、それぞれのユーザーが利用する IAM ロールや許可セットの権限にも依存します。

ユーザー A
  ├ 製品 X は承認済み
  └ aws-marketplace:Subscribe が許可されている
      → 購入可能

ユーザー B
  ├ 製品 X は承認済み
  └ aws-marketplace:Subscribe が許可されていない
      → 購入不可

Private Marketplace では、未承認製品についてユーザーが製品購入リクエストを送信することもできます。

管理者がリクエストを承認すると、申請したユーザーだけでなく、その Experience に関連付けられているすべてのユーザーに対して対象製品が承認されます。

https://docs.aws.amazon.com/ja_jp/marketplace/latest/buyerguide/manage-user-requests.html

そのため、以下のような要件では、Private Marketplace 単独よりも SCP で購入者を制限する方法が向いています。

  • 申請したユーザーだけに購入させたい
  • 購入操作が完了したら購入用ロールを利用できない状態にしたい
  • 同じ AWS アカウントを利用する他のユーザーには購入させたくない

反対に、承認した製品を同じ OU や AWS アカウント内で継続的に購入可能にしたい場合は、Private Marketplace が向いています。

既存サブスクリプションの利用は制限しない

どちらの方法も、主に新しいサブスクリプションを制限するものです。

今回の SCP では aws-marketplace:Subscribe を拒否しますが、サブスクライブ済み製品の利用や、その AMI からの EC2 インスタンス起動は直接制限しません。

Private Marketplace も、既存サブスクリプションの利用や、既存サブスクリプションからの新しいインスタンス起動はブロックしません。

https://docs.aws.amazon.com/ja_jp/marketplace/latest/buyerguide/private-marketplace-current.html

サブスクライブ済み AMI からの EC2 インスタンス起動まで制限したい場合は、ec2:RunInstances に対する別の権限制御が必要です。

要件ごとの選び方

要件 向いている方法
購入操作を実行できるユーザーを限定したい SCP と IAM Identity Center の許可セット
組織として承認済みの製品だけを購入可能にしたい Private Marketplace
OU や AWS アカウントごとに購入可能な製品を変えたい Private Marketplace
購入可能な製品と、購入できるユーザーの両方を限定したい Private Marketplace と SCP を組み合わせる
購入済み AMI からの EC2 起動も制限したい 別途 ec2:RunInstances の制御を検討する

判断の軸はシンプルです。

  • 誰が購入できるかを制御したい場合は、SCP と IAM 権限を利用する
  • 何を購入できるかを制御したい場合は、Private Marketplace を利用する
  • 両方を統制したい場合は、2 つを組み合わせる

まとめ

SCP と IAM Identity Center の許可セットを組み合わせる方法は、AWS Marketplace の購入操作を実行できる IAM ロールを限定したい場合に向いています。

Private Marketplace は、組織、OU、AWS アカウントごとに承認済み製品を管理したい場合に向いています。購入者と購入可能な製品の両方を統制したい場合は、両者を組み合わせます。


そのマルチアカウント運用、気合いで支えていませんか

Organizations や Control Tower で土台は作れても、アカウントもポリシーも増えるほど、運用は「詳しい一人」に寄りかかっていく。属人化が限界を迎える前に、組織として回す仕組み=CCoEへ。5,600社の支援から得た立ち上げの型を、無料資料にまとめました。

CCoE総合支援

組織で回す仕組みの資料をもらう

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事