GCP Committed Use Discounts（CUD）実践入門｜Compute Engine・Cloud SQL料金を最大57%削減する購入戦略と柔軟性トレードオフの判断基準

GCPにリソースを移行して数か月が経ったころ、「インスタンスをほぼ常時稼働させているのに、請求額がなかなか下がらない」と感じたことはないだろうか。AWS経験者であれば、Reserved Instancesを買えばすぐ割引が効くとわかっているが、GCPではその入口がどこにあるのか、わかりづらい。

GCPの割引体系は、AWSのリザーブドインスタンスと根本的に異なる。まず「使えば自動で割引が入る仕組み（Sustained Use Discounts）」があり、その上に「明示的にコミットすることでより大きく削減できる仕組み（Committed Use Discounts）」が重なっている。この2層構造を理解していないと、コミットメントを無駄に買うか、逆に何もせず割引機会を逃す、どちらかのミスが起きる。

この記事では、GCPのCommitted Use Discounts（以下CUD）について、仕組み・種類・割引率の試算・購入判断フロー・落とし穴まで、インフラエンジニア向けに整理する。AWS RI/Savings Plansと比較しながら読み進めることで、GCP固有の勘所が理解できるようになる。

まず押さえるGCP割引の2層構造 ー SUDとCUDの違い

GCPのCompute Engineには、大きく分けて2種類の割引がある。

・Sustained Use Discounts（SUD）: 月内の稼働時間に応じて自動的に適用される割引。購入・申込み不要。
・Committed Use Discounts（CUD）: 1年または3年のコミットメントを明示的に購入することで得られる、さらに大きな割引。

AWS経験者がGCPに移ると「SUDに相当するものはAWSにない」ため、GCPのSUDを見落としがちだ。逆に「GCPにはRIがない」と思い込んでCUDを使わないケースも多い。両方を組み合わせて最適化するのがGCPコスト管理の基本だ。

Sustained Use Discounts（SUD）の仕組みと対象範囲

SUDはCompute Engineの特定インスタンスファミリーに対して、月内の稼働時間が増えるほど自動で割引率が上がる仕組みだ（2026年10月時点）。月の稼働割合に応じた段階的な割引が加算され、月フル稼働の場合に最大の実効割引率が得られる。

段階割引の加重平均として、月フル稼働のN1インスタンスには実効で最大約30%のSUDが自動適用される。ただし対象インスタンスファミリーは限られている。

・SUD対象: N1・N2・N2D（汎用系）、M1・M2（メモリ最適化系）など
・SUD対象外: E2・Tau T2D（コスト最優先系）、C2・C2D（コンピューティング最適化）、A2・G2（GPU搭載）、Spot VM

E2インスタンスはそもそもオンデマンド価格がN1より安く設定されており、SUDがない代わりに基本料金を下げる設計になっている。「コストを下げるためにE2を選んだ」という環境でCUDを購入しても適用先がなく、後述するよくある落とし穴の一つになる。

Committed Use Discounts（CUD）の2タイプを使い分ける

CUDには「Resource-based CUD（リソースベース）」と「Flexible CUD（支出ベース）」の2種類がある。用途が異なるため、自チームの構成に合わせて選ぶ。

1. Resource-based CUD

特定のリージョン・インスタンスファミリーに対して、vCPU数・メモリ量（GB）をコミットする方式だ。購入後は指定リソースに対して自動的に割引が適用される。

・対象: Compute Engine（N1・N2・N2Dなど）
・コミット単位: リージョン × インスタンスファミリー × vCPU数 × メモリGB
・期間: 1年または3年
・解約: 不可（期間中は変更も不可）

2. Flexible CUD（支出ベースCUD）

1か月あたりの支出額（ドル）をコミットする方式だ。Cloud SQLなど、Resource-based CUDが利用できないサービスにも対応している。

・対象: Cloud SQL、一部のコンピューティングサービス
・コミット単位: リージョン × サービス × 1か月あたりの支出額
・柔軟性: 同一リージョン内であれば複数のインスタンスタイプにまたがって適用可

「どのサービスにResource-based CUDが使えるか」は公式ドキュメントで都度確認することを勧める。サービス追加やCUDの対応範囲は定期的に更新される。

割引率の仕組みと試算（想定例）

2026年10月時点のCompute Engine N2標準（vCPUおよびメモリ）に対するCUD割引率の目安は次のとおりだ。実際の数値はGCP公式料金ページで確認すること。

以下は想定例として、東京リージョン（asia-northeast1）でN2 standard（4 vCPU / 16 GB）を常時10台稼働させるケースを概算したものだ（価格は架空の試算値であり、実際の料金とは異なる）。

【想定例（架空の試算）】
・オンデマンド月額（SUD込みなし）: 約$1,200（10台合計）
・1年CUD適用後: 約$756（約37%削減）
・3年CUD適用後: 約$516（約57%削減）

3年コミットの場合、年間換算で$8,208相当の削減になる計算だが、コミット期間中はインスタンス数を減らしてもCUD料金は変わらない。削減率の大きさと引き換えに柔軟性を失う点を購入前に組織内で合意しておく必要がある。

Cloud SQLへのCUD適用

Cloud SQLにはFlexible CUDが適用できる。Cloud SQL第2世代インスタンスのvCPUとメモリに対して、リージョン別・1年または3年でコミットする仕組みだ。

Cloud SQLはマネージドDBとして常時稼働させることが多く、CUDの費用対効果が出やすいサービスの一つだ。ただし以下の点に注意したい。

・HA構成（高可用性）は2倍のリソースコスト: HA構成のCloud SQLはスタンバイが別途起動するため、コミット量の見積もりにはインスタンス数×2のリソースを考慮する必要がある
・読み取りレプリカはCUD対象外: レプリカは別途課金され、Flexible CUDの適用範囲に含まれない
・ストレージ費用はCUD対象外: CUDで削減できるのはコンピュート（vCPU/メモリ）部分のみ

AWS RI・Savings PlansとのCUD比較

AWS経験者がGCPに来たとき、最も混乱しやすいのはCUDとAWSの仕組みの違いだ。主な差異を整理する。

GCP CUDはAWS Compute Savings Plansより柔軟性は低いが、前払いが不要な点はキャッシュフローに優しい。AWSのRIマーケットプレイスのような「余ったコミットメントを売却する仕組み」がGCPにはないため、購入量の見積もりをより慎重に行う必要がある。

クラウドの購入モデルをAWS・Azure・GCPで横断的に比較した記事も参考にしてほしい: クラウドの購入モデル完全比較｜オンデマンド・リザーブド・スポットをAWS・Azure・GCPで横断整理する実践ガイド

Cloud Recommenderを使ったCUD購入判断フロー

「どれだけCUDを買えばよいか」を自力で計算するのは手間がかかる。GCPにはCloud Recommenderという分析機能があり、過去30日間の使用状況をもとに推奨CUD量と試算削減額を提示してくれる。

1. Recommenderへのアクセス

# Google Cloud Consoleから
# [Billing] → [Cost Management] → [Committed use discounts]
# → [Recommendations] タブで推奨内容が表示される
#
# または gcloud CLIで確認する場合（ Billing Account IDを指定）
# gcloud recommender recommendations list \
#   --recommender=google.billing.CostInsight.Recommender \
#   --location=global \
#   --billing-account=BILLING_ACCOUNT_ID

2. 推奨内容の読み方

推奨画面には「推奨コミット量（vCPU数・メモリGB）」「想定月額削減額」「適用後の推定月額」が表示される。次の点を確認してから購入を決断する。

・使用率の安定性: 過去30日の稼働率が90%以上か。急なスパイクや季節変動がある場合は過剰コミットリスクがある
・プロジェクト成長計画: 向こう1年でインスタンス数が大きく変わる予定があるか
・Billing Account適用範囲: CUDはBilling Accountレベルで管理され、同一Billing Account内の複数プロジェクトで共有される

3. 段階的な購入アプローチ

一般的な注意として、初めてCUDを購入する場合はRecommendations推奨量の50～70%程度からスタートし、3か月後に実際の使用状況を見ながら追加購入するアプローチが安全側の設計だ。CUDは後から追加購入できるが、キャンセルはできない。

よくある落とし穴と現場での注意点

落とし穴① E2インスタンスを使っているのにCUDを購入した

Resource-based CUDはインスタンスファミリー（N1・N2など）に紐づく。E2インスタンスにはSUDもResource-based CUDも適用されない。「コストを下げるためにE2を選んだ」環境でN2向けCUDを買っても適用先がなく、コミット分を無駄に支払う形になる。既存の環境のインスタンスファミリー構成を事前に確認することが必須だ。

落とし穴② CUDがプロジェクトをまたいで効いていないと思った

CUDはBilling Accountに紐づき、同一Billing Account配下のすべてのプロジェクトに自動的に適用される。「プロジェクトAで購入したCUDがプロジェクトBのインスタンスに効いていない」という混乱は、Billing AccountとProjectの関係を誤解していることが多い。Cloud ConsoleのBilling画面でBilling Accountレベルのコミット状況を確認するとよい。

落とし穴③ 開発・ステージング環境を含めた使用量でコミット量を決めた

一般的に、開発・ステージング環境は本番より使用時間が不安定だ。「全環境を合算した平均vCPU数」でコミットすると、夜間や週末にインスタンスを停止する開発環境の分が過剰コミットになる。本番環境の安定稼働ベースラインだけを対象にコミット量を計算するのが安全側の設計だ。

落とし穴④ SUD適用済みの請求額をベースにCUD効果を計算した

SUD割引後のコストをCUD割引前の基準価格と比較すると、CUDの実際の効果が過小評価される。CUDの割引はリスト価格（SUD前）に対して計算されるため、SUDとCUDが重複適用されるわけではない。CUDを購入するとSUDより優先的にCUDが適用される仕組みになっている。

まとめ：GCP CUD購入の判断基準

GCPのコスト最適化において、CUDは「安定的に使い続けるリソース」に対して最も効果的な手段だ。以下の判断基準を参考にしてほしい。

CUDは前払い不要でキャッシュフローに優しい一方、解約できない性質上、過剰購入のリスクが常に伴う。Cloud Recommenderの推奨を確認し、安定稼働実績のあるリソースに絞って購入するのが、GCPコスト最適化の基本方針だ。

FinOpsの全体設計についてはFinOps実践入門も参照してほしい。GCPのコンテナ基盤コスト最適化についてはGoogle Kubernetes Engine（GKE）入門で詳しく解説している。