セキュリティサービス部 佐竹です。
本日は、2025年11月19日に発表された AWS コスト管理における新機能「Reserved Instances and Savings Plans (RISP) Group Sharing」について記載します。
- はじめに
- AWS のアップデートに関連する情報
- これまでの課題
- RI/SP Group Sharing で可能になったこと
- 実装には「AWS Cost Categories」の設定が必要
- 設定における注意事項
- 実際に設定を行ってみる
- 注意点：月末の設定が「正」になる
- アップデート後の「Savings Plans 購入戦略」を再考する
- まとめ
はじめに
本ブログは、既に Savings Plans や Reserved Instances についての詳細をご存知の方向けの、かなりマニアックな（つまり上級者向けの）内容となっています。
想定読者は、既に SP や RI を運用管理されている、AWS クラウドのコスト担当の方。また、お客様へ SP や RI の購入方法と運用を指南する CSM (TAM) やその他の AWS 導入担当者を想定して記載します。
過去記載したブログのご紹介
最初に、私が過去記載した本アップデートに関連するブログのご紹介をしながら本アップデートの説明のための前提を整えていきます。
まず、本アップデートの理解に役立つ、前提となる機能が存在します。
それが「Reserved Instances and Savings Plans discount sharing」という機能であり、設定です。これは「Billing and Cost Management」の中にある設定項目の1つです。都合「RI/SP の割引共有設定」と呼びます。
補足ですが、画面キャプチャは過去のブログから引用した「今回のアップデートが来る前の画面」です。
本機能については、以下のブログでも解説しました。
RI/SP の割引共有設定は、「購入した RI や SP のディスカウントが、それらを購入したアカウントで使い切られなかった場合に、その他のアカウントにそのディスカウント権を渡すかどうか？」という設定です。
もちろん、使い切られなかったディスカウントの権利を「共有する方が」コスト削減効果が高まるため、コストを最優先にするのであればこれは常に「有効」にするべきとなります。
ですが、それに伴い発生する別の課題があります。以下の「AWS マルチアカウント統制下での Savings Plans 購入戦略を理解する」では、その発生する課題をどう対処するのかを「3つの購入戦略」へとまとめました。
3つの戦略はブログからの引用ままですが、以下の通りです。
| # | シナリオ | SP を購入するアカウント | 割引共有 |
|---|---|---|---|
| 1 | 組織全体でコスト削減効果を最大化したい | SP 購入専用アカウント | 有効 |
| 2 | 各 AWS アカウントでコスト削減に取り組むが、 Savings Plans が無駄になることは避けたい |
各 AWS アカウント | 有効 |
| 3 | 各 AWS アカウントでコスト削減に取り組みたい | 各 AWS アカウント | 無効 |
RI/SP の割引共有設定は、先のブログの「割引共有の有効/無効について」の章でも説明しています。
発生する別の課題とは何か？をざっくり記載すると「Savings Plans のディスカウント権が使い切れなかった場合に、他のアカウント≒他の部署に使われてしまうと、部署別予算や管理の都合が悪い」ということです。
加えて「Savings Plans のディスカウントはコスト最適化効果が高いリソースから順に最適化する」というコスト最適の観点では素晴らしい機能となっていますが、反対に「コスト最適化効果の低いリソースは優先度が下がってしまう」わけです。この時、本来適用したいアカウントのリソースに、Savings Plans が適用されないということが起きえます。
このような課題を、ある程度緩和してくれるのが本アップデートとなります。
簡単に、購入戦略に関する影響を記載すると、この機能により先のブログ「Savings Plans 購入戦略」の「3つの戦略」に、「追加の一層の柔軟性」が生まれることになりました。というのは、「RI/SP の割引共有設定」にもともとあった2種、すなわち「割引共有を有効化しているアカウント群」と「割引共有を無効化しているアカウント群」とに加えて、もう1つグループを追加することができるようになったためです。
以前よりお客様と「RI/SP の割引共有設定」の「割引共有を有効化しているアカウント群」に「さらにいくつかのグループ分けができれば良いのですが」と会話していました。そうすればある程度できることが増えるからなのですが、それが（ある程度は）現実となった形です。
この後は、具体的に何がどう変更され、新しく何ができるようになったのかを詳しく解説していきます。
AWS のアップデートに関連する情報
リリースニュース
- Savings Plans and Reserved Instances Group Sharing is now generally available
ブログ
- Control Your AWS Commitments with Reserved Instances and Savings Plans Group Sharing
AWS 公式ドキュメント
- Reserved Instances and Savings Plans discount sharing
これまでの課題
重要な前提のため、繰り返しになりますが、これまで「RI/SP の割引共有設定」は、以下の2択でした。
- 割引共有を有効化しているアカウント群
- 割引共有を無効化しているアカウント群
（個人的には古い管理画面の方がわかりやすくて好きなのですが）以下の通り、左側が「割引共有を有効化しているアカウント群」で右側が「割引共有を無効化しているアカウント群」です。
まず「割引共有を有効化しているアカウント群」では、「RI/SPの割引（ディスカウント）」が共有されます。
例えば、この中にアカウント A,B,C があるとします。そしてアカウント A が購入した RI/SP はそれが使い切られなかった場合には、アカウント B,C にディスカウント権が使われる可能性があります。
次に「割引共有を無効化しているアカウント群」では、「RI/SPの割引（ディスカウント）」が共有されません。
例えば、この中にアカウント D,E,F があるとします。そしてアカウント A が購入した RI/SP があり、それが使い切られなかった場合において、アカウント D,E,F にディスカウント権が使われることはありません。また、アカウント D 自体が購入した RI/SP はそれが使い切られなかった場合にアカウント E,F に使われることもありません。右側にいるグループは、左側と切り離されていることに加えて、右側の中でも切り離されているからです。
理解を助けるために、説明用の一枚絵をご用意しました。
私はこれをエンドユーザ様には分かり易く「仲間グループ」と「仲間外れグループ」として説明していました。
なお、この管理画面は、新しいコンソール画面では（本アップデート以前は）以下の通りになっていました。
「Activated」となっているアカウント群が「割引共有を有効化しているアカウント群」、つまり古い画面の左側に位置します。「Deactivated」となっているアカウント群は、「割引共有を無効化しているアカウント群」です。
RI/SP Group Sharing で可能になったこと
では本題です。
今回のアップデートにより、これまで「仲間グループ（有効）」と「仲間外れグループ（無効）」の2つしかなかった設定に、「共有グループ（sharing group）」という「一層」が追加されました。
マネジメントコンソールの「Billing preferences」にある「Reserved Instances and Savings Plans discount sharing preference」の設定画面に、新しく "Sharing group preference - new" というセクションが追加されています。
「Edit」を押下すると以下の画面に遷移します。
ここでは、以下の3つのモードから選択が可能になりました。
- Open Sharing (with all activated accounts):
Commitment is available to all activated accounts
(訳) コミットメントはすべてのアクティブなアカウントで利用可能です。 - Prioritized sharing group (first within, then beyond groups):
Commitment is shared with groups first, then becomes available to activated accounts
(訳) コミットメントはまずグループと共有され、その後（余剰分が）アクティブなアカウントで利用可能になります。 - Restricted Sharing group (only within sharing groups):
Commitment is exclusively available to members of your defined sharing groups
(訳) コミットメントは、定義された共有グループのメンバーのみが排他的に利用可能です。
それぞれの挙動を、これまでの「仲間グループ（有効）」と「仲間外れグループ（無効）」の概念に当てはめながら、詳しく見ていきます。
なお、この「sharing group」は後で補足する「コストカテゴリー」を前提として動作します。
従来通りの Open Sharing (with all activated accounts)
これは、従来の「RI/SP の割引共有設定」と全く同じ挙動です。このため、既存のお客様は現在この設定に移行されています*1。
上図は再掲となります。
このため、本設定に関する説明は割愛します。
① Prioritized sharing group (first within, then beyond groups)
今回のアップデートの1つ、「sharing group」における「Prioritized」モードです。
- 動作:
- 購入アカウント: まず購入したアカウント自身に適用されます。
- グループ内: 次に、定義した「同グループ内」のアカウントに優先的に適用されます。
- 組織全体: それでもディスカウント権が使い切れなかった場合のみ、組織内の他のアカウント（
Activatedされている他アカウント）へ共有されます。
- 位置づけ: いわば、「基本は自分たち（少人数の仲良しグループ）で消費するが、万が一使い切れなかったら外のグループ（大きな仲間グループ）に渡してあげましょう」という設定です。
- ポイント: 「自分の部署で買った SP は、まず自分たちで使い切る」という優先権を確保しつつ、万が一使い切れなかった分は他部署に回るため、無駄（ディスカウント権の失効）が発生するリスクも抑えられます。
この動作を図にすると、以下の通りとなります。
図の通り、「仲間グループ（有効）」の中に「優先されるグループ（黄色の箱）ができる」ということです。
補足ですが、意図していないアカウントにディスカウントが優先されようとするのは「そのほうが本来ディスカウント効果が高い」ためです。このため、意図的に優先する「sharing group」によって、組織全体のコスト最適化効果が減少する可能性がある点に注意してください。
② Restricted Sharing group (only within sharing groups)
そして、今回のアップデートのもう1つ、「sharing group」における「Restricted」モードです。
先ほどと同様「仲間グループ（有効）」の中に「優先されるグループ（黄色の箱）ができる」までは同じですが、グループの外には出ていきません。
- 動作:
- 購入アカウント: 購入したアカウント自身に適用されます。
- グループ内: 定義した「同じグループ内」のアカウントに適用されます。
- 終了: ここで終了です。 使い切れなかったディスカウント権があったとしても、グループ外のアカウントには共有がされません。
- 位置づけ: これまではアカウント単位（個）でしか「仲間外れ」になれませんでしたが、この設定により「少人数の排他的な仲良しグループ」を作れるようになったイメージです。
- ポイント: ディスカウント権がグループ外に流出することを完全に防げます。ただし、優先グループ内で使い切れない場合には、そのコミットメントは無駄（ディスカウント権の失効）になってしまいます。
- ユースケース: これまで「戦略3（共有無効）」を採用していたケースのうち、「部や課ごとの複数アカウントでは共有したいが、事業部外には出したくない」といった、いわゆる「サイロ化された予算管理」が必要な場合に適しています。
この動作を図にすると、以下の通りとなります。
実装には「AWS Cost Categories」の設定が必要
この機能を利用するためには「AWS Cost Categories（コストカテゴリー）」を使って、予めアカウントをグループ化しておく必要があります。
- AWS Billing Console > Cost Categories でグループ定義を作成
- 1つのアカウントは1つの共有グループ (sharing group) にしか所属できない
- Payer アカウントは共有グループ (sharing group) に含めることができない
といった制約や仕様がありますため、実装の際はコストカテゴリーの設計から始める必要があります。もしコストカテゴリーが未設定の場合は、まずはこちらの設計が必要になります。
なお、この「Payer アカウントは共有グループ (sharing group) に含めることができない (Payer account cannot be part of a sharing group)」は少々気がかりな制限です。
原則として、Payer = 組織の管理アカウントには、リソースを作るべきではありません。ですが、管理アカウントで RI/SP を購入されているお客様をお見かけすることもあります。
もし、管理アカウントで RI/SP を購入されている場合は、コストカテゴリーが Payer を含められない仕様のために、Payer アカウントはグループに所属できないことになり、つまりは本機能によるグルーピングの範囲外となってしまいます。
今回のアップデートが使えそうだと感じたとしても、この制限（仕様）により、利用を阻まれてしまうお客様もいらっしゃるかもしれません。
設定における注意事項
AWS ドキュメントに記載のある注意点として、以下の点に注意してください。
- The Savings Plans owner account must remain active in sharing preferences
(翻訳) Savings Plans を保有しているアカウントは、Activatedで維持される必要があります - Both purchasing and benefit receiving accounts must have sharing activated to share discounts
(翻訳) SP を購入したアカウントとディスカウント権を共有で受け取るアカウントは、共にそれぞれActivatedで維持される必要があります
今回「グループの設定」が可能になりましたが「アカウントレベルの設定」も引き続き使えます。この2つがバッティングした場合、アカウントレベルの設定が優先されます。
ようは、上図のような共有グループ (sharing group) 設定もやろうと思えば可能です。ただし、このような設定を施した場合に、グループの設定は意味を成しません。「それぞれ Activated で維持される必要があります」の前提を満たしていないためです。
よって、本共有グループ設定は「割引共有を有効化しているアカウント群」の中で設定を行うもの、と考えて頂く必要があります。
実際に設定を行ってみる
さて、実際に設定をしてみます。
今回は「Prioritized sharing group」です。コストカテゴリーは既存のものを選択しました。
確認画面が表示されるため、ここで左側の「Update and create estimate later」を押下します。右側のボタンを押下すると、Pricing Calculator で Estimate (見積もり)するように促されます*2。
これで、Prioritized sharing group の設定として「Core OU」のコストカテゴリーに所属する AWS アカウントが優先される設定になりました。sharing group として設定が可能なコストカテゴリーは1つのみです。
注意点：月末の設定が「正」になる
他のブログでも「これらの共有設定は最終的に月末時点の設定がその月の「正」として扱われる点にも注意してください。」と記載しているように、「RI/SP の割引共有設定」は月末が「正」です。
You can change your preference at any time. Each estimated bill is computed by using the last set of preferences. The final bill for the month is calculated based on the preferences set at 23:59:59 UTC time on the last day of the month.
---(日本語訳)---
設定はいつでも変更できます。各月の概算請求額は、最後に設定された設定に基づいて計算されます。その月の最終請求額は、月末の23時59分59秒（UTC時間）に設定された設定に基づいて計算されます。
https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-turn-off.html
この点には十分にご注意ください。つまり、設定を変えるたびに、その月の請求額は月初に遡って再計算されます。
反対に、この仕様を逆手にとって月内の検証も可能です。月初に設定を変更し、コスト最適化効果が思ったより芳しくない場合は、月末までに元に戻すことができるからです。
アップデート後の「Savings Plans 購入戦略」を再考する
さて、購入戦略を練り直す必要があります。といっても、基本は以下のままです。変わりません。ただし注釈が付きます。
| # | シナリオ | SP を購入するアカウント | 割引共有 |
|---|---|---|---|
| 1 | 組織全体でコスト削減効果を最大化したい | SP 購入専用アカウント | 有効+①*3 |
| 2 | 各 AWS アカウントでコスト削減に取り組むが、 Savings Plans が無駄になることは避けたい |
各 AWS アカウント | 有効+ ① or ②*4 |
| 3 | 各 AWS アカウントでコスト削減に取り組みたい | 各 AWS アカウント | 無効 |
戦略1での共有グループの利用シーン
まず戦略1ですが、基本はこれまで通りです。共有グループ (sharing group) 設定を行うことで、コスト最適化効果が薄れる可能性があるために、コスト最適化効果を最大にしたい場合には Open Sharing が良いという判断に至るためです。
ですが、その中でも優先したいアカウントがあれば、共有グループ (sharing group) 設定の特に「①Prioritized」を行うことでこれまでの不便さをカバーできると考えられます。ただし、「②Restricted」は推奨されないでしょう。Savings Plans の購入アカウントがたった1つだと仮定する場合、Restricted の選択は完全なる除外とイコールになるため、これはもはや戦略1とは呼べないためです。
基本的に今回の追加機能は、この戦略1において一部優先したいアカウントがある場合に「①Prioritized」で共有グループ (sharing group) を追加する、程度に留める方が良いと感じます。この使い方がわかりやすく、シンプルで良いでしょう。
ただし注意したいのは「現在思ったように Savings Plans が適用されていない」という点においては、「コスト最適化効果が低く、適用対象として優先されていない」ということもあるのですが、単に Savings Plans のコミット金額が足りておらず、カバレッジが低いということがあります。よって、Savings Plans の買い足しも検討されてください。
戦略2での共有グループの利用シーン
では戦略2です。この戦略2においては、割引共有の設定をこれまで通りの「Open Sharing」とするか、今回追加された「①Prioritized」の共有グループか「②Restricted」の共有グループかを選択できます。ただ、残念ながら指定できるコストカテゴリーはたった1つのため、Savings Plans の購入アカウントを複数作り、各購入アカウント別にグルーピングするような器用な真似はできません。
そのため、戦略2においては「効果を閉じ込めたい」という場合に「もう一層追加ができるようになった」程度のアップデートです。この組み合わせはあるようには思いつつ、ニッチな使い方な気もします。
戦略3での共有グループの利用シーン
戦略3は、割引共有をすべて「無効」とするため、共有グループの有無は関係ないものとなります。
ただし、本共有グループ機能が使えるということであれば部分的に「②Restricted」の共有グループを使いたい場合もあると考えられます。その場合は、戦略2+②Restricted の使い方に移行されても良いでしょう。
まとめ
本ブログでは、Reserved Instances と Savings Plans の共有設定で、新しく追加された設定である共有グループ (sharing group) について記載しました。
特に、「優先的に消費させたいグループがある」という要件や、「部内では共有したいが、部外には出したくない」といった要件に対し、AWS アカウントの構造（OU 設計など）を大きく変えることなく、「コストカテゴリー」という論理的なグループ定義だけで対応できるようになった点がポジティブです。
本アップデートに関して、今回のポイントを振り返ります。
- 3つのモード: 従来の「Open Sharing」に加え、優先順位をつける「①Prioritized」と、範囲を限定する「②Restricted」が登場
- 前提条件: 実装には「AWS Cost Categories（コストカテゴリー）」の設計と適用が必須となる
- 制約: 管理アカウント（Payer）はコストカテゴリーの制限上、RI/SP の共有グループに含めることができない
機能としては「あって嬉しい」部分もありつつも、コストカテゴリーの設計が必要である点や、管理アカウント（Payer）の制約など、導入ハードルもいくつか存在します。
また、設定が複雑になる分、意図しない「ディスカウント権の無駄（失効）」が発生しないよう、慎重な設計が求められます。
まずは既存の戦略（特に戦略1や2）の中で、「もう少し柔軟性が欲しかった」という部分に対して、「①Prioritized（優先）」設定あたりからスモールスタートで検証されるのが良いと考えます。
記載した通り、月末の23時59分59秒（UTC時間）に設定された設定に基づいて計算されます。よって「月初に設定を変更し、コスト最適化効果が思ったより芳しくない場合は、月末までに元に戻すことができる」ため、検証される場合は月末を避けられた方が無難です。
ここまで記載してから思うのですが、簡単なアップデートだと思ってブログを書き始めたら思ったよりも複雑な解説になり驚いています。
それでは、またお会いしましょう。
*1:これは先ほどの弊社アカウントの画面キャプチャが、この通りになっていたことで確認ができています。
*2:あまりにも Pricing Calculator を使わせようとする、この執拗な実装は一体なんなのだろうと感じるレベルです
*3:割引共有の設定をこれまで通りの「Open Sharing」とするか、今回追加された「①Prioritized」かを組み合わせることが可能
*4:割引共有の設定をこれまで通りの「Open Sharing」とするか、今回追加された「①Prioritized」か「②Restricted」かを組み合わせることが可能
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
セキュリティサービス部所属。AWS資格全冠。2010年1月からAWSを業務利用してきています。主な表彰歴 2021-2022 AWS Ambassadors/2020-2025 Japan AWS Top Engineers/2020-2025 All Certifications Engineers。AWSのコスト削減やマルチアカウント管理と運用を得意としています。
