AWS以外のSaaSもAWS Marketplaceに出品できる？掲載条件とDeployed on AWS

「うちのSaaSはAzureで動いているので、AWS Marketplaceには載せられない」と、社内で判断してしまっていないでしょうか。以前は、その判断が正しい場面がありました。AWSは2025年2月25日の発表で、2025年5月1日から、SaaS製品の一部がAWS上で動いている必要があるという従来の要件をなくし、ホスティング先を問わず掲載を受け付けると案内しました。（AWS Marketplace Blog）2025年5月1日以降のガイドラインにも、すべてのSaaSアーキテクチャを公開できると書かれています。（SaaS製品のガイドライン）

ただ、そこから「AWS以外でも同じように載る」と読むと、半分しか合っていません。AWS上で完結する製品には「Deployed on AWS」という特別な表示が付き、その条件は掲載の条件とは別に定められています。（SaaS製品のガイドライン）さらに、表示の有無が購入者のAWS支出コミットの消化にどう関わるかは、SaaS製品のガイドラインには書かれていません。コミットの消化そのものの考え方と確認の進め方は、AWS Marketplaceでのコミット消化の確認で扱います。

本記事の内容は、2026年10月5日に確認したAWSの公式ドキュメントと発表にもとづきます。購入者のコミット消化に関する記述は、2026年10月28日に再確認しています。AWSの外部の記事に頼る箇所は、その旨を明記して区別しています。仕様は変わることがあるため、判断の前には各出典で最新の内容を確認してください。

掲載できるかと表示を受けられるかは別の問い

自社の構成について確かめたいことは三つに分かれ、判定の軸もそれぞれ違います。

掲載できるかについては、「はい」と答えられます。一方、Deployed on AWSの表示を受けられるかは自社の構成を、購入者のコミット消化に数えられるかは購入者の契約条件を、それぞれ確認しないと答えが出ません。

2025年5月1日に変わったこと

変更の中身は、掲載できる製品の範囲です。AWSのブログによると、対象はAWS上のSaaSに加えて、他のクラウドやオンプレミスで動くSaaSにも広がりました。Deployed on AWSの表示は、2025年5月1日から製品詳細ページに出ています。（AWS Marketplace Blog）

ガイドラインの該当部分には、この基準が2025年5月1日から有効だという注記があります。（SaaS製品のガイドライン）範囲が広がっても、審査が緩んだわけではありません。実際、ガイドラインの冒頭には、提出時に基準を満たすか審査し、公開後も継続して確認すると書かれています。基準から外れた製品は、問題が解消されるまで新規の購読者に一時的に提供されなくなることがあります。（SaaS製品のガイドライン）

ホスティング先を問わない掲載条件

販売者に求められる条件

ホスティング先が他のクラウドでも、販売者はAWSアカウントを保有している必要があります。有料製品を売るには、対象の国と地域に居住するか法人として設立されていること、税務情報の登録、米ドルを受け取れる銀行口座の情報の登録が要ります。（販売者の資格要件）求められた場合は、口座の検証も完了させる必要があります。（口座の検証）日本は対象の国と地域に含まれています。（販売者の資格要件）登録から公開までの全体の流れは、AWS MarketplaceにSaaSを出品する方法で整理しています。

SaaS製品のガイドラインが定める条件

ガイドラインは、すべてのSaaS製品に次の条件を課しています。ホスティング先による例外の記載はありません。（SaaS製品のガイドライン）

• 料金は、AWS Marketplaceに設定した料金ディメンションだけで請求します。クレジットカードや銀行口座の情報を、販売者が顧客から集めることはできません
• 登録ページには、購入者のメールアドレスの入力欄を設けます
• 購入後に、顧客がSaaS内でアカウントを作り、Webコンソールにアクセスできるようにします。SaaS内のアカウントを作成済みの顧客は、フルフィルメントのランディングページ（購入後に遷移するページ）からログインできるようにします
• 顧客が、SaaS内で契約や利用の状況を確認できるようにします
• 顧客のデータを保存時も通信時も業界標準の暗号化で守り、顧客ごとにデータと環境を分離します
• 顧客データを処理する場合は、セキュリティに関わるイベントの監査ログを有効にし、1年以上保管して改ざんから守ります
• 製品とその掲載情報（メタデータ）に、利用者を他のクラウドプラットフォームや、AWS Marketplaceで提供していない製品、アップセル、無料トライアルへ誘導する文言を入れません

他のクラウドで動かすSaaSでも、暗号化やデータ分離はそのクラウド側の設計で満たすことになります。ホスティング先を記載することと、他のクラウドへ誘導することは別で、条件が禁じているのは後者です。なお、これらの条件は、Deployed on AWSの表示の有無にかかわらず同じです。

他のクラウドのSaaSに必要な連携機能

ガイドラインは、料金モデルごとに呼び出すAPIを定めています。APIは、販売者として登録し、SaaSの公開を申請したAWSアカウントから呼び出す必要があります。（SaaS製品のガイドライン）

購入や解約の通知は、Amazon EventBridgeで受け取ります。イベントはdefault event bus（デフォルトのイベントバス）に届き、target（イベントの送り先）の例にはAWS Lambdaの関数、AWS Step Functions、Amazon API Gatewayといったサービスが挙がっています。（Amazon EventBridgeによるSaaSイベント管理）

2026年10月5日時点では、ガイドラインとAmazon EventBridgeのページに、他のクラウドからの受け取り方の記載はなく、以下は筆者の読みです。契約イベントは販売者のAWSアカウントのdefault event busに届くため、そのイベントを他のクラウドの環境へ転送する仕組みが要ります。APIは販売者登録したAWSアカウントの権限で呼び出すため、他のクラウドからそのアカウントの権限をどう使うかを設計に含める必要があります。その実装の全体像は、AWS MarketplaceのSaaS連携に必要な実装で扱っています。

加えて、2026年6月1日以降に新規掲載するSaaSには、同じアカウントの複数契約に対応するConcurrent Agreementsの対応も必須とされているため、契約の識別を設計に含めておく必要があります。（AWSの発表）詳細は、AWS MarketplaceのConcurrent Agreementsとは？で整理しています。

Deployed on AWSの条件

両プレーンがAWS上で動くこと

ガイドラインによると、Deployed on AWSの製品は、検索結果と製品詳細ページで特別な表示を受けます。その対象と見なされるには、製品がアプリケーションもコントロールプレーンも含めて、すべてAWS上で動く必要があります。（SaaS製品のガイドライン）

二つのプレーンは、AWSのSaaSアーキテクチャの解説で区別されています。アプリケーションプレーンは、テナントが触れるアプリケーションと、その業務ロジックを担う層です。コントロールプレーンは、テナントのオンボーディング、認証、管理、運用、分析といった機能を担う層です。（SaaS Architecture Fundamentals）このホワイトペーパーは、ページの冒頭で過去の資料として参照用に残されていると断っています。概念の定義を借りる分には足りますが、自社の分類に迷ったら、ガイドラインの構成図の書き方（後述）に合わせて整理してください。

構成ごとの見立て

ガイドラインには、AWS上で動く範囲についての条件が細かく書かれています。（SaaS製品のガイドライン）次の表は、その文言をもとに、構成ごとにDeployed on AWSの条件との関係を整理したものです。ただし、AWS Marketplaceが最終的に判断するのは、提出した構成図の内容です。

ここでいうアプリケーションデータは、購入者に属するデータ、または購入者のために生成されるデータを指します。

購入者のAWSアカウントにリソースを配置する構成

アプリケーションプレーンを購入者のAWSアカウントに配置する構成は、掲載できる一方で、追加の条件があります。ガイドラインが挙げる主なものは次のとおりです。（SaaS製品のガイドライン）

• コントロールプレーンは、販売者が管理するインフラ上に配置します。マネージドサービスではなくSaaSとして扱われるための条件です
• 購入者のAWS Marketplaceの取引とは別に、AWSのインフラ料金が発生し得ることを、製品の説明で購入者に伝えます
• AWS Security Token Service（AWS STS）やAWS Identity and Access Management（IAM）などで、安全にリソースを用意します。権限は最小権限の原則に従って付与します
• 用意するAWSサービスとAWS IAMポリシーを説明する文書と、購入者がリソースを展開するための手順またはテンプレートを提供します

AWS CloudFormationのテンプレートを使う場合は、SaaS Quick Launchの方法で、SaaSの掲載と一緒に公開します。購入者の環境にAmazon Machine Image（AMI）やコンテナイメージを展開する場合は、別のAMI製品またはコンテナ製品として公開し、アドオン製品であることを示します。（SaaS製品のガイドライン）

構成図の書き方と申請の手順

AWS Partner Centralでの申請

表示の申請は、AWS Partner Centralで次のように進めます。（SaaS製品の設定）

1. AWS Partner Centralにサインインし、Buildメニューで「SaaS」を選びます
2. SaaS productsの表で、対象の製品を選びます
3. Request changesから「Update architecture details」を選びます
4. ホスティングパターンを選びます
5. Deployed on AWSと見なされるパターンを選んだ場合は、案内に従って、構成図（PNGまたはJPG）をアップロードし、アプリケーションプレーンがどこで動くかを選びます
6. 「Update architecture details」を押します

リクエストの完了後、結果は製品の「Architecture details」タブで確認できます。（SaaS製品の設定）ホスティングパターンが変わったときは、製品のアーキテクチャの詳細を更新する必要があります。（SaaS製品のガイドライン）Deployed on AWSと見なされるホスティングパターンについて、SaaS製品の設定のページは、ガイドラインの条件（本記事の「構成ごとの見立て」で整理しています）を参照するよう案内しています。ただし、画面に表示される選択肢の一覧は、2026年10月5日時点では公開ドキュメントに載っていません。

AWSのブログも、Deployed on AWSのバッジを受けたい販売者には構成図の提出が必要だと案内しています。（AWS Marketplace Blog）

構成図に書くこと

ガイドラインが示す構成図の基準は、次のとおりです。（SaaS製品のガイドライン）

• 構成要素を、アプリケーションプレーンとコントロールプレーンに分けてグループ化し、ラベルを付けます
• AWS外にあって製品の中核の業務ロジックを担う要素は、アプリケーションプレーンに含めます
• 構成要素は、実際に動く場所に配置します。販売者のAWSアカウント、購入者のAWSアカウント、販売者のAWS外の環境などです
• 構成要素は、コンピュートインスタンスやサブネットのような低い粒度でも、データ分析基盤のような高い粒度でもかまいません。サービス名を書く必要はありません
• データのレプリケーションや移行の製品では、対応するすべての移行元と移行先の環境を含めます

構成図は購入者に公開されません。（SaaS製品のガイドライン）

たとえば、コントロールプレーンはすべてAWSにあり、分析ジョブだけがGoogle Cloudにある構成は、次のように書くことになります。

コントロールプレーン
  オンボーディング、認証、契約の管理：販売者のAWSアカウント

アプリケーションプレーン
  テナント向けのWebアプリケーション：販売者のAWSアカウント
  データストア：販売者のAWSアカウント
  分析ジョブ（中核の業務ロジック）：販売者のGoogle Cloud環境

分析ジョブは、製品の中核を担う要素です。ガイドラインに従えば、この要素はアプリケーションプレーンに含めたうえで、AWS外に配置したと書くことになります。そう書いた時点で、この構成はアプリケーションプレーンがAWS上だけで動くという条件に合いません。

購入者のコミット消化は別に確認する

Deployed on AWSの表示が購入者にもたらすものについて、AWSのブログは、AWS上で100%動く製品がこの表示を受け、引き続き追加の購入者向け特典の対象に数えられると述べています。（AWS Marketplace Blog）続く文は、これが組織のクラウド投資の最大化を助けるとしていますが、投資が何を指すかの説明はありません。別の箇所では、表示のある製品はAWSのセキュリティと運用の水準を活かした製品であり、追加の購入者向け特典の対象になり得るとも書いています。ただし、2026年10月28日時点でも、この特典がコミット（購入者がAWSと約束した利用額。Enterprise Discount Program（EDP）と呼ばれる契約など）の消化を指すかは、ブログにもガイドラインにも明記されていません。

いっぽう、コミットの消化そのものについては、別の公式ページに記載があります。Multi-Product Solutions（一つのパートナーが複数の製品をまとめて提供する形態）の購入者向けFAQは、製品がコミット消化の対象として適格であれば購入者のコミットを使えるとしたうえで、AWS上にデプロイされた製品は通常は適格であり、適格性はソリューションに含まれる製品ごとに判定されると述べています。（Multi-Product Solutionsの購入者向けFAQ）同じMulti-Product Solutionsの購入者ガイドは、ソリューション詳細ページのDeployed on AWSが、ソリューション内のすべての製品がAWS上にデプロイされているかを示し、そのソリューションをAWSのコミットプログラムの対象にすると説明しています。（Multi-Product Solutionsを探す（購入者ガイド））ここで注意が必要なのは、これらの記述がMulti-Product Solutionsについての説明だという点です。対象になるとされているのもソリューション単位で、適格性は製品ごとに判定されます。その影響で、AWS Marketplaceのすべての取引や、個々の購入者の契約条件にそのまま当てはめることはできません。単独の製品の取引について、検索結果や製品詳細ページのDeployed on AWSの表示とコミットの消化を結び付ける記述は、SaaS製品のガイドラインにはありません。この論点はAWS Marketplaceでのコミット消化の確認で詳しく扱います。

外部の記事には、この表示とコミットの消化との関係を述べたものがあります。Duckbill Groupの2025年2月6日付の記事は、2025年5月1日から、AWS上だけで動くSaaSだけがコミットの消化に数えられるようになると述べています。また、AWSがこの変更をメールで案内した相手は販売者で、購入者には案内されていないようだとも書いています。（Duckbill Group）これは第三者の著者による解説で、AWSの公式な説明ではありません。契約の時期や条件によって扱いが異なる可能性もあるため、Duckbill Groupの記事の主張は、事実として商品ページに書く根拠にはなりません。

だとすれば、販売者にできるのは、商談の早い段階で購入者に確かめておくことです。確認する先は、購入者のAWSとの契約と、購入者側のAWSアカウント担当です。購入者の調達部門が、AWS Marketplaceでの購入をコミットの消化に使う前提なら、自社の構成が購入者の判断材料になる可能性があります。逆に、コミットの消化が目的ではなく、請求の一本化が目的の購入者であれば、表示の有無は主な論点になりにくいと考えられます。

自社の構成で判断すべきことと順序

AzureやGoogle Cloudで動かしている販売者が実際に決めることは、次の五つです。

1. 自社の構成を、コントロールプレーンとアプリケーションプレーンに分けて棚卸しします。AWS外にある要素と、アプリケーションデータを扱う第三者サービスを洗い出します
2. 掲載の可否を確認します。ホスティング先は問われないため、他のクラウドの構成でも、掲載の共通条件を満たせるかが論点になります
3. Deployed on AWSの表示を目指すかを決めます。目指す場合は、AWS外にある要素をAWSへ移す、または条件に当てはまる形へ変える計画が要ります
4. 主要な見込み客に、AWSとの契約とコミットの扱いを確認します
5. 購入通知を受け取る処理と、権利の確認と課金のAPIを呼び出す処理を、自社の環境でどう実装するか設計します

費用のかかる分岐は、Deployed on AWSの表示を目指すかどうかの判断です。構成の移行にかかる費用と、見込み客がAWS Marketplaceで買う動機を比べて決めることになり、表示を得ること自体を目的にすると判断を誤りやすくなります。出品を判断する枠組みは、AWS Marketplaceに出品するメリットと注意点で整理しています。

冒頭の「Azureで動いているから載せられない」という判断は、掲載については当てはまりません。販売者に残るのは、Deployed on AWSの表示を目指すかどうかの判断と、自社製品の購入が購入者の契約でどう扱われるかの確認です。

掲載準備の進め方と相談先

構成がどうであれ、掲載の工程は、販売者登録、料金設計、製品の登録、連携機能の確認、公開申請と審査を通ります。この工程のうち、日本語の掲載ガイドとタスク一覧、AWS IAMロールとAmazon EventBridgeルールの自動設定、購入後の利用申請フォームを提供するのがDeshimaです。掲載ガイドとタスク一覧は、無料のアカウントから確認できます。

2026年10月5日時点で、Deshimaの対応範囲は、SaaS Contract型のSaaSです。従量課金（メータリング）とChannel Partner Private Offer（CPPO）は対象外で、Concurrent Agreementsには対応済みです。購入者と契約の情報は、Amazon EventBridgeにイベントとして発行され、テナント作成などの後続処理は利用企業の側で実装します。他のクラウドで動くSaaSでこのイベントをどう受け取るかは、構成によって変わります。まずは自社の構成を添えて、ページ下部のお問い合わせから相談してください。対応範囲の詳細は、トップページのFAQに記載しています。Deshimaは更新が多いため、最新の機能と対応範囲は、無料のアカウントを作成したうえで、プロダクト内のドキュメントでご確認ください。

Deshimaの利用料は、初期費用と月額が0円で、売れたときの販売手数料だけが発生します。料率は、2026年10月5日時点では個別に提案します。なお、この販売手数料は、AWS Marketplace自体の手数料とは別です。詳細は、トップページの料金をご覧ください。