RI/SPの割引共有は2025年11月に「組織まるごとON/OFF」ではなくなった — マルチアカウント環境で確認すべき7項目

ここまで3本、請求書から割引を読む話を書いてきました。SPとRIを請求書だけで見分ける方法、リセラー割引が掛かる分母、実案件9件でその分母が総額の何%だったか。どれも「率」と「分母」の話でした。

この記事は別の軸です。同じ割引が、組織の中で誰に届いているか。

アカウントが1つなら考える必要のない論点ですが、本番・検証・開発でアカウントを分けている、あるいは部門ごとにアカウントを持っている構成では、買った割引が想定と違うアカウントに流れていることが普通に起こります。しかも請求書の総額は変わらないので気づきにくい。気づくのはたいてい、社内の費用配賦でもめたときか、リセラーへの切り替えを検討して構成を洗い直したときです。

そして2025年11月に、この領域の前提が1つ変わりました。割引共有は「組織まるごとON/OFF」ではなくなっています。

なぜ今この話か

前回の集計で、分析した9件のうち6件がSavings Plans・Reserved Instances・CUDのいずれかを保有していました。コミット型の割引を持っている会社のほうが多数派です。そしてコミット型を持っていて、かつアカウントが複数あるなら、共有設定は必ず効いています。設定した覚えがなくても効いています。デフォルトが有効だからです。

つまり「うちは共有の設定なんてしていない」は、「デフォルトの挙動をそのまま使っている」と同じ意味です。それが意図と合っているかどうかは、別途確認しないと分かりません。

前提: AWSは組織全体で共有するのがデフォルト

AWS Organizations の一括請求（consolidated billing）配下では、RIとSavings Plansの割引共有はデフォルトで有効です。管理アカウントの Billing and Cost Management コンソール、Billing preferences（請求設定） にある「Reserved Instances and Savings Plans discount sharing」で、アカウント単位にON/OFFできます。

ここまでは多くの社内ドキュメントに書かれている前提だと思います。問題は、この先です。

変化1: グループ共有（2025年11月GA）

2025年11月19日、AWSは Savings Plans and Reserved Instances group sharing を一般提供として発表しました。従来はアカウント単位のON/OFFしかできませんでしたが、Cost Categories で定義したアカウントのグループ単位で共有の効かせ方を制御できるようになっています。

公式ドキュメントで示されている共有モードは2つです。

この2つは、実務で長年トレードオフだったものを設定に落としたものです。

• Restricted は費用配賦の公平性に寄ります。部門Aが買ったコミットは部門Aだけが使う。社内で「うちのコミットを他部門に食われている」という揉め方をしないで済みます。代わりに組織全体での消化率は落ちます
• Prioritized は消化率に寄ります。買った部門を優先しつつ、余りは全社で使い切る。代わりに部門間の配賦は複雑になります

どちらが正しいという話ではなく、社内の費用配賦をどう運用したいかで決まるものです。従来はON/OFFの二択だったので、この判断を設定で表現できませんでした。「アカウント単位でONかOFFか」でしか語れない社内資料があるなら、それは2025年11月より前の前提です。

制約として、AWSの発表では GovCloud（US）リージョンと中国リージョンは対象外とされています。

なお、グループをいくつまで作れるか、1つのアカウントが複数グループに所属できるかについては、AWSの公式資料で明記された記述を確認できませんでした。設計に入る前に確認すべき項目として扱ってください。この記事では断定しません。

変化2ではないが見落とされる: 買ったアカウントが優先される

これは昔からの挙動ですが、共有をONにしている現場ほど誤解されています。

RI/SPの割引は、まず購入したアカウント自身の利用に適用され、そこで消化しきれなかった分が組織内の他アカウントに回ります。

順序が決まっているということは、こうなります。

架空の数字で書きます。以下の金額はすべて架空で、実在の構成を示すものではありません。

本番アカウントで Compute Savings Plans を月100万円分コミットしているとします。

上の行の状態、つまり購入アカウント自身が十分に使っている間は、共有をONにしていても他アカウントには1円も回りません。「共有をONにしたのに開発アカウントの請求が下がらない」という相談は、たいていこれです。設定は正しく効いていて、単に余りが出ていないだけです。

厄介なのは下の行です。本番のワークロードを縮小したりGravitonへ移行したりして対象利用が落ちると、余りが出ます。このとき余りの行き先が、共有設定で決まります。共有をOFFにしているアカウントには回らないので、行き場がなければ未消化のままです。コミット費用は払い続けているのに、割引としては誰にも届いていないという状態がここで生まれます。

だから確認すべきは、共有設定そのものより先に**「今、余りは出ているのか」**です。Cost Explorer の Savings Plans utilization / coverage レポートで、購入アカウントの利用率を見てください。利用率が100%に張り付いているなら、共有設定を触っても何も変わりません。

Zonal RI を「共有できる予約」と思わない

RIには、リージョン単位で適用される Regional RI と、アベイラビリティゾーンを指定する Zonal RI があります。この2つは割引の共有という文脈で混同されがちですが、そもそも提供しているものが違います。

ここで大事なのは、割引の共有と、キャパシティ予約は別の話だということです。Zonal RIを買った目的が「必要なときにインスタンスを確保できること」なら、その目的は購入したアカウントのためのものであって、割引共有の設定でどうにかなる性質のものではありません。

逆に言えば、キャパシティ確保が要らないのにZonal RIを買っていると、サイズの柔軟性を捨てているぶんだけ損をしています。ファミリー内でサイズを変える運用をしているなら、Regional RIのほうが素直です。ただし、Regional RIのサイズ柔軟性がどのOS・テナンシー条件で成立するかは、今回の確認では公式資料から条件を特定しきれませんでした。自社の構成が該当するかは、購入前にAWSまたは販売事業者に確認してください。

Google Cloudは単位も順序も違う

同じ話をGoogle Cloudでやろうとすると、AWSの用語がそのまま対応しません。

共有の単位が違います。 AWSはOrganizations（一括請求のまとまり）が単位ですが、Google CloudのCUD共有は Cloud Billing account 単位です。公式ドキュメントによれば、共有が有効な場合、resource-based CUD は Billing account レベルでプールされ、同じ Billing account にリンクされた任意のプロジェクトの適格な使用量に適用されます。そして多くの Cloud Billing account でデフォルト有効です。

優先順位の考え方も違います。 AWSは「買ったアカウントが先」でしたが、Google Cloudの公式説明は「購入したプロジェクトに限定されず、同じ Billing account 配下の適格使用量に分配される」という書き方で、購入プロジェクトが優先されるとは読めません。同一 Billing account 内でどのプロジェクトから先に消費されるかの厳密なアルゴリズムまでは、公式資料からは特定できませんでした。

種類による違いも残っています。 公式に共有の説明があるのは Compute Engine の resource-based CUD です。Cloud SQL・Spanner・Dataflow などを対象とする spend-based（flexible）CUD について、resource-based と同じ共有の説明は確認できませんでした。同じ挙動だと仮定しないでください。

CUDの帰属設定は Billing の Committed use discounts から View Analysis → Configure Attribution で扱いますが、共有そのものを無効化できるか、プロジェクト単位で除外できるかは、今回参照した公式資料の範囲では断定できませんでした。ここも確認事項です。

Sustained Use Discount（SUD）については、Compute Engine で継続して提供されており、対象となる使用量に自動適用されます。前回のGoogle Cloud編にも書いたとおり、SUDはCompute Engineの話で、他サービスにも同じものがあると仮定すると外れます。

まとめると、AWSの共有設計をそのままGoogle Cloudに写すことはできません。「共有はデフォルトON」という一点だけが共通で、単位も優先順位も種類ごとの扱いも別物です。

いちばん効くのは「請求のまとまりを変えるとき」

ここまでを1行にすると、こうなります。

割引共有のスコープは、技術構成ではなく請求のまとまりに紐づいている。

AWSならOrganizations、Google Cloudなら Cloud Billing account。どちらも請求の器です。ということは、サーバーもコードも一切変えていないのに、請求まわりの都合で構成を触ると割引の効き方が変わります。

具体的には次のような場面です。

• アカウントの統廃合・組織の付け替え — 別のOrganizationsに移ると、元の組織のRI/SPは届かなくなります
• 子会社・事業部の分離 — 請求を分けた時点で、共有していた割引の前提が崩れます
• Google Cloudでのプロジェクト移動 — プロジェクトを別の Cloud Billing account に移すと、そのプロジェクトは元の Billing account の共有範囲から外れます。ただし移動後の既存CUDの扱いを明示した公式手順は確認できなかったため、事前に確認してください
• 請求代行・リセラーへの切り替え — 請求の器そのものを変える話なので、まさにここに当たります

最後の点は、この記事の中でいちばん実務的な落とし穴です。リセラーへの切り替えでアカウントを新規に作り直す形になる場合、アカウントIDが変わり、ワークロードを移す作業が発生します。このとき、移行前の組織で共有していた割引の関係は、そのままの形では引き継がれません。

だからこそ、前々回の記事にも書いたとおりコミットの満了日を先に洗い出すことが効いてきます。マルチアカウント環境では、これに**「そのコミットは今、どのアカウントで消化されているか」**が加わります。満了日だけ見て動くと、移行後に「消化していたのは別部門のアカウントだった」と後から分かることがあります。

チェックリスト（7項目）

社内で確認するとき用に、順番も含めて整理します。上から順に見てください。

1. コミット型の割引を持っているか、その購入アカウントはどこか 持っていなければ以降は不要です。持っているなら、SP/RI/CUDそれぞれについて購入アカウント（プロジェクト）と満了日の一覧を作ります。ここが土台です。

2. 今、余りは出ているか Cost Explorer の Savings Plans utilization / coverage、Google Cloud なら CUD の消化状況。購入アカウントの利用率が100%近いなら、共有設定を触っても請求は動きません。 先にこれを見ないと、以降の作業が空振りします。

3. 割引共有はどのアカウントでONになっているか AWSは管理アカウントの Billing preferences。デフォルトで有効なので、**「設定していない」＝「全部ONのまま」**です。意図してOFFにしたアカウントがあるなら、その理由が今も有効かを確認します。

4. グループ共有を使う余地があるか 部門間の配賦でもめている、あるいは「買った部門が優先されるべき」という社内合意があるなら、2025年11月GAのグループ共有が選択肢になります。Prioritized（優先しつつ余りは全社へ）と Restricted（グループ内で閉じる）のどちらが自社の運用に合うかを先に決めてから設定してください。GovCloud（US）・中国リージョンは対象外です。

5. Zonal RI をキャパシティ確保以外の目的で買っていないか 買っているなら、キャパシティ予約が本当に要件かを確認します。要らないならRegional RIのほうがサイズ柔軟性のぶん有利です。割引共有の設定では解決しない論点なので、共有の議論と混ぜないでください。

6. Google Cloudを併用しているなら、AWSの設計を写していないか 共有の単位（Organizations vs Cloud Billing account）、優先順位（購入側が先か、フラットか）、種類ごとの扱い（resource-based と spend-based）が別物です。同じ設計思想で運用ルールを書いていたら、そこは要検証です。

7. 今後1年で、請求のまとまりを変える予定があるか 組織再編、子会社分離、請求代行・リセラーへの切り替え、Google Cloud の Billing account 付け替え。予定があるなら、コミットの満了日と「どのアカウントで消化しているか」を突き合わせてから時期を決めます。 順序が逆になると、動いた後で消化先が消えます。

公式に書かれていなかったこと

この記事を書くにあたって公式資料を当たった範囲で、確認できなかった項目を明示しておきます。設計に入る前にAWS・Google Cloud、または販売事業者に確認してください。推測で埋めないほうがいい領域です。

特に1つめは実務に直結します。反映タイミングが確定していない設定を月の途中で変えて、その月の請求書で効果を検証するのは避けてください。 月次で切り替えて、翌月以降の請求書で比べるほうが安全です。

まとめ

• RI/SPの割引共有は、AWS Organizations 配下でデフォルト有効。「設定していない」は「全部ONのまま」と同義
• 2025年11月19日にグループ共有がGA。Cost Categories でグループを定義し、**Prioritized（優先＋余りは全社）/ Restricted（グループ内で閉じる）**を選べる。ON/OFFの二択を前提にした社内資料は古い
• 割引は購入したアカウントの利用に先に適用される。購入アカウントが使い切っている間は、共有をONにしても他アカウントには回らない
• Zonal RIのキャパシティ予約と、割引の共有は別の話。Regional RIはサイズ柔軟性があるがキャパシティ予約はない
• Google Cloudは共有の単位が Cloud Billing accountで、購入プロジェクトが優先されるとは公式に読めない。AWSの設計を写せない
• 共有のスコープは請求のまとまりに紐づく。組織再編・請求代行への切り替えなど、技術構成を変えない変更でも割引の効き方が変わる
• 反映タイミング・グループ数上限など、公式に明記がない項目がある。断定せず確認事項として持つ

CloudCutの見方

私たちはAWS / Google Cloudの請求代行を通じた最大20%の削減¹を提供していますが、この記事の論点は割引率の話とは独立しています。請求の器を変える以上、コミット型の割引がどう効いているかを先に把握しておく必要がある、という順序の話です。

そのため、お切り替えのご相談をいただいた場合、率の話に入る前にコミットの種類・満了日・どのアカウントで消化されているかを確認しています。マルチアカウント構成では、ここを飛ばすと切り替えの適切な時期が出せません。

「今の構成で、コミットがどのアカウントに効いているのか整理したい」というご相談だけでも承っています。切り替えのご検討とは切り離してお出しできます。