2026 年版 AWS コミットメント割引の設計図 — Database Savings Plans 登場後のレイヤリング戦略

クラウドのコスト最適化は、もはや請求書が届いてから慌てる事後処理ではなく、アーキテクチャの意思決定そのものに食い込む設計課題になりました。とりわけ 2025 年 12 月に登場した Database Savings Plans は、これまで Reserved Instances（RI）一択で硬直的だったデータベース領域に、コンピューティング並みの柔軟性を持ち込んだ大きな転機です。

この記事では、AWS の Savings Plans と Reserved Instances を、2026 年 4 月時点の一次情報をベースに整理します。中心に据えるのは「最大割引率をどう取りにいくか」ではなく、「将来のアーキテクチャ移行を止めずに、どこまで財務の柔軟性を確保するか」という設計思想です。料金・対象サービス・ポリシーは変動が激しいため、本記事はあくまで確認日基準のスナップショットであり、実際の購入判断の前には各種ツールと公式ページでの再計算を強くおすすめします。

まず縮小し、それからコミットする

具体的なプランの比較に入る前に、2026 年の最重要原則を先に置きます。それは「まず縮小し、それからコミットする」です。

コミットメント割引は、いったん発効すると原則として減額もキャンセルもできない永久拘束です。過大なインスタンスにそのまま Savings Plans を当ててしまうと、本来削れたはずの無駄を割引価格で固定化することになります。AWS Well-Architected フレームワークも、固定的な「カバレッジ目標」を主指標に置くことを戒め、潜在削減額・純削減額・変化検知を重視するよう述べています。

したがって購入の順序は、アイドルリソースの削減、Compute Optimizer などを使ったライトサイジング、世代更新やアーキテクチャ移行、そして最後にコミットメント購入、という順番が原則です。コミットメントの主戦場は、最適化を終えてもなお残る「常時稼働の安定した底値」に限定するのが、過剰購入を避ける最大のコツになります。

2026 年のコミットメント割引の全体像

AWS の Savings Plans は現在 4 種類あります。従来の Compute・EC2 Instance・SageMaker に、新登場の Database が加わりました。

一方で Reserved Instances / Reserved Nodes は、EC2・RDS・ElastiCache・Redshift・OpenSearch・MemoryDB・DynamoDB（Reserved Capacity）などサービス別に存在し続けています。AWS は新機能開発を Savings Plans 側に集中させていますが、RI は依然フルサポートで、価格ページも更新され、Standard RI を再販できる RI Marketplace も稼働中です。

EC2 に関しては、「Compute SP と EC2 Instance SP の登場によって EC2 Reserved Instance はほぼ陳腐化した（同等以上の割引かつはるかに柔軟）」というのが業界のおおむね一致した見解です。それでも RI が依然有効なのは、データ層の安定ワークロードで最大割引を狙う場合、第 6 世代以前など Database SP 対象外の古い世代、Redis 系 ElastiCache や Redshift・MemoryDB といった Database SP 非対象サービス、そして Standard RI のみ可能な Marketplace での売却余地を残したい場合、の 4 つに絞られてきています。

Database Savings Plans とは何か

2026 年最大のトピックが、この Database Savings Plans（DB SP）です。re:Invent 2025 にあわせて 2025 年 12 月 2 日に発表され、中国リージョンを除く全リージョンで利用できます。長年の FinOps コミュニティの要望に応えるもので、これまでコミットメント割引が一切なかったサーバーレスにも割引が効くようになった点が画期的です。

対象サービスは、AWS News Blog の発表記事および現行の料金ページ時点で、Amazon Aurora・Amazon RDS・Amazon DynamoDB・Amazon ElastiCache・Amazon DocumentDB・Amazon Neptune・Amazon Keyspaces・Amazon Timestream・AWS DMS、そして Amazon OpenSearch Service に及びます。発表当日のアナウンスには OpenSearch が含まれていませんでしたが、その後の公式 FAQ と plan-types ドキュメントには OpenSearch および OpenSearch Serverless が明記されました。これは「対象サービスが順次追加され、既存の DB SP に自動適用される」という AWS の方針の表れです。実際 2026 年 3 月には、適用対象として OpenSearch Service と Neptune Analytics が正式に追加されています。

割引率について AWS が公式に明示しているのは、次のデプロイモデル別の 4 ティアだけです（いずれも「最大」）。

• サーバーレス（Aurora Serverless v2・ElastiCache Serverless for Valkey・DocumentDB Serverless など）: 最大 35%
• プロビジョンドインスタンス（全対象サービス）: 最大 20%
• DynamoDB・Keyspaces のオンデマンドスループット: 最大 18%
• DynamoDB・Keyspaces のプロビジョンドキャパシティ: 最大 12%

AWS はサービスごとの個別割引率表を公開していないため、各インスタンスの実割引は料金ページの USD/時間レートと購入シミュレーションで自分で確認する必要があります。DB SP は、サポートされるデータベースサービスを横断して 1 時間あたり一定金額（USD/時間）の利用にコミットすることで適用され、サーバーレスで最も割引率が高く設定されています。RDS for Oracle から Aurora PostgreSQL 互換へ、あるいは RDS から DynamoDB へとモダナイズしても割引が途切れない、というのが AWS の中心メッセージです。

Database Savings Plans の制約と落とし穴

DB SP は「柔軟性のための割引」であって、既存の RDS RI を即座に置き換えるものではありません。最大割引率では RI に明確に及ばず、いくつかの強い制約があります。設計の前にここを押さえておく必要があります。

第一に、対象は第 7 世代以降のモダンインスタンスファミリーのみです。db.r7g・db.m7g・db.r8g などは対象ですが、db.m5・db.r5・db.r6g といった旧世代や、バースト可能な db.t3・db.t4g は対象外です。これらの古いフリートで割引を受けるには、個別の RDS Reserved Instance を購入するか、フリートを最新世代へ更新する必要があります。これは事実上のモダナイズ誘導です。

第二に、ElastiCache では Valkey エンジンのみが対象で、Redis OSS と Memcached は対象外です。Timestream も InfluxDB インスタンスのみが対象です。Valkey は 2024 年に登場した Redis 互換の OSS エンジンで、Redis OSS より低レートで提供されており、AWS が割引対象を Valkey に寄せているのは、ライセンスコスト削減とインフラ割引の両面でモダナイズを促す FinOps インセンティブと言えます。なお Amazon Redshift と Amazon MemoryDB は対象外で、引き続き Reserved Nodes が必要です。

第三に、支払いは 1 年・前払いなし固定です。3 年契約も前払いオプションも現時点では存在しません。年度末の余剰予算で前払いしたい場合は、別機能の Advance Pay を併用し、毎月の No Upfront 請求を事前デポジットのプールから差し引くことで、会計上は実質的な全額前払いとして処理できます。

第四に、同一ワークロードでは RDS RI や DynamoDB Reserved Capacity との重ね掛けができません。別ワークロードへの併用は可能ですが、同一時間・同一インスタンスでは RI が優先適用され、カバーされなかった分に DB SP が充当されます。

そして最も注意すべき落とし穴が、サービス固有の Private Pricing Agreement（PPA）との関係です。PPA で例えば 40% の割引を受けている Aurora インスタンスに対して、20% の DB SP が「カバレッジ争い」に勝ってしまうと、高い割引を低い割引で上書きして、かえって損をするケースが第三者分析（ProsperOps）で具体的に報告されています。購入レコメンデーション画面はサービス固有の PPA を考慮しないため、PPA がある環境では DB SP の購入前に必ず影響をシミュレーションすべきです。

適用順序とレイヤリング戦略

AWS の請求システムは、各時間に稼働したオンデマンドリソースに対して、システム的な優先順位で割引を自動適用します。この順序を理解することが、重ね合わせ設計の前提になります。

1. AWS 無料利用枠: 最優先
2. Reserved Instances / Reserved Capacity: 該当リソースがあれば最優先で適用
3. EC2 Instance Savings Plans: 特定ファミリー・指定リージョンに適用
4. Compute Savings Plans: 最も適用範囲が広い最後の砦として残余に適用

各 Savings Plans の中では「割引率が最も高い使用量から」適用されるため、複数の SP を重ねても競合せず、AWS が自動で最適化します。この性質を活かして、インフラ全体を安定度とモダナイズロードマップに基づいて 3 つのレイヤーに分け、コミットメントを積層させるのが 2026 年のベストプラクティスです。

flowchart TD
    A["対象ワークロードを識別"] --> B{"まず最適化済みか"}
    B -- いいえ --> C["アイドル削減 / ライトサイジング / 世代更新"]
    C --> A
    B -- はい --> D{"DB 中心か"}
    D -- はい --> E{"今後 1 年でエンジン / サービス / リージョンが変わり得るか"}
    E -- はい --> F["Database SP を第一候補"]
    E -- いいえ --> G["RDS RI 等と Database SP を比較"]
    D -- いいえ --> H{"EC2 / Fargate / Lambda をまたぐか"}
    H -- はい --> I["Compute SP を第一候補"]
    H -- いいえ --> J{"単一ファミリー / 単一リージョンで安定か"}
    J -- はい --> K["EC2 Instance SP または Standard RI を比較"]
    J -- いいえ --> I

3 レイヤーの具体像は次のとおりです。

レイヤー 1 は、超安定な基幹系データベースと固定ワークロードです。今後 3 年間アーキテクチャ変更の可能性が極めて低い大規模 RDS や、商用データベース（Oracle・SQL Server）の長期固定ライセンス環境には、3 年契約の Standard Reserved Instance を全額または一部前払いで選びます。最大 60% を超える業界最高水準の割引を固定化してボトムラインを守る狙いですが、期間内に移行を決めると未使用 RI が「座礁資産」と化すリスクを負います。

レイヤー 2 は、中期的に安定したアプリケーションフリートです。リージョンや OS の変更可能性は低いものの、将来的に Graviton 世代へのインスタンス更新を想定する EC2 群には、1 年または 3 年の EC2 Instance Savings Plans を選びます。同一ファミリーであればサイズや OS を自由に変えられるため、Standard RI の硬直性を緩和しつつ強力な割引を維持できます。

レイヤー 3 は、流動的なクラウドネイティブ・データベースと新規モダンインフラです。Aurora Serverless v2・DynamoDB オンデマンド・ElastiCache for Valkey、そして開発・テスト環境の動的なデータベース群には、1 年契約の Database Savings Plans を全面的に配備します。エンジン自体を RDS から Valkey や DynamoDB へドラスティックに変えても割引が自動追従するため、投資保護が機能します。同じレイヤーのアプリケーション実行環境（Fargate・Lambda）には、グローバルで柔軟な Compute Savings Plans を当て、システム全体のサーバーレス化を後押しします。

調達の数値設計 — 70〜80% の保守的ルール

コミットメント調達における最大の失敗要因は、平均負荷やピーク時の消費量を基準に購入金額を決めてしまうことです。未使用のまま消失するコミットメントを防ぐため、調達は数値設計として進めます。

まず Cost Explorer を使い、過去 30〜60 日の 1 時間ごとのネットオンデマンド消費額（USD/時間）をグラフ化します。スパイクや一時的なデータ移行、負荷テストの一過性のコストは必ず除外し、確実に稼働し続けている時間帯の最低ライン、すなわち p10 付近の底値を特定します。サイジングは平均ではなく、この最小ベースライン基準で行うのが鉄則です。

次に、特定した底値の 70〜80% に相当する金額を上限として、第一フェーズのコミットメントを購入します。残りの 20〜30% は一時的にオンデマンドで支払う余地として残し、数か月の稼働推移を見ながら、必要に応じて少額を階段状に買い増していきます。1 時間で使い切れなかったコミットメントは消失して繰り越せないため、100% をカバーしようとすると、週末の停止や右サイジングに伴って即座に「利用率の低下＝純損失」へ反転します。

ここで 2 つの指標を区別することが重要です。利用率（Utilization）は買ったコミットのうち実際に使われた割合で、目標はほぼ 100% です。カバレッジ（Coverage）は対象支出のうち割引でカバーされた割合です。高カバレッジかつ低利用率は買い過ぎ、低カバレッジかつ高利用率は買い不足を意味します。

数値感覚をつかむために、単純化したブレークイーブンモデルを置きます。コミットした底値を X、割引率を d、ある月の実使用を U とすると、コミット後コストは近似的に次のようになります。

コミット後コスト = X × (1 - d) + max(0, U - X)

このとき、オンデマンドより不利にならない条件は U > X × (1 - d) です。つまり割引率 35% の Database SP なら、実使用がコミットした底値の 65% を下回らない限り損はしません。逆に言えば、割引率が低いプランほど底値を慎重に切る必要があり、DB SP は「柔軟だが、床の見積もりは保守的に」という設計になります。

なお Savings Plans には、1 時間あたり 100 USD 未満の契約に限り、購入と同一暦月内かつ 7 日以内であれば、1 つの Organizations につき年間最大 10 回まで返品できる救済枠があります。桁を間違えた発注などの深刻なミスに対する保険であると同時に、「少額で買って検証し、問題なければ買い増す」という運用を後押しする仕組みでもあります。

マルチアカウントの割引共有

大規模な AWS Organizations 環境では、一括請求（コンソリデーティッドビリング）によって割引が自動集約されます。デフォルトでは RI/SP の割引共有がオンで、ある購入アカウントに適用された後の余剰枠が、組織内の他アカウントへ自動適用されます。最大の節約を狙うなら、使用量のない中央管理アカウントで集中購入し、共有をオンのまま組織全体へ最も高い割引率で適用するのが基本です。

しかし従来は、ある事業部の予算で買った割引枠が、夜間バッチを走らせた別部署のアカウントに自動適用され、本来の予算所有部署で利用率が下がる「予算配分と割引適用のミスマッチ」が慢性的な課題でした。2025 年 11 月に一般提供された RI/SP Group Sharing は、この組織的な摩擦を技術的に制御する仕組みです。管理者は Cost Categories を使って組織階層を定義し、割引共有の境界を制御できます。

割引共有をオフや制限付きにすると、規模の経済を失って組織全体の利用率が下がり、総コストが増える傾向があります。オフが適切なのは、リセラー・MSP のテナント分離、規制上の分離、厳密な部門別 P&L が必要なチャージバックの場合に限られます。なお 2025 年 6 月 1 日施行のポリシー更新により、MSP・リセラーが単一 Organizations 配下の複数エンドカスタマー間で RI/SP 割引を共有することは禁止されました。自社で直接管理する同一 Organizations 内の共有には影響しませんが、リセラー経由の場合は施行後に割引が消えてオンデマンドに戻っていないか確認が必要です。

プロダクトのライフサイクルで戦略を変える

コミットメント戦略は、プロダクトの成熟度に応じて段階的に変えるのが現実的です。

立ち上げ期は、原則オンデマンド中心でコミットしません。CI/CD・バッチ・検証環境には Spot インスタンスを活用し、まずは右サイジングと不要リソースの停止を徹底します。検討を始める目安は、3 か月以上の安定した時間単位の使用データが貯まり、明確な 24/7 のベースラインが見えたときです。最初は最小ベースラインの 60〜70% を上限に、小さな Compute SP（1 年・前払いなし）から始めます。

成長期は、Compute SP（1 年・前払いなし）を土台に、ベースラインの 70〜80% をカバーします。柔軟性を最優先し、ファミリー変更・Graviton 移行・Fargate/Lambda 化に割引を追従させます。四半期ごとに少額を階段状に買い増し、購入のたびにシミュレーションし直します。データ層で新世代やサーバーレスを使っているなら、ここで DB SP を小さく始めると、移行フェーズでも割引が途切れない利点が活きます。

運用安定期は、確信のあるインスタンスファミリーとリージョンに、EC2 Instance SP または Standard RI（3 年・全額または一部前払い）を上乗せして割引を最大化します。データ層で安定した特定構成の最大割引を狙うなら、RDS RI や Reserved Nodes（3 年・全額前払い）が有力です。多エンジンでモダナイズ予定のものは DB SP、Redshift・MemoryDB・Redis 系 ElastiCache は引き続き Reserved Nodes、という住み分けになります。

判断を変えるしきい値も明確にしておきます。利用率が継続的に 95% を下回るなら買い過ぎなので買い増しを止める。カバレッジが 80% 未満かつ利用率が高いなら買い不足なので追加購入を検討する。旧世代 DB が多いなら、DB SP の前に第 7 世代へのモダナイズか RI を検討する。サービス固有の PPA があるなら、DB SP の購入前に必ず影響をシミュレーションする、という具合です。

FOCUS と自動ガバナンス

2026 年の FinOps は、プロプライエタリな課金ダッシュボードへの依存から、オープンスタンダードである FOCUS（FinOps Open Cost and Usage Specification）を使った自律的なデータ駆動ガバナンスへ移行する流れにあります。AWS は Data Exports を通じて FOCUS 1.0 のネイティブサポートを GA として提供しており、FOCUS 準拠のデータを S3 に蓄積して Amazon Athena や BI ツールで検索すれば、これまで手作業だったコミットメントの追跡を高度に自動化できます。実効コスト（EffectiveCost）カラムで RI/SP の割引を各リソースへ按分し、契約コミットメントのデータセットで有効開始日・満了日・残存量を一元把握する、という設計が推奨されます。

運用を健全に保つため、次の自動ガードレールを定常プロセスに組み込みます。

• Cost Anomaly Detection の強制適用: 機械学習ベースの異常検知を全アカウントで有効化し、想定モデルから乖離したコスト変動を Slack などへ自動通知する。メトリクス反映には最大 48 時間かかる点に注意。
• AWS Budgets と購入キューの活用: 保有する全 RI/SP に対し満了 30 日前・7 日前のアラートを設定し、継続が確定しているワークロードには購入のキューイング予約を実行して、満了日と寸分の狂いなく新しい割引が引き継がれるよう自動更新する。これで満了時の「断崖」を避けられる。
• 定期的なモダナイズ監査の自動化: Compute Optimizer と Cost Optimization Hub を監視に組み込み、旧世代に個別 RI が当たっているレガシー DB を四半期ごとに洗い出し、第 7 世代と Valkey への移行ロードマップを是正する。ただし DB SP の推奨は現時点で Cost Optimization Hub に表示されない点に注意する。

レビュー頻度は、新規購入後の 90 日は週次、その後は安定ワークロードなら月次が目安です。とりわけ DB SP は 1 年物なので、四半期ごとの見直しと年次の再均衡が適しています。

まとめ

要点を整理します。

• AWS の Savings Plans は Compute・EC2 Instance・SageMaker・Database の 4 種類になった。2025 年 12 月の Database SP は、サーバーレスにも初めて割引が効く「柔軟性のための割引」で、最大 35% と RI の最大割引には及ばないが、エンジン移行に追従する点が画期的。
• DB SP には、第 7 世代以降のみ・ElastiCache は Valkey のみ・1 年/前払いなし固定・RI と重ね掛け不可・サービス固有 PPA を上書きして損をしうる、という制約と落とし穴がある。
• 2026 年のベストプラクティスは重ね合わせ。基幹データ層に Standard RI（3 年）、中期安定の EC2 に EC2 Instance SP、流動的なクラウドネイティブ DB に Database SP、という 3 レイヤーで積層する。
• 調達は最小ベースラインの 70〜80% を上限に階段状に買い増す。利用率とカバレッジを区別し、固定的なカバレッジ目標ではなく限界削減額で購入停止点を決める。
• マルチアカウントは中央集権購入と共有オンが基本。RI/SP Group Sharing で事業部単位の優先・制限共有を制御し、FOCUS と自動ガードレールでガバナンスを継続する。

最大割引率を追いかけるのではなく、モダナイゼーションを止めない財務の柔軟性をどう設計するか。これが 2026 年の AWS コミットメント戦略の核心です。料金・対象サービス・ポリシーは短期間で書き換わるため、本記事はあくまで 2026 年 4 月時点の見取り図として、実際の購入前には必ず一次情報と各種ツールで再確認してください。

以上、Database Savings Plans 登場後の AWS コミットメント設計を、4 種類の比較・レイヤリング・調達の数値設計の観点から整理した、現場からお送りしました。

参考情報

• Database Savings Plans 料金ページ
• Introducing Database Savings Plans for AWS Databases（AWS News Blog）
• Savings Plans 公式
• リザーブドインスタンスと Savings Plans のグループ共有
• AWS Well-Architected コスト最適化の柱
• FOCUS（FinOps Open Cost and Usage Specification）