Google Cloudの Committed Use Discount（CUD）は、1年または3年の利用コミットにより最大で高い割引率が得られる仕組みです。AWSのSavings Plansと似た性質を持ちますが、適用ロジックやリスクの所在が異なるため、AWSの感覚のまま運用すると見落としが発生しがちです。この記事では、CUD運用でよくある3つの盲点を整理します。

盲点1: Flexible CUDとResource-based CUDの適用範囲の違い

CUDには、特定のマシンファミリー・リージョンに紐づく「Resource-based CUD」と、Compute Engine全体に柔軟に適用される「Flexible CUD」があります。Resource-based CUDは割引率が高い一方、コミット後にマシンファミリーを変更すると適用外になり、オンデマンド料金に戻ってしまいます。

確認方法: Billingレポートの「Committed use discount utilization」で、コミット消化率が90%を下回っていないか確認する。低下している場合は直近のマシンタイプ変更・リージョン移行と照合する。

盲点2: プロジェクト間でのコミット共有設定の見落とし

組織内に複数プロジェクトがある場合、CUDは請求先アカウント単位で共有されるのが基本ですが、共有設定（Discount sharing）が無効になっていると、コミットを購入したプロジェクトでしか割引が適用されません。マルチプロジェクト構成の企業では、この設定漏れによって一部のワークロードだけ高いオンデマンド料金のままになっているケースが少なくありません。

確認方法: 請求先アカウントの設定で「Discount sharing across projects」が有効になっているか確認する。無効の場合、意図した範囲か（セキュリティ上の理由で意図的に分離しているか）を確認する。

盲点3: Sustained Use Discount(SUD)廃止後の設計転換

Google CloudはSustained Use Discount（自動適用される継続利用割引）を段階的に見直しており、CUDへの依存度が増しています。SUD前提で「何もしなくても割引が乗る」という感覚のまま放置すると、実際にはコミットしていない分は割引を取りこぼす設計になっています。

確認方法: 過去のコスト最適化方針がSUD前提で設計されていないか棚卸しし、主要なワークロードについて1年コミットのCUD導入を検討する。

まとめ

CUDはAWSのSavings Plansと似て非なる仕組みで、特に「コミット共有設定」と「マシンファミリー変更時の失効」はGCP特有の盲点です。マルチプロジェクト構成の企業ほど設定漏れの影響を受けやすいため、四半期に一度は請求先アカウント単位での棚卸しをおすすめします。