AuroraのコストをReserved Instances（以下RI）で削る、というのは以前から知られた手法です。これに加えて、2025年12月にDatabase Savings Plans（以下DBSP）が登場し、AuroraでもSavings Plansが使えるようになりました。それ以前のSavings PlansはEC2・Fargate・Lambda・SageMakerのみを対象としており、Auroraのコミットメント割引はRIしかありませんでした。
本記事では、Auroraにおけるこの2つの割引の使い分けを整理します。先に前提としてAuroraの課金モードと各割引の概要を説明し、判断の観点を整理した後、コミットメント割引以外のコスト最適化も含めた進め方と注意点を述べます。料金や割引率は記事末尾の公式ページに基づきます。
前提：Auroraのコンピュートは2モードある
Auroraのコンピュート課金には2つのモードがあり、利用できる割引が異なります。
- プロビジョンドインスタンス：
db.r7g.largeのようにインスタンスのクラスとサイズを指定し、時間単位で課金されます。RIとDBSPの両方が対象です。 - Aurora Serverless v2（現在の名称はAurora serverless）：ACU（Aurora Capacity Unit）という単位で、負荷に応じて自動的にスケールします。インスタンス課金ではないため、RIの対象外です。コミットメント割引はDBSPのみが使えます。
したがって、Serverless v2を使う場合は割引の選択肢がDBSPに限られます。
なお、Aurora Serverless v1は2025年3月31日にEOL（End of Life）を迎えており、本記事では対象に含めていません。
RIとDBSPの概要
両者の主な違いを表にまとめます。
| Reserved Instances | Database Savings Plans | |
|---|---|---|
| 対象 | プロビジョンドのみ | プロビジョンド（第7世代以降）とServerless v2 |
| 期間 | 1年 / 3年 | 1年のみ |
| 前払い | 全額 / 一部 / なし | なしのみ |
| 最大割引 | 1年 最大45% / 3年 最大66% | サーバーレス 最大35% / プロビジョンド 最大20% |
| 柔軟性 | 同一リージョン・同一インスタンスファミリー内で、サイズとクラスタストレージ構成（Standard / I/O-Optimized）をまたいで適用（リージョンはまたがない） | エンジン・ファミリー・サイズ・リージョン・デプロイ形態をまたいで自動適用 |
割引率だけを見ると、プロビジョンドを3年間コミットする場合の最大値はRIのほうが大きく、3年RIの最大66%に対してDBSPのプロビジョンド割引は最大20%です。一方でDBSPは、コミット後に構成を変更しても割引が追従します。なお、同一ワークロードにRIとDBSPを併用することはできません。
判断の観点
以下は、どちらが向きやすいかを判断するための観点です。
- Serverless v2を使う、または使う予定がある：割引の選択肢はDBSPに限られます。RIはServerless v2に適用されません。
- 安定して使い続けられるプロビジョンドである：割引率はRIのほうが高く、1年RIで最大45%、3年RIで最大66%と、いずれもDBSPのプロビジョンド割引（最大20%）を上回ります（期間が長いほど割引は大きくなります）。
- 前払いで割引を最大化したい：前払いを選べるのはRIのみです。DBSPに前払いの選択肢はありません。
- エンジン移行・リージョン移動・世代更改（例：r7g→r8g）・将来のServerless化を見込む：構成変更後も割引が維持されるのはDBSPです。RIは対象のインスタンスファミリーやリージョンに紐づきます。
- 対象が第7世代より前のプロビジョンドである：DBSPのプロビジョンド割引は第7世代以降が条件のため、旧世代ではDBSPのプロビジョンド割引が適用されません。
コミットメント割引の前に：多角的なコスト最適化
RIとDBSPはコミットメント割引で、効くのは「使い続けるリソースの単価」です。その手前に、そもそも使う量や構成を見直す余地があります。AWSのコスト最適化ガイド（Optimize costs in Amazon Aurora）では、ワークロードの性質ごとに次のような観点が挙げられています。
- コンピュート：変動が大きいワークロードはServerless v2（最小0 ACUまでスケールダウン可能）、開発・検証環境は起動/停止スケジュール、用途に対して過剰なインスタンスはライトサイジング（T系やGraviton、最新世代の検討、Compute Optimizerの推奨を活用）。
- I/Oとストレージ：ストレージ構成（Standard / I/O-Optimized）の見直し（後述）、クエリ・インデックス最適化によるI/O削減、不要なテーブル・インデックスの削除、履歴データのS3アーカイブ。
- データ管理：パーティショニングと古いデータのアーカイブ、Redshiftへのzero-ETL連携による分析系のオフロード。
- DR・冗長化：Aurora Global Databaseのheadlessクラスタ（セカンダリリージョンにインスタンスを持たず、コンピュート料金を発生させない）、バックアップ保持期間の見直し、孤立スナップショットの削除。
- レプリカ：リードレプリカのAuto Scaling、（Aurora MySQLのみ）レプリケーションフィルタによる選択的レプリケーション。
これらで使用量と構成を整えてから、残った安定的な利用にRIまたはDBSPを当てる、という順序になります。
I/O-Optimized：ストレージ構成の選択
Auroraのストレージ構成にはAurora StandardとAurora I/O-Optimizedの2つがあります。Standardはストレージと、リクエストごとのI/Oに対して課金されます。I/O-OptimizedはI/Oの従量課金がゼロになり、インスタンスとストレージのみの課金になります。その代わり、インスタンスとストレージの単価は上がります。
AWSは、I/Oの費用がAurora全体の費用の25%を超える場合に、I/O-Optimizedで最大40%のコスト削減が見込めるとしています。逆に、I/Oの費用が25%未満の場合はStandardのほうが安くなる、というのがAWSの示す目安です。判断にあたっては、Cost ExplorerでI/O関連の使用タイプが全体に占める割合を確認します。構成はクラスタ単位で、I/O-Optimizedへは30日に1回切り替えでき、Standardへはいつでも戻せます。
I/O-Optimized利用時のRIの調整
RIを使っている場合、I/O-Optimizedに切り替えると、AuroraがStandardとの価格差を自動的に調整します。RIの割引をI/O-Optimizedでも維持するには、現在のRIに対しておよそ30%分のRIを追加購入します（追加しない分にはOn-Demandレートが適用されます）。
「30%分」は専用のRI商品を買うわけではなく、同種のRI（同じエンジン・インスタンスクラス・リージョン・期間・支払いタイプ）を数量分多く買うだけです。必要数は「現在のRI数 × 1.3」で求め、そこから現在数を引いた差が追加購入分になります。端数が出る場合は、RIのサイズ柔軟性を使って小さいサイズのRIを組み合わせ、正規化単位（normalized units、後述）の換算で整数に合わせます。公式の計算例は次のとおりです。
| 現在のRI | 必要数（× 1.3） | 追加購入 |
|---|---|---|
| db.r6g.large × 10 | 13 | db.r6g.large × 3 |
| db.r6i.24xlarge × 15 | 19.5 | db.r6i.24xlarge × 4 ＋ db.r6i.12xlarge × 1（0.5 × 24xlarge = 12xlarge） |
| db.r6g.12xlarge × 5 | 6.5 | db.r6g.12xlarge × 1 ＋ db.r6g.4xlarge × 1 ＋ db.r6g.2xlarge × 1（0.5 × 12xlarge = 4xlarge ＋ 2xlarge） |
この表の「0.5」のような小数は、RIのサイズ柔軟性から来ています。RIは買ったサイズに固定されず、同一インスタンスファミリー（同じエンジン・同じリージョン）内では「正規化単位（normalized units）／時」という共通の物差しで管理されます。各サイズの正規化係数は大きさに比例し（large=4、xlarge=8、2xlarge=16、4xlarge=32、12xlarge=96、24xlarge=192…）、割引は合計の正規化単位の範囲で、ファミリー内の任意のサイズの組み合わせに自動適用されます。したがって「0.5 × db.r6i.24xlarge」は、24xlarge（192単位）の半分＝96単位＝db.r6i.12xlarge（96単位）ちょうど、という意味になります。小数のRIを買うのではなく、同じ正規化単位を持つ小さいサイズの実在RIに置き換えているだけです（同様に 0.5 × 12xlarge = 48単位 = 4xlarge ＋ 2xlarge）。
「30%」という数字自体にも理由があります。Aurora I/O-OptimizedはAurora Standardより1時間あたりの正規化単位を30%多く消費します。Standardとして買った既存RIのままではI/O-Optimizedの消費単位を一部しかカバーできず、30%分の単位を追加購入すると元の割引が維持される、という関係です。
購入操作自体は通常のRIと同じで、RDSコンソールの「Reserved instances」、AWS CLIのpurchase-reserved-db-instances-offering（--db-instance-countで数量を指定）、RDS API／SDKのいずれかで行えます。
判断の手順
前節の最適化で使用量と構成を整えた後、残った安定したベースラインに対してRIとDBSPのどちらを使うかを検討します。ここまでの観点を図にすると次のようになります。
いくつかの注意点
RIを買った後にServerless v2へ移行すると、RIが無駄になります。 プロビジョンドにRIを割り当てた後でServerless v2へ移行した場合、RIはServerless v2に適用されないため、残りの期間が無駄になります。移行が予定されている場合、これが判断材料になります。RIの期間を1年にとどめる、移行後にACUの消費量を確認してから検討する、といった対応が考えられます。
RIとDBSPは併用できません。 既存のRIが残っている場合、満了時期とDBSPの開始時期が重ならないように検討することになります。
RIでも対象外の課金があります。 T4g・T3インスタンスのCPUクレジット課金はRIの対象外です。バースト系のインスタンスを多用している場合、想定より割引が乗らないことがあります。
購入の進め方
AWS Well-Architectedフレームワークのコスト最適化（COST07-BP05）では、購入の進め方について次のような考え方が示されています。
- 管理アカウントで集約して分析する。個別のアカウント単位よりも集約したレベルで見るほうが、変更リスクが下がり、割引の効果も見積もりやすいとされています。
- Cost ExplorerのSavings Plans / RIレコメンドを根拠にする。DBSPはSavings Plans Purchase Analyzerでカスタムシナリオの試算もできます。
- 2週間から1か月のサイクルで見直し、一度に大きく購入せず少しずつ積み増す。
おわりに
Serverless v2か、長期で安定したプロビジョンドか、構成が変わる前提か、といった条件で向きやすい割引が変わります。どちらを選ぶかはワークロードの性質やプロジェクトごとのリスク許容度によって変わり、割引率や対象インスタンスもリージョンや時期によって変わります。最終的には、利用実績をCost ExplorerやSavings Plans Purchase Analyzerで確認した上で判断するのがおすすめです。
参考URL
- Amazon Aurora 料金 … RIの割引率・対象、I/O-OptimizedでのRI再利用
- Announcing Database Savings Plans with up to 35% savings（What's New, 2025-12-02）
- Introducing Database Savings Plans for AWS Databases（AWS News Blog） … サーバーレス35% / プロビジョンド20%の内訳
- Database Savings Plans 料金 … RIとの併用不可、対象に「Aurora Serverless v2」を明記
- Optimize costs in Amazon Aurora（AWS Database Blog） … Aurora向けの多角的なコスト最適化（コンピュート・I/O/ストレージ・DR・レプリカ等）、RIとDBSPの関係
- Savings Plans FAQ … Savings Plansの種類、第7世代以降が対象
- Savings Plans Purchase Analyzer（What's New, 2024-11-22） … コミット額・シナリオを指定して節約額・カバレッジ・使用率を試算
- Aurora Serverless v1（EOL: 2025年3月31日）
- Aurora serverless（旧Aurora Serverless v2、2026年4月に改称）
- Purchasing reserved DB instances for Amazon Aurora … コンソール / CLI / API でのRI購入手順
- Reserved DB instances for Amazon Aurora … サイズ柔軟性（正規化単位）、I/O-Optimizedは正規化単位を30%多く消費
- Well-Architected COST07-BP05