AWS Billing Transfer徹底解説 ― AWSパートナーが知るべき新しい請求モデル　概要編

はじめに
1. AWS Billing Transferとは
- 1.1 一言でいうと
- 1.2 なぜ今この機能が必要なのか
2. Billing Transfer以前の課題
- 2.1 複数AWS Organizations運用の課題
- 2.2 AWS再販モデルにおける課題
3. Billing Transferが解決すること
4. 誰がBilling Transferを必要としているのか
5. 検証から見えてきたこと
7. まとめと今後の展望

はじめに

2025年11月にAWSの新たな請求モデル「AWS Billing Transfer」が発表されました。AWSの請求・支払いの仕組みに大きな変革をもたらすこの機能は、特にAWS再販/請求代行を実施しているAWSパートナーにとって見逃せないアップデートです。ネットワールドでは2026年4月よりBilling Transferに対応した再販モデルの販売を開始しました！

本ブログでは、AWS Billing Transferの基本的な仕組みから、AWS再販ビジネスでの課題、実運用上のナレッジを解説します。「Billing Transferって何？」という方から「導入を具体的に検討したい」という方まで、AWS再販ビジネスに関わるすべての方に役立つ内容を目指しました。本ブログを読んでぜひBilling Transferの採用をご検討ください。

Note: 具体的な導入手順については別記事で追記予定です。本記事ではまず「Billing Transferとは何か」「何が変わるのか」を理解することに焦点を当てます。

1. AWS Billing Transferとは

1.1 一言でいうと

Billing Transferは、AWSの請求書・料金支払いだけを別のAWSアカウントに転送できる機能です。

これまでAWSでは、請求とアカウント管理は不可分の関係にありました。AWSアカウントの管理権限を持つ者が、同時にそのアカウントの請求も管理する必要があったのです。Billing Transferはこの制約を取り払い、「アカウントの管理」と「料金の支払い」を分離することを可能にしました。

【従来モデル】
  再販事業者のOrganizations
    └─ 子アカウント（エンドカスタマー利用）
       → RootUser管理も請求管理も再販事業者が担う（SPAM/DAMモデルの場合）

【Billing Transferモデル】
  エンドカスタマー自身のOrganizations
    └─ 自分のアカウント（完全な管理権限を保持）
       → 請求だけをAWSパートナー（ソリューションプロバイダー/Distribution Seller→ディストリビューター）に転送

1.2 なぜ今この機能が必要なのか

現在多くの企業はAWSを再販事業者経由で利用しています。従来の再販モデルでは、再販事業者がAWS Organizationsの親アカウントを保有し、エンドカスタマーには子アカウントを払い出す形が一般的でした。例えばネットワールドでは下記のようなアカウントモデルでアカウントを払い出すことが標準となります。

親アカウントはネットワールドが管理し、エンドユーザー様毎のアカウントを子アカウントとして払い出す形となります。

また、アカウントモデルには下記2パターンがあります。 ECAMは比較的新しいアカウントモデルということもあり、DAM/SPAMモデルで再販アカウントが多く利用されているようです。この仕組みはビジネスモデルとしては合理的でしたが、エンドカスタマーにとっては「（特にDAM/SPAMの場合）自分たちのAWSアカウントなのに完全な管理権限を持てない/AWSの魅力的な機能を十分に活用できない」という課題がありました。Billing Transferはこの課題を根本から解消する機能です。

2. Billing Transfer以前の課題

従来のAWS再販モデルでは、エンドカスタマーは以下の制約を受けていました。 ※実際には再販事業者毎に制約事項は異なります。

課題	詳細
管理権限の制約	RootUserは再販事業者が管理（SPAM/DAMの場合）。アカウントの完全な権限をエンドカスタマーが持てない
セキュリティリスク	再販事業者がアカウントのすべてのデータ・機能にアクセスできる構造的リスク（SPAM/DAMの場合）ECAMの場合でもSCP誤適用などによる外部リスク
コスト可視性	Billingページへのアクセスが制限され、リアルタイムのコスト把握が困難
Organizations機能の制限	再販事業者が提供するOrganizationsプランでは、親アカウントへのアクセスが限定的

最近は特にIAM Identity Centerを使いたいのに再販事業者のプランでは利用できない、という制限が問題になっていました。再販事業者によってはAWS Billing Consoleへのアクセスを禁止しているところもあり、AWS費用確認のために別サイトを参照する必要があったり、AWS BudgetやCost Anomaly Detectionといったコスト管理サービスが利用できないといった課題もあります。

再販事業者側にも課題がありました。

エンドカスタマーのRootUser権限を厳重に管理するためのセキュリティコスト
Organizations数の増加に伴う請求処理の複雑化
複数Organizationsにまたがるコスト管理の困難さ

3. Billing Transferが解決すること

3.1 セキュリティの自律性

Billing Transferにより、エンドカスタマーは自身のAWS環境に対する完全なセキュリティ制御と管理者権限を維持したまま、支払い機能だけを外部アカウントに移管できます。

RootUserをエンドカスタマー自身が管理するため、再販事業者へのセキュリティ依存がなくなります。これは特にセキュリティ要件が厳しい業種のお客様にとって大きなメリットです。

3.2 請求の集約化

複数のAWS Organizationsにまたがる請求とコスト管理を、単一のアカウントに集約できるようになります。

【請求集約のイメージ】

  Bill-Receiver Account（請求受取アカウント）
    ├─ Organization A の請求 ─── 転送 ───→ 集約
    ├─ Organization B の請求 ─── 転送 ───→ 集約
    └─ Organization C の請求 ─── 転送 ───→ 集約
         ↓
    単一アカウントで全体のコスト分析が可能に

3.3 エンドカスタマーのメリット

完全な管理権限: 自社のOrganizationsを自ら管理し、すべてのAWS機能をフル活用できる
セキュリティの独立性: RootUserを自社で管理し、アカウントの完全な制御権を保持
請求の一元化: 複数Organizationsを持つ大規模組織でも、経理部門は支払いを一元管理可能
コスト可視性の向上: Billingページに自由にアクセスし、リアルタイムにコストを把握

3.4 再販事業者（SPP/Distribution Seller）のメリット

請求処理の簡略化: 複数Organizationsを提供しても請求処理を一本化できる
セキュリティ管理コストの削減: エンドカスタマーのRootUser管理が不要に
柔軟なOrganizations提供: エンドカスタマーへのOrganizations提供をより積極的に提案可能
Billing Conductorによるカスタム請求: 顧客ごとに割引・手数料の設定が可能

4. 誰がBilling Transferを必要としているのか

4.1 エンドカスタマーのユースケース

Billing Transferがもっとも刺さるエンドカスタマーは以下のようなケースです。

セキュリティ要件が厳しい組織: 金融、医療、政府系など、アカウントの完全な管理権限を自社で保持する必要がある
複数Organizationsを運用する大規模組織: 請求の集約とOrganizations横断のコスト分析を実現したい
AWS活用を本格化したい組織: Organizations機能（IAM Identity CenterやControlTower）をフルに活用したいが、従来の再販モデルでは制約があった

4.2 再販事業者のユースケース

再販事業者（SPP/Distribution Seller）はOrganizationsの提供を希望する顧客に対して、Billing Transferで請求管理を維持しながら柔軟なOrganizations利用を提案できるようになります。

4.3 ディストリビューターのユースケース

Billing TransferはAWS Distributorであるわたしたちネットワールドにとっても大きなメリットがある機能です。この機能は請求の二段階転送（エンドカスタマー → パートナー → ディストリビューター） に対応しています。これはまさに、ディストリビューター ― パートナー ― エンドカスタマーという多段商流モデルに合致する設計です。

ディストリビューターにとってのメリット

多数のPayer Accountへの個別ログインが不要になり、単一アカウントで請求処理が完結する
複数Organizations全般にわたるコスト分析が容易になる
パートナーごとにカスタマイズされた請求設定を適用できる
エンドカスタマーへの積極的なOrganizations提供が可能になり、差別化要因となる

わたしたちの請求業務も楽になって、エンドカスタマー、パートナー様にもメリットある機能です。ぜひみなさまにBilling Transferを使ってほしいです。

5. 検証から見えてきたこと

ネットワールドではパートナー様へのBilling Transfer提供にあたり実際に検証環境を構築して動作を確認しました。ここでは検証から得られた主な知見を共有します。

5.1 検証環境の概要

AWSさんのBlogなどすでに請求書の一段階転送の検証報告は多くあるため、ここではディストリビューター ― パートナー ― エンドカスタマーの三層構造（請求書の二段階転送）を検証します。検証にあたり以下アカウントを用意しました。

アカウント	役割	説明
Bill-Receiver Account	ディストリビューター	最上位の請求受取アカウント。すべての請求を集約する
Bill-Transfer Account	パートナー	エンドカスタマーの請求を受け取り、ディストリビューターに転送する
Bill-Source Account	エンドカスタマー	エンドカスタマーが自ら管理するアカウント

5.2 基本的な設定フロー

Billing Transferの設定は大きく分けて2つのステップがあります。

AWS Partner Centralでの設定: アカウント間の関係（PMA：プログラム管理アカウント）を登録する
AWSマネジメントコンソールでの設定: 請求転送の招待・承認を行う

設定自体はシンプルですが、AWS Partner Centralでの関係登録にはいくつかの前提条件があります。

対象アカウントがAWS Organizations（すべての機能）を有効にしていること
他のプログラム管理アカウントと関係を持っていないこと
リンクされているアカウントではないこと

導入手順の詳細は別記事で解説予定です。

5.3 AWS Billing Conductorとの連携

Billing TransferではAWS Billing Conductorと連携することで、転送元アカウントごとにどのような料金を表示させるかカスタマイズすることができます。

Billing Conductorには2つの料金プランがあります。

プラン	内容	費用
BasicPricingPlan	AWS標準のパブリックオンデマンド料金を適用	無料
カスタム料金プラン	顧客ごとに割引・手数料を設定可能	現在は無料だが 2026年6月1日よりUSD 50/月/Organizations

カスタム料金プランでは、料金ルールで割引率・割増率を設定したり、カスタム明細項目で固定費用を追加したりできます。Billing Conductorの詳細については別記事で解説予定です。今回はBasicPricingPlan（エンドカスタマーには定価を公開する）を前提にしています。

5.4 転送チェーンの制約

検証で判明した重要な制約として、転送チェーンの長さにはデフォルトの上限があることが分かりました。

二段階転送（エンドカスタマー → パートナー → ディストリビューター）を構成しようとしたところ、以下のエラーが発生しました。

You have exceeded the maximum length of your transfer chain.

これは「請求書転送チェーンの長さ」のデフォルト値が1に設定されていることが原因です。AWSドキュメントではService Quotaからの上限緩和申請が案内されていますが、検証環境の新設アカウントでは申請が承認されませんでした。なお、Billing TransferのService Quotaはus-east-1のOrganizationsに存在します。ディストリビューター以外は2段階転送が必要になるケースは少ないと思いますが、念のため。パートナー様が利用する Bill-Transfer Accountの転送チェーンは1で問題ありません。

5.5 料金の見え方

検証環境でのコスト表示を確認した結果は以下の通りです。

請求受取側（ディストリビューター）の場合： - Cost Explorerの「請求ビュー」を有効化すると、転送されたアカウントのコストが確認できる - Billing Conductorで原価とパブリック価格の差分（マージン）を確認可能

請求転送側（エンドカスタマー/パートナー）の場合： - Billingページにはパブリックオンデマンド料金（BasicPricingPlanの場合）またはカスタム料金が表示される

つまり、エンドカスタマーには適切な料金が表示され、ディストリビューターやSPP/Distribution Sellerの原価が開示されることはありません。

5.6 NGパターン

検証及び調査の結果、以下パターンはBilling Transferを設定できないもしくは再販用アカウントとして利用できないことが確認されました。 - Organizations未有効化の単独アカウント
- パートナーのBill-Receiver Accountの子アカウント - DAM/SPAMモデルのアカウント

Organizationsを構成していない単独アカウントはそもそもBilling Transferを設定できません。これはBill-Receiver/Bill-Transfer/Bill-Source Accountに共通する制限です。
SPAMモデルで払い出していたSPPの子アカウントなどはパートナーの自社アカウントとして判定されます。再販の要件を満たさないためご注意ください。
Billing-TransferはECAMモデルが前提となります。

5.7 Billing Transfer導入および移行シナリオ

AWS導入初期段階でOrganizationsを利用していないエンドカスタマーに対しては、以下のいずれかのアプローチが考えられます。

従来のDAM/SPAMモデル（再販事業者のOrganizations配下）でアカウントを提供する
Organizationsを有効にしたアカウントを作成し、Billing Transferで転送設定する

Organizations有効化が前提となるため、お客様のAWS利用状況に応じた提案が求められます。

既存の再販モデルアカウントをBilling Transferに移行させるには以下シナリオとなります。 - エンドカスタマー用Organizations親アカウントを作成し、従来組織から子アカウント離脱させ、新組織へ移管する従来SPPやディストリビューターの組織に参加していたアカウントをエンドカスタマー用の組織へ移管させる必要があります。親アカウントにリソースを立てることは非推奨となっていますので、子アカウントを従来組織から離脱させそのままOrganizationsの親アカウントとすることは原則行わないでください。新組織のRootUserはエンドカスタマーのドメインであることが必須となります。

6. まとめと今後の展望

AWS Billing Transferは、従来の再販モデルにおける「セキュリティの自律性」と「請求の集約化」という2つの大きな課題を解決する機能です。

Billing Transferが特に有効なケース： - セキュリティ要件が厳しく、アカウントの完全な管理権限をエンドカスタマーに渡す必要がある場合 - 複数Organizationsの請求を一元管理したい場合 - 再販事業者がエンドカスタマーへ完全なOrganizations管理機能を提供したい場合

Billing TransferはAWSパートナーにとっては請求業務の効率化とエンドカスタマーへの付加価値提案の両面で大きなポテンシャルを持つ機能です。

次回、具体的な導入手順や設定方法については別記事で詳しく解説する予定です。Billing Transferの導入をご検討の方は、ぜひそちらもご覧ください。