CUDとSP/RIは「似た割引」ではない — 率で比べるのをやめて、4つの軸で並べ直す

以前、Savings Plansの盲点3つとCUDの盲点3つを短い記事で書きました。どちらもその仕組みの中で起きる取りこぼしの話で、2つを横に並べてはいません。

ただ、実務で聞かれるのはむしろ横並びのほうです。「AWSでSavings Plansを使っているが、Google Cloudに寄せたらCUDで同じことができるのか」「どちらのほうが有利なのか」。

この記事では横に並べます。ただし、率では並べません。

なぜ率で並べないのか

AWSもGoogle Cloudも、公式サイトにコミット型割引の割引率レンジを掲載しています。並べようと思えば並べられます。それでもこの記事でやらないのは、3つの理由からです。

1. 公表されている率は条件付きの上限で、単独の数字として比較できない。 期間（1年か3年か）、前払いの有無、対象の絞り込み方で率は変わります。「AWSは最大◯%、Google Cloudは最大◯%」と並べた表は、両端の最も条件の厳しい値を突き合わせているだけで、自社に当てはまる保証がありません。

2. 率が同じでも、掛かる先が違えば結果が違う。 これが後述の軸1です。同じ「1年コミットで◯%引き」でも、コミットの対象がインスタンス構成なのか支出額なのかで、構成を変えた瞬間の挙動がまったく違います。

3. 実際に判断を分けているのは、率ではなく「外れたときに何が起きるか」だった。 私たちが請求書を分析していて、コミット型の割引が想定どおりに効いていない案件に共通していたのは、率の選択ミスではありません。適用範囲から外れていた、買ったアカウントに閉じていた、満了に気づいていなかった、のいずれかです。

そこで、率の代わりに次の4軸で並べます。

4つめは当社の商売の話なので最後に置きますが、切り替えを検討する側にとっては、実はここがいちばん見落とされます。

軸1: 何に紐づけてコミットするのか

この軸で見ると、両クラウドの仕組みは**「支出額にコミットするもの」と「リソースの中身にコミットするもの」の2種類**に整理できます。ブランド名で覚えるより、この分け方のほうが実務では効きます。

AWS公式ドキュメントの記載で並べると、こうなります。

Reserved Instancesはさらに2つの軸で分かれます。Standard RI と Convertible RI（Standardのほうが割引が大きく、Convertibleは他のConvertible RIへの交換ができる）、そして Regional RI と Zonal RI（Regionalはリージョン全体に適用されインスタンスサイズの柔軟性がある、Zonalは指定したアベイラビリティゾーンに紐づきキャパシティ予約が付く）。ここで注意したいのは、Zonal RIのキャパシティ予約は割引とは別の価値だという点です。詳しくはマルチアカウント環境でのRI/SP共有の記事に書きました。

Google Cloud側は、Compute Engineの公式ドキュメントで2種類が示されています。

ここが実務でいちばん効く違い

表を眺めていると気づきますが、AWSのSavings Plansは4種類とも「$/hourの支出コミット」です。 種類が分かれている理由は、コミットの方式が違うからではなく、どのサービス群に効くかが違うからです。EC2 Instance Savings Plansだけは、そこにリージョンとインスタンスファミリーの固定という条件が追加で付きます。

対してGoogle CloudのリソースベースCUDは、金額ではなくリソースの量でコミットします。 「毎時◯ドル使います」ではなく「このリージョンでこのマシン構成のvCPUを◯個分使います」という約束です。

この違いが、構成変更に対する強さをそのまま決めます。

• 支出額コミット（Compute SP / Database SP / Compute Flexible CUD）は、中身が変わっても金額さえ出ていれば消化されます。インスタンスタイプを変えても、Graviton系に移しても、対象サービス群の中なら効き続けます
• 属性・リソース量コミット（RI / EC2 Instance SP / リソースベースCUD）は、割引が深い代わりに、指定から外れた瞬間に適用されなくなります

Savings Plansの盲点1とCUDの盲点1で書いたのは、どちらも後者の話でした。この2つの記事は、同じ1つの構造を別々のクラウドで書いていたことになります。

だから「AWSからGoogle Cloudへ」「Google CloudからAWSへ」と考えるときに移植すべきなのは、ブランド名の対応関係ではありません。今使っているのが支出額コミットなのか、リソース量コミットなのかです。ここを取り違えたまま移すと、移行先で同じ盲点を踏み直します。

2025年12月にAWS側が1種類増えている

コミット型の話をするとき、多くの社内資料が「Savings PlansはComputeとEC2 Instanceの2種類（＋SageMaker）」という前提で書かれています。この前提は2025年12月に更新されました。

AWSは2025年12月2日に Database Savings Plans を発表しています。対象はAurora・RDS・DynamoDB・ElastiCache・DocumentDB・Neptune・Keyspaces・Timestream・DMS。公式の発表では1年コミット・USD/hourでの支出コミット・前払いなしとされ、対象サービスの適格な利用に自動適用されると説明されています。

ここは検討に直結します。RDSやElastiCacheのReserved Instancesを持っている会社にとっては、同じ支出に対する選択肢が1つ増えたことになるからです。

ただし注意点があります。この発表に、Reserved Instances / Reserved Nodesを置き換えるという記述は見当たりませんでした。 併存するのか、どちらが優先適用されるのかについても、公式に明記された説明を確認できていません。「RIの代わりに使えるもの」と読まないでください。 既にRIを持っている構成で重ねて買うと、Savings Plansの盲点3で書いた二重最適化と同じことが、データベース側で起きる可能性があります。購入前にAWSまたは販売事業者に確認すべき項目です。

軸2: 買った割引は、組織の中の誰に届くのか

2つめの軸は「率」の話とはまったく独立しています。同じ率で買っても、届く先が違えば実効は違うからです。

この論点はマルチアカウント環境でのRI/SP共有で詳しく書いたので、ここでは横並びの部分だけ抜き出します。

共有の単位が「請求の器」である点だけが共通で、その先は別物です。 AWSはOrganizations、Google CloudはCloud Billing account。どちらも技術構成ではなく請求のまとまりに紐づいています。

一方、適用順序の考え方は揃っていません。AWSは購入アカウント優先が明確ですが、Google Cloudの公式説明は購入プロジェクトを優先するとは読めない書き方です。AWSの「まず自分のアカウントで使われる」という感覚をGoogle Cloudに持ち込むと外れます。

実務での順序も、この軸では1つだけはっきりしています。共有設定を触る前に、購入した側で余りが出ているかを見てください。 購入アカウントが買った分を使い切っている間は、共有をどう設定しても他アカウントには回りません。「共有をONにしたのに開発環境の請求が下がらない」という相談は、たいていこれです。

軸3: 期間が終わったとき、請求はどうなるのか

3つめは、検討中はほぼ話題に出ないのに、実際にいちばん請求額を動かす軸です。

AWSの公式ドキュメントで確認できた範囲では、こうです。

• Savings Plansの期間が終わると、そのプランによる被覆が止まります。 以後、カバーされていない利用はオンデマンド料金で課金されます
• 自動更新の設定は、AWS公式ドキュメントで確認できませんでした。 更新するための手順（購入をキューに入れる操作）が用意されているという記述はあり、更新は自分で行う操作として設計されていると読めます
• Reserved Instancesも同様に、期間終了で割引の適用が止まり、カバーされていない利用はオンデマンド料金に戻ります。自動更新の設定は公式資料で確認できませんでした
• Savings Plansのコミットは時間単位（$/hour）で、その時間に使い切らなかった分は翌時間に繰り越されません。 使っても使わなくてもコミット額は請求されます

Google Cloud側も、期間が終わるとコミットメントは失効し、以後は別の有効なコミットがない限りオンデマンド単価での課金に戻ります。 ここはAWSと同じ考え方です。ただし自動更新のオプションは公式ドキュメントで確認できませんでした。 また、コミット費用は期間分が発生するとされている一方、期間途中で解約できるかについては公式に明記された記述を確認できていません。 3年コミットを検討するときは、ここを事前に確認してください。

満了日は「請求が跳ねる日」として管理する

ここから出てくる実務上の帰結は1つです。コミット型の満了日は、割引が終わる日ではなく、その利用分がオンデマンド単価に戻る日として扱ってください。

見積の場面で頻繁に起きる誤りがあります。「RIの月額料金がなくなるから、その分だけ請求が下がる」という組み方です。これは逆です。RIやCUDでカバーされていた利用は、満了後に消えるわけではなく、オンデマンド単価で課金され直します。 満了後のシナリオを試算するときは、カバーされていた利用量を全額オンデマンドで積み直すのが正しい組み方です。当社が満了後の比較を出すときも、この置き方をしています。

そしてもう1つ。種類が増えるほど、満了日も増えます。 Savings Plansが4種類になり、Google Cloud側にもリソースベースとFlexibleの2系統がある以上、「うちのコミットの満了日一覧」が社内に無い状態は、それ自体がリスクです。請求書から割引の正味効果を読む記事にも書きましたが、満了日は請求書からは読めません。コンソール側で取るしかありません。

軸4: リセラー割引の分母にどう効くか

最後の軸は当社の土俵の話です。ただし、これは切り替えを検討する側にとっても実利のある軸です。コミット型の割引を持っているかどうかで、リセラー割引が掛かる分母がはっきり変わるからです。

前提として、リセラー割引が掛かるのは請求総額ではなく割引対象額です。この分母の作り方はAWS編とGoogle Cloud編に書きました。

4軸で見てきた仕組みは、どれも分母を削る方向にしか動きません。 すでに割引が効いている部分に、リセラー割引を重ね掛けできないためです（この扱いはリセラー各社の解説にもとづく整理で、AWS・Google Cloudの公式にこの定義が公開されているわけではありません）。違うのは削る量ではなく、請求書のどこに現れるかです。

Savings Plansのコミット費用がプラス行として立つ点は、請求書からSPとRIを見分ける記事で扱いました。RIが厄介なのは、カバーされた利用が$0で計上されるため、請求書だけを見ても分母を確定できないことです。

自社の集計で見えていたこと

この軸は、実際の請求書で確認できています。実案件9件の割引対象額を集計した記事で、コミット型の有無で分けたところ、分布がきれいに割れました。

n=9の小さな集計なので、比率そのものを一般化しないでください。それでもこの分かれ方自体は、軸1〜3で見てきた構造から素直に説明がつきます。コミット型で押さえた部分は、リセラー割引の対象から外れるからです。

この事実は当社にとって都合の悪い方向にも効きます。すでにコミット型でよく最適化されている会社ほど、リセラー割引で追加できる余地は小さくなります。 ただし逆側もあって、コミット型を1つも持たない構成では、分母が請求総額とほぼ一致します。予約という仕組みが存在しないデータ転送・ストレージ・ロードバランサの比率が高い会社が、これに当たります。

つまり軸1〜3の設計は、そのまま軸4の答えを決めています。 「コミット型を厚く積むか、フラットな割引に寄せるか」は、本来この4軸をまとめて見て決める話です。

4軸を1枚に

この表に率の行がないことが、この記事の主張です。上の6行が違えば、率が同じでも結果は違います。

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

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

なおSustained Use Discount（SUD）については、Compute Engineの公式ドキュメントに現在も記載があり、廃止・終了のアナウンスは確認できませんでした。 「SUDはもう無くなった」という前提で書かれた社内資料があれば、そこは取り直してください。

公式ドキュメントで確認できた範囲では、SUDはCompute Engineの対象リソースに自動適用され、手動での有効化は不要です。適用先にはCompute EngineおよびGoogle Kubernetes Engineが作成したVMが含まれます。一方、App Engine（standard / flexible）およびDataflowが作成したVMには適用されないと明記されています。つまりSUDは「Google Cloud全体に自動で乗る割引」ではなく、VMの作られ方で適用可否が変わる仕組みです。他のサービスにも同じものがあると仮定すると外れます。

まとめ

• コミット型割引を率で並べても判断材料にならない。公表値は条件付きの上限で、掛かる先も届く先も違う
• 軸1（適用単位）: AWSのSavings Plansは4種類とも$/hourの支出コミットで、違いは対象サービス群。Google Cloudのリソースベースは金額ではなくリソース量でコミットする。移植すべきはブランド名の対応ではなく「支出額コミットかリソース量コミットか」
• 2025年12月2日にDatabase Savings Plansが追加（Aurora・RDS・DynamoDB・ElastiCache他、1年・USD/hour・前払いなし）。ただしRI / Reserved Nodesを置き換えるとは公式に書かれていない
• 軸2（共有）: 共有の単位が請求の器である点だけが共通。AWSは購入アカウント優先、Google Cloudは購入プロジェクト優先とは公式に読めない
• 軸3（満了）: 満了は「割引が終わる日」ではなく「その利用がオンデマンド単価に戻る日」。満了後の試算は全額オンデマンドで積み直す。自動更新の設定は両クラウドとも公式に確認できなかった
• 軸4（分母）: コミット型はいずれも割引対象額を削る。違うのは量ではなく請求書での現れ方で、RIは$0計上のため請求書だけでは分母を確定できない
• 実案件9件では、コミット型を1つも持たない2件が100%、1つ以上持つ6件が46.2〜72.9%だった

「CUDとSavings Plans、どちらが得ですか」と聞かれたら、返すべき問いは率ではありません。構成をこの先1〜3年変えない自信があるか。買った割引を誰に届けたいか。満了日を管理する体制があるか。 この3つが決まれば、選ぶべきものはほぼ決まります。

CloudCutの場合

当社がお出ししているのはAWS / Google Cloudの請求代行を通じた10%以上の削減¹ですが、この10%は請求総額に対する削減率で、割引率そのものが掛かるのは請求総額ではなく、軸4で書いた割引対象額です。コミット型の割引を厚く持っている構成ほど、この分母は小さくなります。 都合の悪い話ですが、先に申し上げるようにしています。

そのためご相談をいただいた際は、率の話に入る前にコミットの種類・満了日・どのアカウント（プロジェクト）で消化されているかを確認しています。この3点が出ないと、切り替えの適切な時期も、そもそも効果があるかどうかも出せません。

「今のコミット構成を整理したい」「満了日が近いが、そのまま更新すべきか」といったご相談だけでも承っています。お切り替えのご検討とは切り離してお答えできます。

ご相談はこちらから。