Summary

  • AWS Marketplaceは、通常のSaaS製品では製品・顧客・時間・料金項目で利用記録を重複排除する。複数契約を扱う製品では、製品に代わって個々のライセンスが記録の識別要素になる。
  • AWSの販売者向け文書は、同じ顧客の同じ利用時間をProductCodeとLicenseArnの両方で送ると二重請求になると警告する。移行時の一時間には送信経路を一つだけ割り当てる必要がある。

一時間しか使っていない。帳簿には二つの入口がある。

AWS Marketplaceでは、SaaS販売者が利用量を測り、AWSへ記録を提出する。AWSは提出された量と設定された価格に基づいて購入者の請求額を計算する。複数契約に対応しない製品なら、重複の判定単位は製品、顧客、時間、料金項目だ。複数契約に対応すると、一つの顧客アカウントが同じ製品について複数の有効な契約を持てる。各契約には固有のLicenseArnがあり、利用量はライセンス単位で管理される。

移行時に危険なのは、二つの仕組みがそれぞれ正常に働く場合だ。AWSによると、同じライセンスでの再送は通常の重複排除に従う。一方、同じ利用時間を旧式のProductCodeと新式のLicenseArnでそれぞれ送ると、二重請求になる。旧送信処理が残ったまま新処理を動かせば、社内の作業記録は一つでも、プラットフォームには異なる識別子を持つ二つの請求対象が届く。

AWSは2026年6月1日から、新しいSaaS製品に複数契約対応の更新された連携方式を求めている。既存の連携は継続できる。したがって、日付を全既存販売者の強制移行日として扱うのは誤りだ。移行を選ぶ販売者には、旧方式が担当する最後の時間と、新方式が担当する最初の時間を決める仕事がある。

新方式で必要なライセンス識別子は、顧客登録時のResolveCustomerから得る。AWSはライセンスを基準に計量する場合、各UsageRecordにLicenseArnを含め、リクエスト全体のProductCodeは外すよう求める。一つの顧客が二つの契約を持つなら、製品名だけでは利用量の帰属先を決められない。顧客、契約、料金項目、UTCの時間帯を結び付ける内部台帳が要る。

送った後の修正にも限界がある。AWSは、料金項目の利用量を一度報告すると、ゼロであっても修正できないと説明する。同じ識別条件で異なる量を再送しても、最初の量が請求対象になる。複数の送信が自動で合算されるわけでもない。新しい経路で成功応答が得られたという試験だけでは、旧経路の停止を証明できない。

購入者は請求管理画面で料金項目ごとの利用量と費用を見られ、設定次第でCost and Usage Reportから単価を含む明細を確認できる。ただし即時反映ではない。販売者側ではCloudTrailでAPI送信を検証できる。特定の顧客に二重請求があったか判断するには、その時間帯と契約の提出記録と、確定した請求明細が必要だ。

識別子の変更は、請求の行き先を変える。AWSが重複排除の境界を作り、販売者がどの経路へ利用量を流すか決め、購入者がその結果を支払う。移行の管理者は、コードの切り替え時刻を請求の切り替え時刻として扱うべきだ。

公式資料