セキュリティサービス部 佐竹です。
このブログ記事は AWS re:Invent 2025 で発表された Database Savings Plans を買う前に必ず読みたい、と思われるそんなブログとして執筆しました。特に「DB 系サービスの割引オプションの整理とまとめ」は必見です。
- はじめに
- Database Savings Plans をまず知る
- Database Savings Plans 対象サービス一覧
- 割引率の「渋さ」
- RI と Savings Plans の比較と使い分けを考える
- Database Savings Plans を見積もる
- その他の特筆すべき点など
- まとめ
はじめに
本ブログは、AWS のコスト管理を担当されているエンジニアや、FinOps 推進担当者の方向けの内容です。
特に、Compute Savings Plans (Compute SP) や EC2 Instance Savings Plans (EC2 Instance SP) は既に購入済みで、RDS の Reserved Instances についても既に購入、運用を行っているような「中〜上級 FinOps 担当」を想定しています。よって、Savings Plans や Reserved Instances (RI) の基本については既にご存知だという前提で記述して参ります。
ところで、コスト最適化というと、Reserved Instances and Savings Plans (RISP) Group Sharing のアップデートが、個人的にはなかなかに解説のし甲斐があり、面白いアップデートだと感じました。以下も是非ご参考ください。
話を戻します。
さて、Database Savings Plans は、その名の通りデータベースサービス群を対象とした Savings Plans です。私はずっと「Savings Plans の対象に RDS も含めてくださいよ！」と願っていました。
ですが、ある意味では残念なことに、Compute Savings Plans の拡張対象とはならず、Database Savings Plans という別の Savings Plans として登場しました。これは SageMaker Savings Plans みたいなものということです。
別の SP に分かれてしまいました。そう、これが4つ目の Savings Plans です。「ビルディングブロック」の概念は良いのですが、さすがにコスト最適化サービスが増えすぎて、ややこしすぎませんか。だから整理したい。そんなブログでもあります。
なお、本ブログでは Database Savings Plans の略称として DB SP を利用します。これは Compute Savings Plans を Compute SP と省略することから、半角スペースを設けて省略することとしました*1。
Database Savings Plans をまず知る
Database Savings Plans は、1年または3年の期間、特定の時間当たりの利用金額（$/hr）をコミットすることで、対象のデータベースサービスの利用料が割引になる料金モデルです…と言いたかったんですが違います。
「1年 × 前払いなし」しか選択できません。それって、CloudFront と WAF の「Security Savings Bundle」みたいじゃないですか？
とにかく、そういう仕様で登場しました。
RI とは異なる Savings Plans の持つ最大の特徴は「柔軟性（Flexibility）」です。
以下の要素が変更となっても、割引は自動的に適用され続けます。
- データベースエンジン (例: RDS for Oracle から Aurora PostgreSQL へ移行)
- インスタンスファミリー (例: db.r7g から db.r8g へ変更)
- リージョン (例: 東京リージョンから大阪リージョンへ移動)
- デプロイオプション (例: シングル AZ から マルチ AZ へ変更)
- サイズ (例: large から xlarge へ変更)
これらは Compute SP が持つ柔軟性と似ており、利用者からすると非常に大きなメリットとなります。では、「対象となるサービス」は一体なんでしょうか？
Database Savings Plans 対象サービス一覧
Database Savings Plans の Pricing ページを参考に以下、一覧表を作ってみました。
| サービスカテゴリ | 詳細サービス名 | 備考 |
|---|---|---|
| Aurora & RDS | Aurora and RDS Instances | 基本となる対象 |
| Aurora Serverless v2 | Serverless も対象 | |
| Aurora DSQL | DSQL も対象になっています | |
| DynamoDB | DynamoDB | プロビジョニング/オンデマンド共に |
| ElastiCache | ElastiCache for Valkey Instances | Valkey インスタンス |
| ElastiCache for Valkey Serverless | Valkey サーバーレス | |
| DocumentDB | Amazon DocumentDB Instances | |
| Amazon DocumentDB Serverless | Serverless も対象 | |
| Neptune | Neptune Instances | |
| Neptune Serverless | Serverless も対象 | |
| Timestream | Timestream | |
| Keyspaces | Keyspaces | for Apache Cassandra |
| DMS | DMS Instances | Database Migration Service |
| DMS Serverless |
特筆すべき点として、Aurora Serverless v2 や、Aurora DSQL、DocumentDB が対象になっているのは目新しいと感じます。
対象外のサービス（注意点）
一方で、以下のサービスは Database Savings Plans の対象外です*2。
- Amazon Redshift:
Redshift には独自の Reserved Node (RN) が存在しますので、そちらをご利用ください - Amazon OpenSearch Service:
こちらも独自の Reserved Instance (RI) が存在しますので、そちらをご利用ください - Amazon MemoryDB:
こちらも独自の Reserved Node が存在しますので、そちらをご利用ください
「データベースっぽいものなら全部いけるだろう」というわけでもなく、Redshift や OpenSearch Service をカバーできていませんので、十分にご留意ください。
私の感覚的には、DocumentDB、Neptune、Timestream、Keyspaces あたりをコスト最適化したい場合に使うイメージで見ています。あとは Aurora Serverless v2 も嬉しいですね。
割引率の「渋さ」
コスト最適化はお金の話。問題は割引率です。
EC2 Instance SP であれば Standard RI と同率の最大 72% オフ、Compute SP でも EC2 インスタンスは Convertible RI と同率の最大 66% オフといった数字を見ていると、Database Savings Plans の割引率は「正直、渋い」と感じるはずです。実際にここから割引率を見ていきましょう。
Aurora / RDS の場合
まず、どのリージョンでも、Aurora / RDS の割引率は「20%」固定です。エンジンの差もありません。「最大 35%」という謳い文句は Aurora Serverless v2 に対してです。
それに、対象となるインスタンスタイプも限られています。Aurora MySQL においては、現在対象となるのは db.r7g、db.r7i、db.r8g の三種類だけで、最新のインスタンスタイプが対象のようです。Aurora PostgreSQL についてはそれに加えて db.r8gd が対象になりますが、対象は狭いと言わざるを得ないでしょう。
RDS についても第7世代と第8世代以降のみが対象となっており、Database Savings Plans のコスト最適化効果を受け取るにはそもそもデータベースのインスタンスクラスを最新世代に変更しないといけない、というハードルが生まれます。これは AWS 公式ブログにて latest provisioned instance generations と記述されている箇所と整合します。
比較して Aurora の RI で db.r5.large の場合、1年×全額前払いで 44% オフです。さらには、3年×全額前払いでは 63% オフです。そのコスト最適化効果は、格段に高いと言えます。
DynamoDB の場合
上記は「DynamoDB On-Demand Throughput（IA 含む）」に対する Database Savings Plans (1年/前払いなし) のレートですが、Savings over On-Demand は「18%」 となっています。
DynamoDB の Reserved Capacity (RC) は、「オンデマンドキャパシティ」は対象外ですので、これは Database Savings Plans でコスト最適化が可能という点で嬉しいアップデートとなっています。
ですがその反面、Provisioned Throughput（IA 含む） に至っては 「12%」 のコスト最適化にしかなりません。
DynamoDB 独自の割引オプションであり、Provisioned Throughput を対象とした Reserved Capacity を購入する場合では、1年で約 54%、3年であれば最大 77% の割引が得られる場合があります。
Reserved capacity is a great option to reduce DynamoDB costs for workloads with steady usage and predictable growth over time.
(中略)
By purchasing capacity up front, you can save up to 54% (one-year term) or up to 77% (three-year term) over the regular hourly rates.
ただ、DDB-ReadUnitsIA と、DDB-ReplicatedWriteUnitsIA らが Database Savings Plans には対象として含まれており、IA がコスト最適化の対象という点で柔軟性があります。
このように、Aurora / RDS のディスカウント効果と合わせて見ても、柔軟性は素晴らしいものの 「特定の利用要件に合致する場合に、確実な割引率だけを求めるなら、Database Savings Plans は最適解ではない」 ということになります。
RI と Savings Plans の比較と使い分けを考える
では、どういう場合に Database Savings Plans を買うのが良いでしょうか？ それは「RI にはない柔軟性」と「RI が存在しないサービスへの適用」のためとなります。
ということで、それを考えるために主要なデータベース系サービスのコスト最適化オプションを整理してみました。
DB 系サービスの割引オプションの整理とまとめ
主要なデータベース系サービスの割引オプションと、Database Savings Plans の適用可否を表にまとめたものが以下です*3。
| サービス | サービスの詳細 | 予約モデル | DB SP の対象か？ | 推奨される購入戦略 |
|---|---|---|---|---|
| Aurora & RDS | Aurora / RDS Instances | あり (RI) | 対象 | 固定負荷は RI で最大化。移行予定や変動分のみ DB SP。 |
| Aurora Serverless v2 | なし | 対象 | DB SP 一択。 | |
| Aurora DSQL | なし | 対象 | DB SP 一択。 | |
| DynamoDB | Provisioned (Standard) | あり (RC) | 対象 | 固定負荷は RC で最大化。 |
| Provisioned (Standard-IA) | なし | 対象 | Standard-IA は RC 対象外のため DB SP 一択。 | |
| On-Demand | なし | 対象 | DB SP 一択。 | |
| ElastiCache | Valkey Instances | あり (RN) | 対象 | 固定ノードは RN で最大化。変動分があれば DB SP。 |
| Valkey Serverless | なし | 対象 | DB SP 一択。 | |
| Redis/Memcached Instances | あり (RN) | 対象外 | RN 一択。Valkey 移行を要検討。 | |
| Redis/Memcached Serverless | なし | 対象外 | 割引手段なし。Valkey 移行を推奨。 | |
| DocumentDB | DocumentDB Instances | なし | 対象 | DB SP 一択。 |
| DocumentDB Serverless | なし | 対象 | DB SP 一択。 | |
| Neptune | Neptune Instances | なし | 対象 | DB SP 一択。 |
| Neptune Serverless | なし | 対象 | DB SP 一択。 | |
| Timestream | Timestream | なし | 対象 | DB SP 一択。 |
| Keyspaces | Keyspaces | なし | 対象 | DB SP 一択。 |
| DMS | DMS Instances | なし | 対象 | DB SP 一択。 |
| DMS Serverless | なし | 対象 | DB SP 一択。 | |
| Redshift | Redshift provisioned clusters | あり (RN) | 対象外 | RN 一択。 |
| Redshift Serverless | なし | 対象外 | 割引手段なし。 | |
| OpenSearch | OpenSearch Instances | あり (RI) | 対象外 | RI 一択。 |
| OpenSearch Serverless | なし | 対象外 | 割引手段なし。 | |
| MemoryDB | MemoryDB Clusters | あり (RN) | 対象外 | RN 一択。 |
※RI: Reserved Instance, RC: Reserved Capacity, RN: Reserved Node, DB SP: Database Savings Plans
さて、これを前提に、Database Savings Plans を踏まえたコスト最適化戦略を考えてみましょう。
戦略1: RI (サービス独自の予約モデル) がないサービスのために買う
Neptune, Timestream, Keyspaces, DocumentDB や Serverless 系 DB サービスのために Database Savings Plans を採用するケースがあるでしょう。これらはサービス独自の予約モデル（コスト最適化サービス）が存在しないためです。
これらのサービスをヘビーユースしている場合、Database Savings Plans が唯一のコスト削減手段となります。
戦略2: 「移行」を前提とした保険として買う
- 「来年、RDS for Oracle から Aurora PostgreSQL へ移行するプロジェクトがある」
- 「大阪リージョンから東京リージョンへ移行するプロジェクトがある」
このような場合、DB Instance RI を買ってしまうと、エンジン変更や構成変更によって RI が無駄になるリスクがあります。
Database Savings Plans であれば、Oracle で使っていたコミット額を、そのまま移行後の Aurora に適用できるため、マイグレーション期間中のコスト最適化として最適です。ただし先に記載した通り、ディスカウント効果そのものは柔軟性が高い反面、低くなる傾向となっており、対象となるインスタンスクラスは第7世代と第8世代のみです*4。
戦略3: RI とのハイブリッド購入
これが現実的で効果が高い方法でしょう。
- ベースロード (60-80%):
24時間365日確実に稼働し、エンジン変更の予定もない RDS や DynamoDB については、割引率の高い RI (Reserved Instances) や RC (Reserved Capacity) をメインに購入します。 - 変動・不確実部分 (20-40%):
季節変動で増減する分や、開発環境、新しいサービスの検証（Aurora DSQLなど）については、柔軟性の高い Database Savings Plans でカバーします。特にリージョンに捕らわれない点も Database Savings Plans が有用な点です。
Database Savings Plans は、RI でカバーされなかったオンデマンド利用分に対して自動的に適用されます。この「漏れた分を拾ってくれる」特性を活かすのが賢い買い方です*5。
Database Savings Plans を見積もる
Savings Plans > Recommendations で、既に推奨の確認が可能となっています。
Savings Plans term が1年固定であることと、Payment option も No upfront に固定されます。
Purchase Analyzer でもDatabase Savings Plans を見積もることができます。
これらを用いて推奨を調べてみたところ、世代という縛りや、ディスカウント効果の低さもあってか、思ったよりコスト最適化効果は高くないようだと感じました。ですが、これまでコスト最適化が難しかった上澄み（変動/可変）部分をコスト最適化できる点は見逃せないメリットです。
その他の特筆すべき点など
AWS CLI に関する補足
以下のブログには You can get started from the AWS Management Console or use the AWS Command Line Interface (AWS CLI) and the API. と記述があります。
そして、以下の CLI 公式ドキュメントには更新がまだないですが、--plan-types Database で実行できます。
CloudShell の AWS CLI バージョンが古い場合、アップデートしてください。
SP を AWS CLI で運用するには、describe-savings-plans-offerings が必須です。やってみました。
aws savingsplans describe-savings-plans-offerings --plan-types Database
これだけで良いです。何故なら、Database Savings Plans は一種類しか存在しないためです。
{ "searchResults": [ { "offeringId": "fb3f8d09-c3ac-453e-84c4-6482102f4b93", "productTypes": [ "RDS", "Neptune", "DocDB", "Keyspaces", "ElastiCache", "Timestream", "DynamoDB", "DSQL", "DMS" ], "planType": "Database", "description": "1 year No Upfront Database Savings Plan", "paymentOption": "No Upfront", "durationSeconds": 31536000, "currency": "USD", "serviceCode": "DatabaseSavingsPlans", "usageType": "DatabaseSP:1yrNoUpfront", "operation": "", "properties": [] } ], "nextToken": "11111115011TmcQU582GqzXgntwKWfj4dfCRAJ3RzjCN9gzPNq4FSCviE4LNe8aNDPqqBjTbFAmPFnYiBpwKGGKgvfnos2qA7Bi8vRMTWcKwTeK" }
この offeringId があれば、AWS CLI で購入が可能です。
AWS 公式ドキュメント(User Guide)にまだ詳細は未記載
Savings Plans のドキュメントの history 等を見てみたのですが、現状以下のドキュメント以外に更新がなさそうです。
Savings Plans types では「Database Savings Plans」として以下の紹介がありました。都合、日本語訳でご紹介します。
Database Savings Plans は、Aurora、RDS、DynamoDB、ElastiCache、DocumentDB、Timestream、Neptune、Keyspaces、DMS のコストを最大 35% 削減しながら、AWS データベースサービスを柔軟に利用できるようにします。これらのプランは、エンジン、インスタンスファミリー、サイズ、アベイラビリティーゾーン (AZ)、リージョンに関係なく、プロビジョニングされた最新のインスタンス世代に自動的に適用され、サーバーレスの使用にも適用されます。たとえば、Database Savings Plans を使用すると、Aurora db.r7g インスタンスと db.r8g インスタンス間の変更、EU (アイルランド) から EU (ロンドン) へのワークロードの移行、RDS for Oracle から Aurora PostgreSQL 互換エディションへの最新化、割引料金を維持しながら RDS から DynamoDB へのワークロードの移行などが可能になります。
追ってアップデートがされるでしょう。
なお表にもある通り ElastiCache については、Pricing 一覧を見るに Cache Engine として Valkey のみが対象となっています。
まとめ
本ブログでは「Database Savings Plans を購入する前に一度は確認したい戦略ガイドと購入判断フロー」というタイトルで、「DB 系サービスの割引オプションの整理とまとめ」をメインディッシュに DB 系のコスト最適化戦略を整理しました。
Database Savings Plans は、既存の SP ほどに「何も考えずに買って大きく割引を得られる」という魔法のような（都合の良い）サービスではないことがご理解いただけたかと思います。しかし、RI ではカバーしきれない現代的なデータベース構成（Serverless, 新サービス, 頻繁な構成変更）に対しては十分なコスト最適化サービスにもなります。
- 対象サービス: Aurora, RDS, DynamoDB, ElastiCache (Valkey のみ), DocumentDB, Neptune, Timestream, Keyspaces, DMS。
- 対象外: Redshift, OpenSearch, MemoryDB と ElastiCache (Redis / Memcached)。
- 割引率: 12〜35% 程度と、同サービスの持つ RI に比べると控えめ（対象の多くは 20%）。
- 最大のメリット: エンジン、リージョン、ファミリーを跨げる柔軟性。
- 推奨戦略: RI が既にある DB サービスは基本 RI でベースを固め、柔軟性が必要な部分や RI がないサービスに対して Database Savings Plans を充てる「ハイブリッド構成」を目指すのがベター。
- 対象世代: Aurora, RDS, ElastiCache, DocumentDB, Neptune, DMS 等のプロビジョニング済みインスタンスは、最新世代（Gen7, Gen8 以降）のみが対象。
最後に簡単な Database Savings Plans 採用判断フローをご用意しました。数字は各ステップです。
Database Savings Plans のための購入判断フロー
| # | 質問/判断 | YES の場合 | NO の場合 |
|---|---|---|---|
| 1 | 利用したいデータベースサービスに、独自の予約モデル（RI/RC/RN）は存在するか？ | ステップ 3 へ進む。 | ステップ 2 へ進む。 |
| 2 | そのサービスは DB SP の対象サービスに含まれているか？ | DB SP を採用する。唯一のコスト最適化手段となる。 | 割引手段なし。 |
| 3 | 利用リソースは DB SP の対象（Gen7, 8 世代、Valkey、Serverless 等）、または対象世代へ移行可能か？ | ステップ 4 へ進む。 | RI/RC/RN を採用する。DB SP 対象外のため。 |
| 4 | 今後1年以内に、DBエンジン変更、インスタンスファミリー世代交代、リージョン間移行の可能性があるか？ | DB SP を採用する。移行リスクへの保険とする。 | ステップ 5 へ進む。 |
| 5 | 24時間稼働のベース部分（固定）と、一時的な利用や変動部分（可変）が混在しているか？ | ベースロードを RI/RC でカバーし、変動分のみ DB SP をハイブリッド採用する。 | ステップ 6 へ進む。 |
| 6 | 利用構成（エンジン、インスタンス、リージョン）が完全に固定されており、割引率を最大化したいか？ | RI/RC/RN を採用する。DB SP よりも高い割引効果を得る。 | DB SP を採用する。DB SP の柔軟性を最大限に活用する。 |
この Database Savings Plans 判断フローが、採用可否のご判断の目安となれば幸いです。
では、またお会いしましょう。
*1:Savings Plans を SPs と略す場合もありますが、一旦長いので今回 s は使っていません
*2:残念です。何故省かれたのでしょうか
*3:本ブログで最大に時間がかかったのがこの「まとめ」です
*4:RDS ではインスタンスタイプではなく、インスタンスクラスと言います
*5:適用順としては、Savings Plans よりも RI が優先される仕様です。これは Savings Plans が登場してからの仕様となっています
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
セキュリティサービス部所属。AWS資格全冠。2010年1月からAWSを業務利用してきています。主な表彰歴 2021-2022 AWS Ambassadors/2020-2025 Japan AWS Top Engineers/2020-2025 All Certifications Engineers。AWSのコスト削減やマルチアカウント管理と運用を得意としています。
