Serverless Operations, inc

>_cd /blog/id_2j8b-ig-bw

title

AWS Marketplace に SaaS を出品するための参考アーキテクチャ

summary

AWS Marketplace に出品する SaaS 製品は顧客オンボーディング対応を行う必要があり、以前「AWS Marketplace へ SaaS プロダクトを掲載するために必要な作業まとめ」という記事でその内容を概要レベルでご紹介したことがあります。この記事では、2024年の時点で改めてその内容を振り返り、どのようなシステム構成で構築できるかにフォーカスして情報をまとめました。AWSマーケットプレイスへSaaS出品を検討している方は是非ご参考ください。

前回の記事では SaaS 出品に関する仕組みについて簡単にご紹介しました。2024年現在、基本的な内容はそれほど変わっていませんが、以前と比べてセルフサービス型で登録が便利になっており、公式の参考アーキテクチャもより分かりやすくなりました。構築に際して抑えるべきポイントを、弊社が解釈した参考アーキテクチャと合わせてお伝えします。

事前に行うこと

AWS マーケットプレイス SaaS 出品に際して対応が必要な項目として、以下のようなものがあります。各項目の内容は前回の記事と大きく変わりませんが、簡単におさらいしていきます。

販売者登録(Seller Account へ登録)

AWS Marketplace 管理ポータルから販売者登録を行います。公開プロファイル情報、銀行口座や税金に関する情報を登録を行う必要があります。米国に銀行口座や拠点がない場合でも、Hyperwallet を利用して登録および SaaS 出品を行うことが可能です。

また、SaaS として出品するための要件があります。SaaS 製品ガイドラインを事前にチェックしておくことをおすすめします。

SaaS 出品計画の選定

ここでいう「計画」とは、具体的には SaaS の料金体系のことを言います。SaaS 出品登録時に以下の項目の中で一つ選択することになりますので、どのような販売形態と料金モデルになるかを考えておく必要があります。

料金モデル

内容

適用例

Usage-based pricing

従量課金モデル

製品の利用量に基づく課金

Contract-based pricing

契約モデル

利用プランに応じた月額課金

Contract with consumption

契約モデル(従量課金あり)

利用プランに応じた月額課金と従量課金の混合モデル

SaaS 出品登録

AWS Marketplace 管理ポータルの製品登録ページ(SaaS Products)から上記料金モデルと製品情報等を入力して登録を進めます。しばらくすると Limited アクセス状態になり、ここから顧客を SaaS 製品に連携するオンボーディング対応(顧客がAWS Marketplace 購入ボタンを押してから SaaS が利用できるまでの対応)を経て、AWS Marketplace チームによる製品レビューが行われ、その後 Public 状態で公開される流れになります。

参考アーキテクチャ

この記事では、顧客オンボーディングのポイントになる構成とポイントを大きく3つのパーツに分けて紹介いきます。それぞれ、料金モデルに応じて内容は少しずつ異なりますが「Contract with consumption」モデルに関しては全ての内容が必要となります。

1. 登録ランディングページを作成

顧客が AWS Marketplace で契約を行うと、登録時に指定した fulfillment URL にリダイレクトされます。SaaS 製品はこの URL にリダイレクトされた場合、ResolveCustomer API を利用して製品コード、顧客のAWS アカウント ID、顧客ID を取得することができますので、製品内または AWS Marketplace と連携するためのマイクロサービスを構え、製品のユーザー情報との紐付けを行う仕組みを作っておきます。

具体的には、リダイレクトされたページで新規ユーザー登録を行ったり、既存ユーザーの場合は支払情報を AWS Marketplace に指定するといった対応が必要になります。

2. 契約情報を取得し、契約更新・サブスク通知対応できるようにしておく

ResolveCustomer API から取得した情報を元に、GetEntitlements API を利用してその顧客の契約情報を取得し、顧客が選択した契約内容に合わせて製品上でのアクセス権付与または機能が利用できるようにしておきます。具体的には、GetEntitlements API のレスポンスから、顧客が製品登録時に設定したディメンジョンのどれに該当するかについての情報が入っているため、それに合わせて機能解禁や課金項目を作成するといった形になります。

また、契約情報の他に、サブスクリプション通知の対応が必要になります。契約のみの場合は契約変更通知、従量課金の場合はサブスク状態の変更通知、両方の組み合わせの場合は両方の通知が飛んできます。例えば、顧客が契約したプランをアップグレードしたり(※ダウングレードはできません)、従量課金のサブスクリプションを解除するような場合に、通知されます。

契約更新の場合は entitlement-updated という通知が、またサブスクリプション状態の変更は以下の項目で通知されますので、製品側ではこの状態に合わせて適宜顧客の利用制限などを行うといった対応を行います。

  • subscribe-success
  • subscribe-fail
  • unsubscribe-pending
  • unsubscribe-success

3. 従量課金情報を送信する

従量課金が含まれる料金モデルの場合、利用量を測定し、その量に応じた課金を行います。製品登録時に従量課金の項目と単位を指定しますので、製品での利用実績などに応じていくら課金するか(具体的には、登録したどのディメンジョンに対してどれぐらいの Unit を加算するか)の情報を AWS Marketplace に送信する必要があります。その時に利用するのが、BatchMeterUsage API です。顧客ID、ディメンジョン、量を指定して送信する形になります。

課金した内容を後からでも正確に確認できるように、一旦 DynamoDB などに保存してからバッチ処理で入れておくような流れにすると便利です。

その他考慮事項

他にも、実際に SaaS 製品を出品して運用するには、例えば以下のような考慮事項があります。

  • 契約情報変更(プランのダウングレード等)
  • プライベートオファー(ある顧客には別の料金体系を提示)の有無
  • 途中解約、払い戻し

製品のサービス仕様および AWS Marketplace での制約事項と照らし合わせて、どのように対応するかについての方針を決めておくとスムーズですので、出品前からあらかじめ検討しておくことをおすすめします。

この記事に関する内容を含め、AWS Marketplace 連携に関する内容全般において気になる点やサポートが必要な場合は、お気軽にお問い合わせください。

Written by
COO

金 仙優

Sonu Kim

  • Facebook->
  • X->
  • GitHub->

Share

Facebook->X->
Back
to list
<-