AWS の RI・Savings Plans をどこまで買うか — 100% コミットしない購買戦略
はじめに
AWS のコストを下げようとすると、必ず Reserved Instances（RI）と Savings Plans（SP）の購入判断に突き当たります。そのとき最初に迷うのが「どこまで買うか」です。割引率だけを見ると 100% コミットしたくなりますが、実務ではそれは高確率で失敗します。
結論から書くと、正しい問いは「何 % 買うか」ではなく「どこまでが崩れない床か」です。本記事では、AWS の仕様から出発してこの原則を導き、指標の定義・商品選択・購買サイクル・シナリオ別レンジまでを整理します。
なぜ 100% コミットが正解にならないのか
理由は割引の心理ではなく、仕様に根拠があります。
- Savings Plans のコミットメントは時間単位で、使い切れなかった分は翌時間へ繰り越されません。1 時間ごとに消滅する純粋な埋没コストになります。
- Cost Explorer の推奨は過去の使用履歴（7 / 30 / 60 日）に基づく計算であり、将来予測を含みません。移行完了直後やスケールダウン直後には古いパターンを反映し、過剰コミットを誘発します。
- Savings Plans は購入後のキャンセルができず、再販市場もありません（時間コミットが $100/時 以下・購入後 7 日以内・同一暦月内の返品窓のみ）。
- 使用量そのものが動きます。週末・夜間の落ち込み、Graviton への移行、EC2 から Fargate・Lambda への移行、rightsizing による縮小は、いずれもコミットを空振りさせます。
興味深いことに、AWS 公式の Well-Architected Cost Optimization Pillar は固定カバレッジ目標そのものに否定的で、「割引率が変動するため、アカウントに固定のカバレッジ目標を設定するな」と明言しています。代わりに推奨されるのは、Cost Explorer の Savings Plans 推奨ツールで潜在削減額を監視し、推定削減が必要割引率を下回るまで少量ずつ買い増す、というやり方です。
一方でサードパーティの FinOps ベンダーは「安定ベースラインの 70〜85%」というレンジをおおむね共通して挙げます。この二つは矛盾しません。どちらも「床にだけコミットする」という同じ原則の別の言い方です。
指標を正しく定義する
議論が噛み合わなくなる最大の原因は、分母の取り違えです。
- カバレッジ: 対象オンデマンド使用量のうち、コミットでカバーされた割合。ここでの分母はあくまで「RI / SP の対象となるオンデマンド相当支出」であり、AWS の総請求額ではありません。
- 使用率: 購入したコミットのうち実際に消費された割合。ほぼ全ユーザーが 100% を目標にすべき指標で、80% を切ったら過剰コミットのサインです。
- 有効削減率（ESR = Effective Savings Rate）: FinOps Foundation が Rate Optimization の主要 KPI として公式採用している指標。
ESR = 使用率 × カバレッジ × 割引率で表されます。
カバレッジと使用率は入力指標、ESR は出力指標（ROI に相当）という位置づけが実用的です。カバレッジ 100% でも使用率が低ければ ESR は伸びません。
分母の話は実際に効きます。「カバレッジ 80%」と言っても、それは AWS 総額の 80% ではありません。S3・EBS・データ転送・NAT Gateway は EC2 RI や Compute Savings Plans の対象外なので、これらの比率が高い組織ではコンピュートカバレッジ 80% でも総請求額への効きはずっと小さくなります。対象コンピュートのカバレッジと、総 AWS コストへの寄与は分けて管理してください。
サービス別の適用可否
| コスト項目 | RI / SP で直接カバーできるか | 実務上の扱い |
|---|---|---|
| EC2 インスタンス使用料 | はい | RI / EC2 Instance SP / Compute SP の主戦場 |
| Fargate・Lambda | Compute SP のみ | 変動があっても基礎負荷があれば対象 |
| EKS・ECS・EMR 上の EC2 | はい（基盤 EC2 分のみ） | ノードの最低常駐分を被覆する |
| EKS のサービス料金 | いいえ | ノードは対象でもサービス料金は別扱い |
| RDS・Aurora・DynamoDB・ElastiCache・OpenSearch | はい（Database SP またはサービス別予約モデル） | 安定した DB の床を別枠で設計 |
| EBS | いいえ | rightsize・gp3 化・未使用削除で最適化 |
| S3 | いいえ | ストレージクラス・ライフサイクル・Intelligent-Tiering |
| データ転送・NAT Gateway | いいえ | アーキテクチャ改善・ゾーン間通信削減・CloudFront 活用 |
商品の選び方
2026 年時点の主要な選択肢を整理します。
| 商品 | 最大割引 | 柔軟性 | 対象 | 主な制約 |
|---|---|---|---|---|
| EC2 Instance SP | 最大 72% | 中（サイズ・OS・テナンシー変更可） | EC2 のみ | ファミリー・リージョン固定 |
| Standard RI | 最大 72% | 低（属性固定） | EC2 | 交換不可。ただし RI マーケットプレイスで売却可 |
| Convertible RI | 最大 66% | 高（ファミリー・OS・テナンシー交換可） | EC2 | 同等以上価値への交換のみ、売却不可 |
| Compute SP | 最大 66% | 最高（全ファミリー・リージョン + Fargate・Lambda） | EC2 / Fargate / Lambda | 容量予約なし、キャンセル不可 |
| Database SP | 最大 35%（サーバーレス） | 高（エンジン・リージョン横断） | RDS / Aurora / DynamoDB ほか | 1 年・No Upfront のみ、RI と同一ワークロード併用不可 |
| DB Reserved Instance | 最大 69%（RDS） | 低 | RDS / ElastiCache / OpenSearch ほか | 構成固定、売却市場なし |
設計原則はシンプルです。柔軟性を先に買い、深い割引は後から積む。最初の 1 層は Compute Savings Plans を基本にし、単一ファミリー・単一リージョンで 6〜12 ヶ月以上安定した床だけを 2 層目で EC2 Instance SP や Standard RI に置き換えます。
もう一つ重要なのは、容量保証と割引を別問題として扱うことです。Savings Plans は容量予約を提供しません。特定 AZ で確実に起動したい本番やフェイルオーバー容量は Zonal RI か On-Demand Capacity Reservations で確保し、そのうえに割引を重ねます。割引の都合だけで大きな Zonal RI を買うと、AZ 偏りと構成変更に弱くなります。
なお適用順序は Zonal RI → Regional RI → EC2 Instance SP → Compute SP です。安定層を RI / EC2 Instance SP で深く割り引き、変動層を Compute SP で拾う層別戦略が成立します。
2025 年末に発表された Database Savings Plans は、初の DB サーバーレス対応・エンジン横断割引ですが、RI より割引は浅くなります。安定・大規模な DB は RI、移行予定やサーバーレスは Database SP、という使い分けが妥当です。
期間と前払いの選択
「12 ヶ月以上観測していないワークロードに 3 年を買うな」が実務原則です。3 年の割引上乗せは約 20 ポイントですが、36 ヶ月間で 15% を超える使用量低下があれば相殺されます。月次ボラティリティが 25〜30% を超えるなら 1 年を選ぶべきです。
前払いは、財務に余力があり 12 ヶ月以上安定した実績があるなら All Upfront が最も深く割引されます。高成長・変化中・初回購入は No Upfront が無難です。Database SP は No Upfront のみです。
FinOps Foundation のペーパーが提示する 60/40 戦略（安定ベースロードの 60% を 3 年、40% を 1 年に配分）はヘッジとして有効ですが、成熟度が低い段階では 70% を 1 年・30% を 3 年で保守的に始め、12 ヶ月以上のデータが揃ってから移行するほうが安全です。
ラダリングで段階的に買う
一括で目標カバレッジに到達しようとしないことが、構造的に過剰コミットを避ける方法です。AWS が提示するローリング Savings Plans は、総コミット枠を複数の小さな等額コミットに分割し、四半期ごとなどずらして購入する手法で、満了時点が分散するため使用量の変化に合わせて更新・増額・失効を選べます。個人資産運用の CD ラダーと同じ発想です。
購買サイクルの目安は次のとおりです。
- 新規購入後の最初の 90 日は週次レビュー、その後は安定ワークロードで月次レビュー
- 1 年商品（Database SP など）は四半期レビュー・年次リバランス
- 満了 30 / 60 / 90 日前にアラートを設定
購入前には Savings Plans Purchase Analyzer を必ず使ってください。カスタム金額や目標カバレッジを指定して、コスト・カバレッジ・使用率・削減額を比較できます。特に $100/時 を超える大型コミットでは必須です。
一点、よくある事故があります。Compute SP と EC2 Instance SP の推奨は同じ使用データから生成されており、両方を足し合わせて同時購入する前提ではありません。まずどちらを軸にするか決めてから Analyzer に進んでください。
シナリオ別の推奨レンジ
以下は AWS 公式の固定値ではなく、過剰コミットを避ける側に寄せた実務レンジです。迷ったら下限から入り、月次で上げるのが安全です。
| ワークロード | 推奨カバレッジ | 推奨ミックス | 補足 |
|---|---|---|---|
| 定常本番（単一リージョン・単一ファミリー、変更ほぼなし） | 70〜90% | EC2 Instance SP / Standard RI 中心 + Compute SP で補完 | 床が厚く深い割引を取りに行ける |
| 定常本番だが Graviton 化・Fargate 移行の可能性あり | 60〜80% | Compute SP 中心、必要なら Convertible RI | 変化リスクを割引より優先 |
| 予測可能な成長がある本番 | 現在値の 50〜70% から開始 | まず Compute SP、安定後に RI 追加 | 四半期ごとに 5〜15pt 追加 |
| 季節性が明確 | 35〜60% | 閑散期の床だけ Compute SP | 谷の床だけ買う |
| バースト・Auto Scaling 主体 | 15〜35% | ASG min・EKS ノードの最低常駐分のみ | ピーク追従はオンデマンド |
| dev / test（夜間停止あり） | 0〜20% | 24x7 の CI ランナー・踏み台のみ | 停止中もコミットは消費される |
| 短命環境・POC・組織変更前後 | 0〜10% | 原則オンデマンド | 安定化まで待つ |
| DB 系の安定床 | 50〜80% | Database SP またはサービス別予約モデル | 床だけ買う原則は同じ |
| S3 / EBS / ネットワーク | 0% | ライフサイクル・ストレージクラス・アーキ改善 | そもそも RI / SP の対象外 |
事業上の事情による補正も入れてください。キャッシュ温存が最優先なら下限寄りに 10〜15pt、四半期ごとに構成変更が多いなら下限寄りに 10〜20pt、組織再編や M&A が見えているなら一旦下限寄り、というのが実務感覚です。
床にコミットする効果を数字で見る
説明用の仮定として、常時必要な床が ¥1,000/時、平日ピーク追加が ¥500/時 × 月 220 時間、Compute SP の実効単価がオンデマンド比 70% だとします。
| ケース | 月額コスト | オンデマンド比 |
|---|---|---|
| すべてオンデマンド | ¥840,000 | 基準 |
| 床の 70% を Compute SP | ¥686,700 | -18.3% |
| 床の 100% を Compute SP | ¥621,000 | -26.1% |
| 床の 120% を Compute SP | ¥679,200 | -19.1% |
床の 100% までは効率よく効きますが、変動ピークまでコミットで追いかけた瞬間に効率が落ちます。これが「100% カバレッジを狙うより床を確実に押さえる」ことの数字上の意味です。
夜間停止する dev / test はもっと極端です。1 台のオンデマンド料金が ¥1/時、Compute SP 実効単価が ¥0.70/時、稼働が平日 12 時間のみ（月 260 時間）だとすると、すべてオンデマンドで ¥260 のところ、24x7 相当の 100% コミットは ¥511、「半分だけ買う」50% コミットでも約 ¥386 になります。Savings Plans は「稼働した時間だけ安くなる」のではなく「毎時間コミットを消費する」ためです。
意思決定のフローと財務評価
flowchart TD
A[対象コストを分類する] --> B{RI/SP の対象か}
B -- いいえ --> C[S3/EBS/データ転送/NAT を別管理]
B -- はい --> D{特定 AZ の容量保証が必要か}
D -- はい --> E[Zonal RI または ODCR を検討]
D -- いいえ --> F{12 ヶ月以上ファミリー・リージョンが安定か}
F -- はい --> G[EC2 Instance SP または Standard RI]
F -- いいえ --> H{世代変更や Fargate 移行の可能性ありか}
H -- はい --> I[Compute SP または Convertible RI]
H -- いいえ --> J[Compute SP を基本にし安定床のみ RI を併用]
E --> K[残りはオンデマンド]
G --> K
I --> K
J --> K
床の算出は、過去 90 日（季節性があれば最も低い四半期）の時間単位オンデマンド支出を取得し、その P10（10 パーセンタイル）を「絶対に下回らない床」とするのが実用的です。平均でコミットすると約半分の時間で使用量が下回り、無駄が出ます。
財務評価では割引率だけでなく、TCO・NPV・Payback・損益分岐稼働率を見ます。特に損益分岐稼働率（コミット単価 ÷ オンデマンド単価）は間欠稼働ワークロードで効きます。コミット単価がオンデマンドの 70% なら、その単位が 70% 以上の時間で消費されない限りフルコミットは得になりません。AWS が公開する平均割引（Standard RI は 1 年平均 40%・3 年平均 60%、Convertible RI は 1 年平均 31%・3 年平均 54%）から近似すると、1 年 Standard RI は 60% 稼働超、3 年 Standard RI は 40% 稼働超でようやく有利になります。
NPV は基準・下振れ -20%・上振れ +20% の 3 ケースを用意してください。AWS の推奨は将来予測をしないため、需要低下や rightsizing 完了後の縮小は自分で織り込まないと、最適化のはずが固定コスト化します。
過剰コミットしてしまったときの出口
購入前に出口を確認しておくべきです。
- Standard RI（EC2）: RI マーケットプレイスで売却可能（12% 手数料、最初と最後の 30 日は不可、米国銀行口座が必要）
- Convertible RI: 同一リージョン内で同等以上価値のものへ交換（有効期限は維持）
- Savings Plans: 再販不可・キャンセル不可。$100/時 以下かつ購入後 7 日以内・同一暦月内の返品窓のみ
- RDS / ElastiCache / OpenSearch / Redshift の RI: 売却市場なし
Savings Plans だけに依存する設計は、この出口の観点では脆弱です。柔軟性が高く運用負荷が低いので第一候補ではありますが、出口戦略を持つ RI との併用を検討する価値はあります。
実務チェックリスト
- 先に最適化する。アイドル削除 → Compute Optimizer で rightsize → 世代更新（Gen7+、Graviton、Valkey）を済ませてからコミットする。過剰なインスタンスに割引を貼ると無駄が固定化されます。
- 分母を分ける。EC2 / Fargate / Lambda / 対象 DB と、S3 / EBS / 転送 / NAT を分離する。
- タグと分類を整える。コスト配分タグを有効化し、環境・アプリ・オーナー・コストセンターを標準化する。
- 床を自分で計算する。90 日の時間単位データから P10 を算出し、Cost Explorer 推奨は鵜呑みにせず 70〜75% の緩衝を掛ける。
- 層別に割り当てる。最安定層は RI / EC2 Instance SP、変動層は Compute SP、中断可はスポット、ピークはオンデマンド。
- 段階購入する。四半期ごとに小分けで買い増し、満了を分散する。
- 監視を設定する。使用率・カバレッジ・満了（30 / 60 / 90 日前）のアラートを支払いアカウントで設定する。AWS Budgets の通知は最大 48 時間遅延する点に注意。
運用しきい値としては、定常本番で SP 使用率 95〜98% 以上、使用率が 3 日連続で 85% 未満なら買い増しを停止して過剰コミットを疑う、未使用コミットが 2 ヶ月以上続くなら追加購入停止、というあたりが扱いやすい基準です。
注意点
- 72% / 66% / 35% といった割引率はすべて特定条件（3 年・All Upfront・特定リージョン）での最大値です。実際の割引はインスタンスタイプ・OS・リージョンで大きく変動し、Windows や SQL Server のようなライセンス OS、小型インスタンスでは数 % しか出ないこともあります。購入前に必ず自環境の実レートを Purchase Analyzer で確認してください。
- 本記事のパーセンテージの多くはサードパーティ FinOps ベンダーの実務推奨と、AWS の仕様から再構成した実務レンジであり、AWS が公式に固定値として示しているものではありません。
- Database SP は新しく制約が多い商品です。Gen7+ のみ、ElastiCache は Valkey エンジンのみ、1 年・No Upfront 固定、RI との同一ワークロード併用不可、ストレージ・バックアップは対象外です。
- 数値と商品仕様は 2025-2026 年時点のものです。AWS は通常 re:Invent（11 月末〜12 月）で価格と商品を更新するため、購入直前に公式ページで再確認してください。
おわりに
「必ずしも 100% コミットしなくてよい」という直感は、実務のベストプラクティスと一致します。時間単位コミット・非繰越・履歴ベース推奨という AWS の仕様を踏まえれば、正しい順番は可視化 → 右サイズ化 → 小口購入 → 効果観察 → 追加購入です。
以上、AWS の RI・Savings Plans を床だけコミットする原則で整理した、現場からお送りしました。
参考情報
RI はサービスごとに商品名・割引率・購入単位が異なります。実際の購入判断では、対象サービスの公式ページで条件を確認してください。