RISP Group Sharing に関するよくある質問

セキュリティサービス部佐竹です。
本日は、先日発表された AWS コスト管理の新機能「Reserved Instances and Savings Plans (RISP) Group Sharing」に関するよくある質問（FAQ）について回答いたします。

はじめに
RISP Group Sharing に関する質問
関連ブログ
- Savings Plan に関するよくある質問
- RDS のリザーブドインスタンス（RI）に関するよくある質問
まとめ

はじめに

先日、「Reserved Instances と Savings Plans の共有設定で Sharing Group が設定可能になりました」というタイトルでブログを記載しました。

blog.serverworks.co.jp

こちらは、2025年11月19日に発表された AWS コスト管理における新機能「Reserved Instances and Savings Plans (RISP) Group Sharing」についての記事です。実環境での動作検証を経た上で、詳細な解説を上記ブログでは行いました。そして本ブログは、上記ブログの続きです。

本機能はリリース直後ではありますが、お客様だけでなく社内からも仕様に関する問い合わせがいくつか私宛に来ております。そこで、2025年11月27日(木)に社内で実施した勉強会*1や、AWS サポートへの仕様確認を通じて得られた情報を元に、現時点での FAQ をまとめました。

本機能は特定のユーザ様に待ち望まれていた機能のため、すぐに利用されたいというそのお気持ちも理解できるのですが、なかなかに設定や仕様が複雑だと感じます。そこで、本 FAQ ブログがその導入検討の一助となれば幸いです。

本質疑の内容は2025年12月1日時点の情報を元にしております。以後アップデートによって仕様変更が入る可能性がありますことご留意ください。

「アカウントレベルの設定」が優先されます。

従来から存在する「割引共有の無効化（Discount sharing disabled = Deactivated）」に設定されているアカウントは、Sharing Group に含まれていたとしても、グループ内外に関わらず割引共有は行われません。

Sharing Group 機能は、あくまで「割引共有が有効（Activated）」になっているアカウント群の中で、さらに適用範囲をコントロールするための機能です。

先のブログでも記載した通り Both purchasing and benefit receiving accounts must have sharing activated to share discounts*2 の前提条件を満たす必要があります。

いいえ、含めることはできません。

コストカテゴリーの仕様上、管理アカウント（Payer）を含めることができないため、Payer で購入した RI/SP を特定のグループに優先的に割り当てるといった制御はできません。Payer は常にグループ外の扱いとなります。

原則として管理アカウント（Payer）ではリソース稼働や RI/SP の購入を行わないことが推奨されますが、もし Payer で RI/SP を購入＆運用されている場合は本機能の適用外となる点にご注意ください。

補足：コストカテゴリーの仕様上設定に含めることができないだけで、これまで通り、つまり Open Sharing の状態で管理アカウントの持つ RI/SP はシェアされます。

いいえ、設定画面で選択できるコストカテゴリーはたった1つのみです。複数の設定はできません。

ただし、「1つのコストカテゴリー」の中で、複数の「値（グループ）」を定義することは可能です。

先のブログからの引用となりますが、以下の図の通りです。

「コストカテゴリー」の設定で、グルーピングを行うことができます。これを用いて、各グループ（青色の枠）を複数作成することが可能です。

実際のコストカテゴリーの設定画面は上画像の通りで、このようにグループを複数並列して設定することで、複数のグループを用いた共有グループを作成して RI/SP をシェアできます。

質問4. 設定を変更した場合、いつから適用されますか？

月末時点の設定が、その月全体の請求に対して遡って適用されます。

RI/SP の共有設定全般に言えることですが、月中に何度設定を変更しても、最終的な請求額は「月末（UTC時間 23:59:59）時点」の設定に基づいて計算されます。

この仕様を利用して、月内で一時的に設定を変更し、Cost Explorer で適用状況（グラフの波形など）を確認した後、月をまたぐ前に設定を戻すといった検証も可能です。ただし、戻し忘れには十分ご注意ください。

質問5. Cost Categories のルールの「順序」は共有順序に影響しますか？

いいえ、影響しません。

Cost Categories の Priority (上から下に向かう順序) はあくまで「アカウントがどのグループ（値）に属するか」を決定するための評価順序であり、RI/SP の適用順序（グループ間の優先度）ではありません。

各グループは並列なサイロ*3として扱われます。

具体例として、「Prioritized」モードにおいて、あるグループで使い切れなかった余剰分は、特定の別のグループへ優先的に流れる（Group A → Group B）のではなく、一律に自分のグループ外の「Open Sharing（全体共有）プール」へと放出されます。これは、「所属する自分のグループ」以外は「全て外 (Open Sharing)」という扱いだからです。

質問6. コストカテゴリーで「未分類（Uncategorized）」となったアカウントはどう扱われますか？

どちらのモードにおいても、「未分類」という名称の1つのグループ（暗黙のグループ）として扱われます。念のため、モード別に動きを見ていきましょう。

「未分類」は、定義されたグループ（Group A, Group Bなど）と並列のグループとして扱われます。余剰のディスカウント権は「Open Sharing（全体共有）プール」へ放出され、自分が所属するグループ以外の他のグループと共有されます。

グループ定義	アカウント
グループ A	アカウント 1, 2, 3
グループ B	アカウント 4, 5, 6
未分類グループ	アカウント 7,8,9,10,11,12,13,14,15,16

グループ	共有の振る舞い
グループ A	アカウント 1〜3 に共有 → 余剰分はアカウント 4〜16（グループ B と未分類）に開放される。
グループ B	アカウント 4〜6 に共有 → 余剰分はアカウント 1〜3 および 7〜16（グループ A と未分類）に開放される。
未分類グループ	アカウント 7〜16 に共有 → 余剰分はアカウント 1〜6（グループ A とグループ B）に開放される。

「未分類グループ」は、定義されたグループと並列の独立したサイロとして扱われます。グループ内で使い切れなかった余剰のディスカウント権は、他のグループとは一切共有されません。

グループ定義	アカウント
グループ A	アカウント 1, 2, 3
グループ B	アカウント 4, 5, 6
未分類グループ	アカウント 7,8,9,10,11,12,13,14,15,16

グループ	共有の振る舞い
グループ A	アカウント 1〜3 に共有 → 余剰分は他に移動しないため、失効（無駄）となる。
グループ B	アカウント 4〜6 に共有 → 余剰分は他に移動しないため、失効（無駄）となる。
未分類グループ	アカウント 7〜16 に共有 → 余剰分は他に移動しないため、失効（無駄）となる。

※「未分類グループ」のアカウント数が多いのは、未分類グループには「残り全てが入る」イメージで記載しているためです

質問6 の背景

何故このような疑問が出るのか？の背景ですが、Restricted の場合に以下のような懸念があったためです。

それは挙動として「未分類（Uncategorized）」は「定義されたグループのメンバー」ではないため、RI/SP の共有対象から完全に除外される（グループ内共有も、他からの共有も受けられない）のでは？という懸念です。

もしこの挙動となる場合、② Restricted モードで RI/SP を共有させたいアカウントは、「必ずコストカテゴリ上で何らかの具体的なグループ（値）に分類しなければならない（未分類にしてはならない）」という運用上の制約が実際には発生する可能性がありました。

この点を AWS サポートに確認したところ、② Restricted モードでも「未分類（Uncategorized）」は暗黙のグループとして扱われるため、完全に除外されるのではなく、未分類同士で1つの暗黙的なグループとして機能するという回答を得ました。一安心です。

質問7. Restricted モードの場合、グループ内で余った RI/SP はどうなりますか？

そのグループ内で使い切られなければ、無駄（ディスカウント権の失効）になります。

Restricted モードは「グループ外へ一切出さない」設定であるため、たとえ組織内の別のアカウント（グループ外）でオンデマンド利用が発生していても、適用されません。このため、導入には特に慎重な設計が必要です。

質問8. 本機能（Sharing Group）を利用するメリットは何ですか？

アカウント構造（OU）を変更することなく、論理的なグループ単位でのコスト最適化が可能になる点です。

従来、特定の範囲で共有を閉じるには「共有無効」にするしかありませんでしたが、本機能により「部や課単位での共有（Restricted）」や「自部署優先だが余れば全社貢献（Prioritized）」といった、組織の実態に合わせた柔軟な制御が可能になります。

質問9. 利用する際のデメリットやリスクはありますか？

設計が複雑になり、組織全体でのコスト最適化効果が低下するリスクがあります。

優先グループを設定することで、本来最もコスト最適化効果が高い（＝最もコスト削減になる）リソースへの適用が歪められ、結果として組織全体でのコスト最適化効果（割引）が低下する可能性があります。

このため、マネジメントコンソール上では事前に影響を把握するよう「Pricing Calculator」の利用を再三求められます。

また先に記載した通り、その月の設定の確定は月末時点のため、月内での検証時点でコスト最適化効果に著しい影響があった場合には、「月末までに元通りに戻す」などの十分な準備検証期間が必要です。

質問10. RI と SP で異なるグループ設定を行うことはできますか？

いいえ、できません。Sharing Group の設定は RI と SP で共通（セット）です。

「RDS の RI は特定の部署に寄せたいが、Savings Plans は全社で共有して無駄なく使いたい」といった、RI と SP で異なるスコープを設定したい場合、本機能単体では実現できません。

質問11. SP は全社共有、RI だけ特定部署に優先適用したい場合の良い方法はありますか？

「SP 購入用アカウント」と「RI 購入用アカウント」を分離することで実現可能です。

質問10で回答した通り設定自体は分離できません。しかし、以下のような構成を取ることでハイブリッドな運用が可能になります。

SP 購入用アカウント: どの Sharing Group にも所属させない（Open Sharing のまま全社共有させる）
RI 購入用アカウント: 特定の Sharing Group に所属させる（そのグループ内で優先適用させる）

このように購入元のアカウントをサービスによって使い分ける戦略（アカウント設計）を行えば、Savings Plans は「戦略1」のまま、コスト最適化効果が一定である RI を特定のアカウントに寄せるといった制御が実現可能となります。

参考：Savings Plans 購入戦略改善版

#	シナリオ	SP 購入アカウント	割引共有
1	組織全体で最大効率化	単一の購入専用アカウント	Open Sharing (共有)
2	各アカウントで最適化 + 無駄回避	各アカウント	Open Sharing (共有)
2-改	部署優先 + 無駄回避	部署別購入専用アカウント	① Prioritized SG
3	各アカウントで最適化 (独立)	各アカウント	無効 (共有なし)
3-改	部署別のサイロ化 (部署独立)	部署別購入専用アカウント	② Restricted SG

質問12. 運用観点で、AWS アカウントを新規に払い出した場合に必要な作業はありますか？

はい、「コストカテゴリー」の定義更新が必要となる場合があります。

新規に作成された AWS アカウントは、コストカテゴリーのルール定義に合致しない場合、自動的に「未分類（Uncategorized）」として扱われます。

特に、アカウント ID 指定でコストカテゴリーを定義する必要があるため、コストカテゴリーの設定画面で新規のアカウント ID を既存のグループに追加する（もしくは新たなグループを作成する）作業が手動で必要になります。

もし、本作業を忘れて「未分類」のまま放置された場合、質問6で回答した通りの挙動（Prioritized なら Open Sharing プール扱い、Restricted なら暗黙の未分類グループ扱い）となります。意図しない共有（または共有不足）を防ぐため、アカウント払い出しフローに「コストカテゴリーのメンテナンス」を組み込むことを推奨します。

いいえ、利用できません。

コストカテゴリーの作成画面には「Automatically group costs by account or tag (Inherit rule)」という、タグを利用し自動的にグループ化する設定も存在しています。しかし「RISP Group Sharing」のためのコストカテゴリーとしては、この機能はサポートされていません。

その理由は「RISP Group Sharing」の制約である「1つのアカウントは1つの共有グループにしか所属できない（Each account can only belong to one sharing group）」に抵触するためです*4。タグベースの分類では、同一アカウント内のリソースごとに異なるタグが付与される可能性があり、結果として「1つのアカウントが複数のグループに所属する」状態になり得るためです。

したがって、コストカテゴリーのルール作成時には、必ず「Manually define how to group costs」を選択し、Dimension として「Account」を指定して、アカウント ID 単位でグルーピングを行う必要があります。

まとめ

本ブログでは、先日発表された AWS コスト管理の新機能「Reserved Instances and Savings Plans (RISP) Group Sharing」に関するよくある質問（FAQ）についてその回答をまとめました。

本機能はマニアックで高度な機能ではありますが、使いこなせば「部署ごとの予算管理」と「全社的なコスト最適化」のバランスをより細かく調整できる強力なツールになります。

繰り返しとなりますが、まずは「① Prioritized」モードからはじめ、スモールスタートで検証されることをお勧めします。

それではまたお会いしましょう。

*1:私が継続して行っている第12回のコスト削減塾のテーマが「RISP Group Sharing」でした

*2:和訳: RI/SP を購入したアカウントとディスカウント権を共有で受け取るアカウントは、共にそれぞれ Activated で維持される必要があります

*3:貯蔵庫・格納庫

*4:この仕様は念のため AWS サポートにも確認済です