クラウドの購入モデル完全比較｜オンデマンド・リザーブド・スポットをAWS・Azure・GCPで横断整理する実践ガイド

オンプレミスでサーバーを調達するとき、私たちは「物理機を購入するか、リースするか」という判断をしてきた。クラウドはこの仕組みを根本から変え、同じスペックの仮想マシンを「秒単位の従量課金」から「1～3年の長期予約」「空き枠を活用した格安利用」まで、複数の購入形態から自由に選べるようにした。

ところがこの自由度が、逆に混乱を招いている。AWSには「オンデマンド」「リザーブドインスタンス」「Savings Plans」「スポットインスタンス」が混在し、AzureとGCPではそれぞれ異なる名称で似た仕組みが提供されている。「どれが自分のワークロードに合うのか」を判断できないまま、デフォルトのオンデマンドを使い続けているチームは少なくない。

この記事では、クラウドの主要な購入モデルをAWS・Azure・GCPで横断整理し、現場のインフラエンジニアが「このワークロードにはどのモデルを選ぶか」を即断できるよう解説します。割引率・利用条件・中断リスクの3軸で比較し、実務での判断フローまでカバーします。

なぜクラウドの購入モデルは複雑なのか

オンプレでは、サーバーはほぼ「買い切りか、リースか」の2択だった。運用コストは人件費と電気代が主で、台数が増えると単価が少し下がる程度だった。

クラウドが異なるのは、データセンターの余剰キャパシティを多様な方法で販売することで収益を最大化するというビジネスモデルにある。AWS・Azure・GCPは、同じ物理インフラを次の3タイプの「顧客」に売る。

・急に使いたい顧客（オンデマンド）: 割高な料金を受け入れる代わりに、いつでも使えて即解約できる
・長期契約する顧客（リザーブド）: 一定期間使い続けることを約束する代わりに、大幅値引きを受ける
・空き枠を安く使いたい顧客（スポット）: データセンターの余剰時間を格安で使う代わりに、いつ中断されてもよい

この3タイプの顧客向けに料金体系を設計したのが、クラウドの購入モデルだ。各クラウドが独自の名称と条件を付けているため複雑に見えるが、骨格は共通している。

4つの主要購入モデルを整理する

1. オンデマンド（On-Demand / Pay-as-you-go）

最もシンプルな課金モデルで、使った分だけ払う。事前契約不要、いつでも起動・停止できる。その分、後述のリザーブドやスポットと比べると単価は最も高くなる。

どんなときに使うか
・初期検証・PoC環境: 使用期間が読めないため、無駄な予約コストを避けたい
・突発的なピーク対応: イベント期間中だけ一時的にスケールアウトする
・開発・テスト環境: 平日日中だけ稼働させるような不規則な利用パターン

オンプレのオンプレ比較でいえば、ベアメタルサーバーをデータセンターで「日単位レンタル」するイメージに近い。

2. リザーブド（Reserved Instances / Azure Reservations / Committed Use Discounts）

1年または3年の使用を事前コミットすることで、オンデマンド比で最大72～73%の割引を受けられるモデルだ。支払い方式は「全額前払い」「一部前払い」「前払いなし（月払い）」の3通りが選べ、全額前払いにするほど割引率が上がる。

各クラウドでの呼称は以下の通り。

クラウド	名称	割引率の目安	期間
AWS	リザーブドインスタンス（RI）	最大72%（2026年9月時点）	1年 / 3年
Azure	Azure Reservations（予約）	最大72%（2026年9月時点）	1年 / 3年
GCP	Committed Use Discounts（CUD）	最大57%（2026年9月時点）	1年 / 3年

注意点
リザーブドは「コミットした分の料金は使わなくても発生する」ため、常時稼働しているワークロードに限定して予約するのが鉄則だ。Webアプリの本番環境・DBサーバー・監視基盤など、24時間365日動き続けるものが対象になる。

AWSのリザーブドインスタンスとSavings Plansの使い分けについては、別記事「EC2コスト削減 リザーブドインスタンスとSavings Plansの違いと選び方」で詳しく解説している。

3. スポット（Spot Instances / Azure Spot VMs / Spot VMs）

クラウドデータセンターの余剰キャパシティを格安で利用できるモデルだ。オンデマンド比で最大90%の割引になる場合もあるが、クラウド事業者側の都合（空き枠がなくなる）で突然中断されるというリスクがある。

クラウド	名称	割引率の目安	中断通知
AWS	スポットインスタンス	最大90%（2026年9月時点）	2分前通知
Azure	Azure Spot VMs	最大90%（2026年9月時点）	30秒前通知
GCP	Spot VMs（旧: プリエンプティブルVM）	最大91%（2026年9月時点）	30秒前通知

中断リスクを許容できるワークロードであれば、コスト削減効果は圧倒的だ。バッチ処理・機械学習の学習ジョブ・CI/CDのビルドパイプラインなど、途中で止まっても再実行できる処理が主なターゲットになる。

AWSスポットインスタンスの実践的な活用方法は「AWSスポットインスタンス入門 EC2料金を最大90%削減する実践活用ガイド」を参照してほしい。

4. Savings Plans（AWS独自の柔軟予約モデル）

AWSが2019年に導入した購入モデルで、リザーブドインスタンスよりも柔軟なコミットが可能な点が特徴だ。「1時間あたり$X分の使用量をコミットする」という形で予約するため、EC2のインスタンスタイプやリージョンをまたいで割引が適用される。

種別	適用範囲	最大割引率
Compute Savings Plans	EC2・Lambda・Fargate（インスタンスタイプ・リージョン問わず）	最大66%
EC2 Instance Savings Plans	特定ファミリー・リージョンのEC2に限定	最大72%

AzureとGCPにはSavings Plansの完全な相当品はなく、AWSがこの点で柔軟性に優れている。GCPは「Sustained Use Discounts（継続利用割引）」という自動適用の割引制度があり、月の使用量に応じて自動的に割引が増えていく仕組みを持つ。

AWS・Azure・GCPの購入モデル横断比較表

購入モデル	AWS	Azure	GCP
従量課金	オンデマンドインスタンス	従量課金（Pay-as-you-go）	オンデマンド
長期予約（明示的コミット）	リザーブドインスタンス / Savings Plans	Azure Reservations	Committed Use Discounts（CUD）
自動割引（使用量連動）	なし（Savings Plansが近い）	なし	Sustained Use Discounts（SUD）
余剰枠利用（中断あり）	スポットインスタンス	Azure Spot VMs	Spot VMs
中断通知時間	2分	30秒	30秒
コミット期間	1年 / 3年	1年 / 3年	1年 / 3年
柔軟な予約モデル	Compute Savings Plans	なし（RIに相当）	なし（CUDに相当）

GCPのSustained Use Discounts（継続利用割引）は他クラウドにない独自の仕組みで、月の使用時間が長いほど自動的に割引率が上がる。月の25%を超えると段階的に割引が始まり、フル稼働（100%）の場合はオンデマンド比で最大30%の自動割引が適用される。予約コミット不要で自動適用されるため、GCPを使い始めて間もない段階でも恩恵を受けられる。

実務での選び方 ― 3つのシナリオ別判断フロー

シナリオ1: 本番環境の常時稼働サーバー

DBサーバーや24時間動いているWebアプリのバックエンドなど、停止できない本番系にはリザーブドモデル一択だ。

判断フロー:
・使用期間が1年以上確定しているか？ → Yes → リザーブドを選ぶ
・インスタンスタイプを変更する可能性があるか？ → Yes → AWS Compute Savings Plans（柔軟性が高い）を選ぶ
・インスタンスタイプが固定されているか？ → Yes → EC2 Instance Savings Plans またはリザーブドインスタンスを選ぶ

AzureとGCPは柔軟な予約モデルが少ないため、Reservations / CUDのスコープ設定（サブスクリプション全体 vs リソースグループ）を適切に選ぶことが重要になる。Azure Reservationsの詳細については「Azure Reserved VM Instancesコスト最適化入門」を参照してほしい。

シナリオ2: バッチ処理・データ変換・ML学習ジョブ

夜間バッチや機械学習モデルのトレーニングなど、中断→再実行が可能な処理にはスポットモデルが最適だ。

判断フロー:
・処理が途中で止まっても再開できるか？ → Yes → スポットを使う
・中断時のチェックポイント機能が実装済みか？ → No → まずチェックポイントを実装してからスポットへ移行する
・完了までの期限が厳しいか？ → Yes → スポット×オンデマンドの混在構成（AWSならMixed Instances）を検討する

スポットの中断通知時間の差（AWS 2分 vs Azure/GCP 30秒）は大きな違いだ。チェックポイント保存のI/Oに2分以上かかる処理では、Azureのスポット運用を慎重に設計する必要がある。

シナリオ3: 開発・ステージング環境

平日日中だけ使う開発環境は、予約コミットすると休日の課金が無駄になる。オンデマンド + 自動停止スケジュールの組み合わせが基本だ。

・夜間・休日は停止しているか？ → 停止していない → AWS Instance Schedulerや Azure Auto-shutdownを設定してオンデマンドの無駄使いを止める
・1日8時間稼働が安定している場合: 月間稼働率が約33%であり、リザーブドの損益分岐点（一般に50%以上）を下回るため、オンデマンドのままが安い

よくある落とし穴と対処法

落とし穴1: リザーブドを使わないまま課金が続く

リザーブドインスタンスは「インスタンスを起動しなくても課金が発生する」設計だ。コミット期間中にインスタンスを削除しても、料金は停止しない（全額前払いの場合はすでに支払い済み）。

対処法: リザーブドの適用状況をAWS Cost ExplorerやAzure Cost Managementで定期的に確認し、未使用RIはマーケットプレイスでの売却や、スコープの変更で他リソースに適用する。

落とし穴2: スポットの中断に備えていない

スポットインスタンスを単純にオンデマンドの代替として使ってしまい、中断通知を受け取ったときの処理が未実装というケースがある。中断が発生するとジョブが丸ごとやり直しになる。

対処法: スポットを使う前に、処理のべき等性（同じ処理を何度実行しても結果が変わらない設計）とチェックポイントからの再開機能を実装する。AWSではEC2 Spot Interruptionsを捕捉するEventBridgeルールを設定し、終了前に必要なクリーンアップを自動実行できる。

落とし穴3: GCPのSUDとCUDを二重で適用しようとする

GCPではSUDとCUDは同じリソースに同時適用されない。CUDを購入したリソースはSUDの対象外になる。CUDの割引率（最大57%）がSUDの上限（30%）を上回るため、長期稼働が確実ならCUDを優先すべきだが、どちらが得かをケースごとに試算する必要がある。

落とし穴4: FinOpsの体制が整う前に大量予約する

インフラ担当が個人判断で大量のリザーブドを購入し、後から使用量が変化してROIが悪化するケースが多い。本来はFinOpsの実践として、購入前に3か月以上のオンデマンドの実績を取得し、稼働率を確認してからコミット量を決めるプロセスが必要だ。

詳しくは「FinOps実践入門｜タグ運用ルール・予算アラート・Reserved Instance最適化」を参照してほしい。

本記事のまとめ

クラウドの購入モデルは「オンデマンド・リザーブド・スポット」の3軸が基本で、AWSが「Savings Plans」という柔軟な中間形態を加えて4種類となっている。GCPにはSUDという自動適用の割引が独自に存在する。

ワークロードの特性	推奨モデル
本番・常時稼働・使用期間1年以上	リザーブド / Savings Plans / CUD
中断・再実行可能なバッチ・ML学習	スポット
開発・検証環境・不規則な利用	オンデマンド + 自動停止スケジュール
インスタンスタイプ変更の可能性がある本番	AWS Compute Savings Plans
GCPで長期稼働が確実	CUD（SUDの上限より割引率が高い）

購入モデルの選定はコスト最適化の第一歩だ。オンプレのサーバー調達と同様、「いつ、どれだけ、どのくらい使うか」の見通しを立ててからコミットする原則は変わらない。ただし、クラウドでは購入した後からでも変更・売却・スコープ変更できる仕組みが整っているため、「完璧な試算ができてから動く」のではなく、まず常時稼働しているリソースから小さくコミットし、実績を見ながら拡大していくアプローチが現実的だ。