AWS Cost Optimization Vol4｜Database Savings Plans本番運用

1. この記事について

1-1. 本記事のゴール

本記事は「AWS Cost Optimization本番運用」シリーズのVol4として、2025年12月にGAとなったDatabase Savings Plansを対象に、「どのDBサービスが対象か」「どの程度割引されるか」「どう購入額を判断するか」という3つの実務課題を解決します。Vol1で扱ったCompute SP/EC2 Instance SPがコンピュートリソースのコミット割引であったのに対し、本Vol4はAurora・RDS・DynamoDBをはじめとするデータベースサービスのコミット割引を扱う点が最大の違いです。

Database Savings Plansは、$/hour単位で1年間の利用コミットを行うことで、対象DBサービスの利用料が自動的に割引される仕組みです。EC2向けのCompute SPと同様に「エンジン・インスタンスファミリー・サイズ・デプロイ形態・リージョンを問わず」自動適用される柔軟性を持ちますが、割引率や対象サービスの範囲はDB特有の条件で定められています。本記事ではこの割引率の内訳(デプロイ形態別・サービス別)を正確に整理し、Cost Explorerのカバレッジ分析に基づいて購入額を判断するための考え方を解説します。

両者の位置付けを表で整理すると、以下のとおりです。対象サービス・コミット単位は似ていますが、割引率レンジと購入オプションには明確な違いがあります。

本記事を読み終えた時点で、Database Savings Plansの対象サービス一覧・割引率マトリクス・自動適用の対象判定条件を理解し、自組織のDB支出のうちどの程度をコミット購入に回すべきかをカバレッジ分析から判断できる状態に到達します。あわせて、Compute SPとDatabase SPを併用する場合の適用優先順位(レイヤリング)についても触れます。

Cost Explorerでの分析からSavings Plans推奨の確認、購入額の判断、購入後のカバレッジ・利用率モニタリングまでを一連のFinOps運用フローとして捉え、Database Savings Plansをその中にどう組み込むかという実務的な視点で解説を進めます。

具体的な割引イメージを掴むために、教育目的の試算例を示します。実際の削減額はワークロード構成・リージョン・コミット額により大きく異なるため、必ず自組織のCost Explorer実データで再計算してください。

上記はあくまで教育目的のモデルケースであり、実際の割引額はコミット額の設定・利用パターン・各サービスの実際の適用条件によって変動します。§4のカバレッジ分析では、この考え方を自組織の実データに置き換えて購入額を判断する手順を解説します。また、Aurora ProvisionedとDynamoDB on-demandでは同じ「最大」表記でも割引率が大きく異なる点に注意してください。デプロイ形態ごとの割引率の内訳は§2-3で一覧化します。

なお、本記事のコード例・購入額試算はすべて教育目的のサンプルです。実際の購入判断にあたっては、必ず自組織のCost Explorer上の実データとAWS公式ドキュメントの最新情報を確認してください。

本記事における「割引率」の表記は、いずれもAWS公式ドキュメント記載の最大値を指します。実際に適用される割引率は、コミット額とオンデマンド利用料の比率(コミット充足率)によって変動するため、常に最大値が適用されるとは限りません。この点は§3-2で詳しく解説します。

1-2. 読者像

本記事の対象読者は、すでにAurora/RDS/DynamoDB/ElastiCache/DocumentDB/Neptune/Keyspaces等のいずれかを本番運用しており、DB利用料のコミット割引導入を検討しているFinOps担当・SRE・コストオーナーです。

たとえば、Vol1でCompute SPをすでに導入済みでDB費用の最適化余地を探している方、Cost ExplorerでDB利用料の割合が高いことに気づいたがどのコミット商品が対象になるか把握できていない方、複数のDBサービスを横断運用しておりサービスごとの個別購入は煩雑だと感じている方が該当します。

AWSアカウントの基本操作とCost Explorer/Savings Plansの基礎知識があれば、本記事の内容を実践できます。Terraform未経験でも問題ありませんが、§5で扱うBudgetsアラートの構築では、Terraformの基礎知識があるとより理解が深まります。

本記事は特定の組織規模を前提としていませんが、月間DB利用料が数百ドル以下の小規模環境ではコミット購入によるリスク(将来的な利用量減少時の余剰コミット)が相対的に大きくなるため、§4のカバレッジ分析を用いて慎重に判断することを推奨します。逆に月間DB利用料が数千ドル規模以上に達している組織では、Database Savings Plans導入による削減効果が大きくなりやすい傾向にあります。

各§はそれぞれ独立して読めるように構成しています。§3(仕組みと自動適用)・§4(購入戦略とカバレッジ分析)・§5(Terraform/Budgets対応範囲)のうち、直面している課題に対応する§から優先して読み進めても問題ありません。

1-3. なぜ今これを書くか

Database Savings Plansは2025年12月2日にGAとなった比較的新しい機能で、東京リージョンを含む全リージョン(China除く)で利用可能です。2026年3月にはOpenSearch ServiceとNeptune Analyticsが対象サービスに追加され、対象範囲は現在も拡大を続けています。GA以降の主な経緯を整理すると、以下のとおりです。

本記事を執筆する動機は、既存のCost Optimization本番運用シリーズがVol1でCompute SPのみを扱っており、DBサービスを横断するコミット割引についての解説が空白だったことです。Database Savings Plansは対象サービスが9種類(GA時点)から11種類(2026-03時点)へと拡大しており、デプロイ形態(Serverless/Provisioned)やサービス(DynamoDB/Keyspacesのon-demand/provisioned)によって割引率が異なるため、正確な一次情報に基づく整理が必要だと判断しました。

また、Compute SPを既に導入している組織にとって、Database SPとの併用時にどちらが優先的に適用されるか(レイヤリングの考え方)を理解しないまま両方を購入すると、想定した割引を得られないことがあります。本記事ではこの適用優先順位についても§3で明確に整理します。

Cost Optimization本番運用 Vol1(Compute SP編)を読む

1-4. 読み進め方ガイド

本記事は通読を基本としますが、目的に応じて以下の読み進め方も可能です。

§2で前提条件と対象サービス・割引率の全体像を把握したうえで、§3(仕組み)→§4(購入戦略)→§5(Terraform/Budgets対応)の順に読み進めると、判断から実装までを一気通貫で理解できます。前提記事未読の方は§2で要点を確認できるため、本記事から読み始めることも可能です。§6・§7はどの読み方をした場合でも、最後に必ず目を通すことを推奨します。

前提記事であるVol3ではBilling Conductor/Cost Categories/Data Exportsを扱っており、本Vol4のDatabase Savings Plansはそれらのコスト可視化基盤の上に「DBコミット割引」という削減手段を追加する位置付けです。

Cost Optimization本番運用 Vol3(Billing Categories編)を読む

2. 前提・環境・準備

本章では、Database Savings Plansの購入判断を進めるために必要な前提条件・対象サービス・割引率・リージョン対応・IAM権限・本記事で扱う範囲の6項目を整理します。§3以降の解説はすべて本章の内容を前提とするため、初めての方は§2-2・§2-3から必ず目を通してください。

2-1. 前提条件

本記事の内容を実践するにあたり、以下の前提条件を満たしていることを確認してください。

AWS環境

知識面の前提

Vol1のSavings Plans節を未読の場合も、本章の内容だけで読み進められるように構成しています。

2-2. 対象サービスと適用範囲

Database Savings Plansの対象サービスは、GA時点(2025-12-02)の9サービスから2026-03時点で11サービスへと拡大しています。取得日2026-07-14時点の対象サービス一覧は以下のとおりです。

対象サービスは用途別に大きく5グループへ分類すると理解しやすくなります。

リレーショナルDB系(Aurora/RDS) — 最も利用実績の長いグループです。Auroraは Provisioned と Serverless v2 の両方が対象となり、同一クラスター内でも起動しているインスタンスのデプロイ形態ごとに異なる割引率区分が適用されます。RDSはProvisionedのみが対象です。

NoSQL系(DynamoDB/Keyspaces/DocumentDB) — DynamoDBとKeyspacesはキャパシティモード(on-demand/provisioned)によって割引率区分が変わります。この点は本グループの特徴です。DocumentDBはProvisionedとElastic Clustersの両方が対象です。

インメモリ/グラフDB系(ElastiCache/Neptune) — ElastiCacheはRedis OSS互換・Valkey・Memcachedいずれのエンジンも対象です。NeptuneはProvisionedとServerlessの両方に対応します。

検索/分析系(OpenSearch Service/Neptune Analytics) — 2026-03に対象追加された最も新しいグループです。OpenSearch ServiceはProvisioned/Serverlessの両方、Neptune AnalyticsはServerlessのみが対象です。

移行/時系列系(DMS/Timestream) — DMSはレプリケーションインスタンスのProvisioned利用が対象です。Timestreamは時系列データ向けのProvisionedキャパシティが対象になります。

自動適用の対象判定は「エンジンの種類・インスタンスファミリー・インスタンスサイズ・デプロイ形態(Provisioned/Serverless)・リージョン」を問わず行われます。これはCompute SPが「インスタンスファミリー・OS・テナンシー・リージョンを問わず」自動適用されるのと同じ設計思想です。対象サービスは今後も拡大が見込まれるため、購入検討時には必ずAWS公式のSavings Plans対象サービスページで最新の一覧を再確認してください。

2-3. デプロイ形態別 割引率マトリクス

割引率はデプロイ形態・サービスの課金モデルによって以下の4区分に分かれます(取得日2026-07-14)。

同じ「最大」表記でも区分によって最大10ポイント以上の差があるため、購入計画時にはワークロードがどの区分に属するかを正確に把握することが重要です。特にDynamoDBは同一テーブルでもキャパシティモードの選択次第で適用される割引率区分が変わる点に注意してください。

サービス単位で割引率区分を整理すると、以下のとおりです。1サービスが複数のデプロイ形態を持つ場合、それぞれに異なる区分が適用されます。

この一覧はCost ExplorerのSP推奨画面でも同様の粒度(サービス×デプロイ形態)で表示されます。§4のカバレッジ分析では、この単位でコミット額を配分する考え方を解説します。

コミット条件は以下のとおりです。

Compute SPが1年・3年、All/Partial/No Upfrontの複数オプションを提供するのに対し、Database SPは執筆時点(2026-07-14)では1年・前払いなしの単一オプションのみです。この差は購入判断のシンプルさにつながる一方、長期コミットによる追加割引は得られない点に留意してください。

主要リージョンの対応状況を確認すると、以下のとおりです。

中国リージョンを除く全リージョンが対象であるため、マルチリージョン構成であってもリージョンごとに個別のSPを購入する必要はなく、1つのDatabase Savings Plansで対応するすべてのリージョンの利用料に自動適用されます。

2-4. 必要なIAM権限

Database Savings Plansの購入・確認に必要な権限は以下のとおりです。

購入操作は原則として少人数の管理者ロールに限定し、閲覧系の権限(カバレッジ・利用率確認)をFinOps担当者に広く付与する権限設計を推奨します。マネージドポリシーとしてはAWSBillingReadOnlyAccess(閲覧)とAWSBillingConductor系ポリシー(購入・管理)の組み合わせが目安になりますが、最小権限の原則に基づき自組織のIAMポリシーとして再定義することを推奨します。

閲覧専用ロールのIAMポリシー例は以下のとおりです。購入権限を含まないため、FinOps担当者への安全な権限付与に利用できます。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "DatabaseSavingsPlansReadOnly",
"Effect": "Allow",
"Action": [
  "ce:GetSavingsPlansPurchaseRecommendation",
  "ce:GetSavingsPlansCoverage",
  "ce:GetSavingsPlansUtilization",
  "ce:GetSavingsPlansUtilizationDetails",
  "savingsplans:DescribeSavingsPlans",
  "savingsplans:DescribeSavingsPlanRates"
],
"Resource": "*"
 }
  ]
}

購入権限(savingsplans:CreateSavingsPlan)は上記ポリシーに含めず、別ロールとして管理者にのみ付与することで、閲覧担当者が誤って高額なコミット購入を実行するリスクを排除できます。

2-5. 本記事で扱う範囲(使用するAWS機能一覧)

本記事の各§で扱うAWS機能・画面の対応関係は以下のとおりです。

Savings Plansの購入操作は、2026-01-28リリースのhashicorp/aws provider v6.29.0で追加されたaws_savingsplans_savings_planリソース(およびaws_savingsplans_offeringsデータソース)を通じてTerraform管理も可能です。ただしプロバイダー側が「best effort」と明記する新しいリソースであるため、本番導入時は§5-2で詳説する注意点をあわせて確認してください。

2-6. 用語整理

本記事で頻出する用語を以下に整理します。§3以降はこの定義を前提に解説します。

これらの用語はAWS公式ドキュメントの表記に準拠していますが、一部は本記事内での説明の便宜上、平易な日本語で言い換えています。正確な定義は必ずAWS公式ドキュメントを参照してください。

2-7. ゴール状態の定義

本記事を完走した時点で、以下の状態に到達していることを目指します。

• Database Savings Plansの対象11サービス(2026-03時点)と、それぞれが属する割引率区分(Serverless/Provisioned/DynamoDB・Keyspaces on-demand/provisioned)を一覧で説明できる
• 自動適用の対象判定条件(エンジン/インスタンスファミリー/サイズ/デプロイ形態/リージョン不問)と、Compute SPとの適用優先順位(レイヤリング)を説明できる
• Cost ExplorerのSP推奨とカバレッジ分析に基づき、自組織のDB利用料のうちどの程度をDatabase SPのコミットに回すべきかを判断できる
• Terraformで管理できる範囲(Budgetsアラート)と管理できない範囲(SP購入自体)を切り分けて説明できる
• 過剰コミット・二重コミットといった典型的なアンチパターンを回避した購入計画を立案できる

各ゴールは§3〜§6にそれぞれ対応しています。§7では、これらのゴールへの到達状況をチェックリスト形式で振り返ります。

3. Database Savings Plans の仕組みと自動適用

本章では、Database Savings Plansが「どのように」利用料へ自動適用されるかを、対象判定条件・コミット額の消化ロジック・Compute Savings Plansとの関係・モダナイズ時の割引継続性の4つの観点から整理します。§2で確認した対象サービスと割引率区分を前提に、実際の請求への反映のされ方を理解することが本章のゴールです。

3-1. 自動適用の対象判定条件

Database Savings Plansは、購入時に指定したコミット額($/hour)の範囲内で、以下の5要素を問わず対象DBサービスの利用料へ自動的に割引を適用します。

AWS公式発表(2025-12-02)では、この柔軟性を具体例で示しています。「Aurora db.r7g から db.r8g へのインスタンスファミリー変更」「EU(アイルランド)からUS(オハイオ)へのリージョン移動」「RDS for Oracle から Aurora PostgreSQL へのモダナイズ」「RDS から DynamoDB へのモダナイズ」のいずれも、変更後も割引適用が継続すると明記されています。これはCompute SPが「インスタンスファミリー・OS・テナンシー・リージョンを問わず」自動適用されるのと同じ設計思想であり、Database SPはこれをデータベースサービス全体に拡張したものと理解できます。

3-2. コミット額の消化ロジックとカバレッジ・利用率の関係

Database Savings Plansは、購入時に指定した$/hourのコミット額を1年間、毎時間分課金対象として消化していきます。ここで押さえるべきポイントは以下の2点です。

• コミット額は利用の有無にかかわらず課金される: 購入したコミット額(例: $10/hour)は、実際のDB利用が少ない時間帯であっても、その時間分の請求が発生します。サブスクリプションに近い性質を持つ仕組みです
• コミット額を超える利用分はオンデマンド料金で課金される: 実際のオンデマンド換算利用額がコミット額を上回った時間帯は、超過分がオンデマンド料金のまま請求されます

この2点から、Database Savings Plansの経済効果を最大化するには、実際の利用額にできるだけ近いコミット額を設定することが重要になります。コミット額が実利用より大きすぎると未消化分(利用率の低下)が発生して余剰コミットとなり、逆にコミット額が実利用より小さすぎるとカバレッジ(割引適用割合)が下がり、削減効果を取りこぼします。この実利用とコミット額のバランスを評価する具体的な手順は§4で解説します。

なお、AWS公式ドキュメントは、複数の対象サービス・デプロイ形態にまたがる利用がある場合の時間内配分アルゴリズム(どのサービスの利用から優先的に割引が適用されるかの詳細な数式)までは公開していません(取得日2026-07-14時点)。Compute SPが「コミット額の範囲内で最も割引率の高い利用から優先的に適用される」設計思想を持つことを踏まえると、Database SPも同様の思想に基づくと考えられますが、実際の適用結果は必ずCost ExplorerのSavings Plansカバレッジ・利用率レポートで確認してください。

3-3. Compute Savings Plans との関係(「優先順位」が実質発生しない理由)

§1で「適用優先順位は§3で解説」と予告しましたが、実態としてはCompute SPとDatabase SPは対象サービスが重複しないため、請求時点での「どちらが優先的に適用されるか」という競合判断自体が発生しません。両者は独立した2つのコミットとして並行運用されます。実務上「優先順位」として検討すべきなのは適用時の競合ではなく、限られたFinOps予算をCompute SPとDatabase SPにどう配分するかという購入戦略上の判断です。この配分の考え方は§4-4で扱います。

一方、Database SP自体は、同一ワークロードに対してRDS予約インスタンス(Reserved Instances)やDynamoDB予約キャパシティ(Reserved Capacity)と併用できません。同一利用に対して複数の割引商品を重ねて適用しようとする二重コミットは、想定した割引が得られない、あるいは一方の割引が無駄になるといった問題につながるため、購入前に既存の予約商品との重複がないか確認することを推奨します。

3-4. モダナイズ・移行時の割引継続性

Database Savings Plansのもう一つの実務的な利点は、DBのモダナイズ・移行をしても、コミットした割引が失われない点です。AWS公式発表では、以下の変更パターンでも割引は継続すると明記されています(取得日2026-07-14)。

この特性は、既存のオンプレミス/レガシーDB(Oracle等の商用ライセンスDB)からAurora PostgreSQL等のオープンソース互換DBへの移行を計画している組織にとって重要です。移行完了を待たずにDatabase Savings Plansを購入しておいても、移行後の利用に対してコミットした割引が引き続き適用されるため、モダナイズプロジェクトの投資対効果を早期に確定できます。ただし、対象サービス自体が変わる場合(例: RDSからDynamoDBのようにDBの種類が根本的に変わる場合)は、移行後のサービスもDatabase SPの対象11サービス(§2-2)に含まれていることが前提になります。対象外のサービスへ移行した場合は割引が適用されない点に注意してください。

4. 購入戦略とカバレッジ分析

本章では、Database Savings Plansのコミット額をどう決定し、購入後どのようにモニタリングするかを、Cost Explorerの機能を軸に整理します。あわせて、Compute SPとの予算配分の考え方(レイヤリング戦略)も扱います。

4-1. 購入前に使う3つのツール

AWSはDatabase Savings Plansの購入判断を支援するため、以下3つのツールを提供しています(取得日2026-07-14、Database Savings Plans料金ページ準拠)。

Purchase Analyzerでは、コミット額とlookback期間(過去何週間分の利用実績を参照するか)を調整すると、画面上でカバレッジ・削減額の推定値がリアルタイムに更新されます。実際のコミット額を決定する前に、複数のコミット額パターンをシミュレーションし、カバレッジと余剰コミットのトレードオフを確認することを推奨します。

4-2. コミット額の決め方(段階購入)

Database Savings Plansは1年コミットの単一オプションであり、Compute SPのように3年コミットで追加割引を狙う選択肢がありません(§2-3参照)。そのため、コミット額の初期設定を誤ると1年間にわたって余剰コミットまたはカバレッジ不足の影響を受け続けることになります。この特性を踏まえ、Vol1のCompute SPと同様、以下の段階購入アプローチを推奨します。

1. 初回購入は推奨額の70-80%程度に抑える: SP推奨額をそのまま全額コミットするのではなく、直近のDB利用実績のうち安定して発生している(季節変動やスパイクを除いた)ベースライン相当の70-80%を初回コミット額とします
2. 1〜2ヶ月間、カバレッジ・利用率を実測する: 購入後はCost Explorerのカバレッジ/利用率レポート(§4-3)で実際の消化状況を確認します
3. 利用率が高水準(95%以上目安)で安定していれば追加購入を検討する: 既存コミットの利用率が高く、かつカバレッジに伸びしろがある場合、追加のDatabase Savings Plansを購入して段階的にカバレッジを引き上げます
4. 追加購入も同様に70-80%ルールを適用する: 一度に全カバレッジを埋めようとせず、複数回に分けて購入することで、将来的な利用量減少時の余剰コミットリスクを抑えます

段階購入により、DB利用量が増加傾向にある組織では追加コミットのタイミングを実測データに基づいて判断でき、逆に利用量が不安定な組織では過剰コミットのリスクを抑えられます。

4-3. カバレッジ分析とモニタリング

§2-6で整理したとおり、カバレッジ(Coverage)は対象サービスの利用料のうちSP割引が適用されている割合、利用率(Utilization)は購入したコミット額のうち実際に消化された割合を指します。この2つの指標は購入判断・購入後モニタリングの両方で異なる役割を果たします。

理想的な状態は、カバレッジと利用率がともに高い状態です。カバレッジが低く利用率だけ高い場合は、追加購入の余地があります。カバレッジは高くても利用率が低い場合は、コミット額は過大である可能性があります。両指標をあわせて確認することで、単独の指標だけでは見えない購入額の過不足を判断できます。

Cost ExplorerのSavings Plansカバレッジレポート・利用率レポートは、サービス別・デプロイ形態別(§2-3の割引率区分単位)にドリルダウンして確認できます。特定のサービス(例: DynamoDB)だけカバレッジが低い場合、そのサービスの利用実績に基づいて追加コミットの配分を調整するといった、サービス単位での購入戦略の微調整も可能です。§5で扱うBudgetsアラートは、このカバレッジ・利用率の閾値割れを継続的に検知する仕組みとして位置付けられます。

4-4. Compute Savings Plansとの予算配分(レイヤリング戦略)

Compute SPをすでに導入済みの組織がDatabase SPを追加検討する場合、既存のCompute SPのカバレッジ・利用率を悪化させることはありません(対象サービスが重複しないため)。したがって、Database SPの追加は既存のCompute SP運用に影響を与えない独立した意思決定として進められます。逆に、これから両方を新規導入する組織では、Cost Explorerでコンピュート利用料とDB利用料の内訳比率を確認し、金額の大きい方から優先的にSP推奨を確認していくアプローチが効率的です。

5. Terraform/Budgets対応範囲と監視

本章では、Database Savings Plansの「購入」と「監視」のそれぞれについて、Terraformで何ができて何ができないかを一次情報に基づいて整理します。この領域はプロバイダーのアップデートで状況が変わりやすいため、以下は取得日(2026-07-14)時点の情報であることに留意してください。

5-1. Terraformで管理できる範囲・できない範囲(全体像)

2026年3月時点では「SP購入自体はTerraform非対応」という理解が一般的でしたが、2026-01-28リリースのhashicorp/aws provider v6.29.0で状況が変わりました。ただし新しいリソースであるがゆえの注意点(5-2)があるため、購入と監視を同列に扱わないことが重要です。

5-2. SP購入のTerraform管理 — aws_savingsplans_savings_plan

aws_savingsplans_savings_planは特定のSP種別(Compute/EC2 Instance/SageMaker/Database)に紐づく専用リソースではなく、AWS公式のDescribeSavingsPlansOfferings/CreateSavingsPlan APIをそのままラップした汎用リソースです。購入したいSPの種別は、リソースに直接指定するのではなく、事前にaws_savingsplans_offeringsデータソースで取得するsavings_plan_offering_idによって決まります。AWS公式API仕様ではplanTypesパラメータの有効値としてCompute | EC2Instance | SageMaker | Databaseが定義されており、Databaseを指定することでDatabase Savings Plansのオファリングを取得できます。

# Database Savings Plansのオファリングを取得(東京リージョン・1年・前払いなし=§2-3の唯一の購入条件)
data "aws_savingsplans_offerings" "database" {
  region = "ap-northeast-1"
  plan_types= ["Database"]
  payment_options = ["No Upfront"]
  durations = [31536000] # 1年 (秒)
}

locals {
  # Vol1のCompute SPと同じ考え方(§4-2の段階購入): 月次目標額の70-80%を初回コミットにする
  monthly_target_usd = 10000
  hours_per_month  = 730
  commitment_ratio = 0.75
  hourly_commitment= (local.monthly_target_usd * local.commitment_ratio) / local.hours_per_month
}

resource "aws_savingsplans_savings_plan" "database" {
  savings_plan_offering_id = data.aws_savingsplans_offerings.database.offerings[0].offering_id
  commitment= format("%.2f", local.hourly_commitment) # USD/hour単位(Vol1と同じ落とし穴に注意)

  tags = {
 Name  = "database-savings-plan-1y"
 Environment = "production"
 ManagedBy= "terraform"
  }
}

このリソースを本番運用へ組み込む前に、以下3点を必ず確認してください。

• 「best effort」警告: hashicorp/aws providerのCHANGELOG(v6.29.0)には「we cannot easily test this functionality, it is best effort and we ask for community help in testing」と明記されています。E2Eテストが手薄な領域であることを前提に、terraform planの差分レビューを他のリソースより厳格に行ってください
• terraform destroyはSPを解約しません: §2-4のIAM表でも触れたとおり、有効化(active)状態のSavings Plansは購入後キャンセルできない金融コミットメントです。terraform destroyやterraform state rmを実行してもstateから消えるだけで、実際のコミットは契約期間(1年)満了まで課金され続けます
• 購入操作は影響範囲を分離する: 通常のインフラ変更と同じstate/CI枠で自動適用すると、レビュー漏れのまま高額コミットを実行してしまうリスクがあります。購入専用のワークスペース(またはfor_eachを使わない単一リソースのみのモジュール)に分離し、terraform apply前に人間の承認ステップを挟む運用を推奨します

購入後はaws_savingsplans_savings_planのデータソース、またはコンソール/CLIで購入済みSPを確認し、terraform importでstateに取り込むことで、以降のtagging等の管理をTerraformに寄せることができます。

5-3. Budgetsでのカバレッジ/利用率アラート — aws_budgets_budget

購入操作と異なり、Budgetsによる監視は以前からaws_budgets_budgetリソースで管理できる、実績のある領域です。budget_type引数はAWS SDKのBudgetType列挙値(USAGE | COST | RI_UTILIZATION | RI_COVERAGE | SAVINGS_PLANS_UTILIZATION | SAVINGS_PLANS_COVERAGE)をそのまま検証に使う実装のため、Terraform公式ドキュメントの例で紹介されているSAVINGS_PLANS_UTILIZATIONだけでなく、SAVINGS_PLANS_COVERAGE(§4-3のカバレッジ指標に対応)も同様に指定可能です。

# 利用率(Utilization)が95%を下回ったら通知 — 余剰コミット(§4-3)の早期検知
resource "aws_budgets_budget" "database_sp_utilization" {
  name= "database-sp-utilization"
  budget_type  = "SAVINGS_PLANS_UTILIZATION"
  limit_amount = "100.0"
  limit_unit= "PERCENTAGE"
  time_unit = "MONTHLY"

  notification {
 comparison_operator  = "LESS_THAN"
 threshold= 95
 threshold_type = "PERCENTAGE"
 notification_type = "ACTUAL"
 subscriber_email_addresses = ["finops@example.com"]
  }
}

# カバレッジ(Coverage)が80%を下回ったら通知 — 追加購入の検討タイミング(§4-2)
resource "aws_budgets_budget" "database_sp_coverage" {
  name= "database-sp-coverage"
  budget_type  = "SAVINGS_PLANS_COVERAGE"
  limit_amount = "100.0"
  limit_unit= "PERCENTAGE"
  time_unit = "MONTHLY"

  notification {
 comparison_operator  = "LESS_THAN"
 threshold= 80
 threshold_type = "PERCENTAGE"
 notification_type = "ACTUAL"
 subscriber_email_addresses = ["finops@example.com"]
  }
}

AWS公式ドキュメント(Creating a Savings Plans budget)によれば、Savings Plansの利用率/カバレッジは既定でアカウント単位の「Overall(SP種別を問わない合算値)」として集計されます。すでにCompute SP(Vol1)を導入済みの組織がこの設定をそのまま使うと、Compute SPとDatabase SPの利用率/カバレッジが合算され、Database SP単体の状態を切り分けられない点に注意してください。フィルターでの絞り込みが可能かどうかはBudget種別によって対応状況が異なるため、Database SP単体でのサービス別カバレッジを正確に追いたい場合は、本節のBudgetsをアカウント全体の安全網として使いつつ、§4-3で解説したCost Explorerのサービス別カバレッジレポートを一次情報源として併用することを推奨します。

5-4. state管理の考え方

Database Savings Plansの購入は1年間取り消せない金融コミットメントであるため、通常のインフラリソースとは異なるstate管理の考え方が必要です。

• 既存の手動購入分はimportで後追い管理する: 本章のTerraform化に先行してコンソール/CLIで購入済みのSPがある場合、aws_savingsplans_savings_planデータソースで存在を確認したうえでterraform importし、tagging等の差分のみをterraform applyで解消する進め方が安全です(いきなり新規購入リソースとして定義すると二重購入の懸念があります)
• purchase_timeによるスケジュール購入を活用する: 即時購入ではなくpurchase_time引数で将来時刻を指定するとqueued状態で作成され、active化する前であれば削除(取り消し)が可能です。段階購入(§4-2)の2回目以降の購入で、レビュー期間を確保する目的に活用できます
• Budgets側はライフサイクルが軽く、通常運用に含めてよい: aws_budgets_budgetは取り消し不能な金融コミットを伴わないため、5-2のような分離運用は不要です。通常のインフラ変更と同じCI/CDパイプラインで管理して問題ありません

6. 詰まりポイント / アンチパターン

6-1. コミット額の見誤り — 時間額と月額の取り違え

commitment引数はUSD/hour単位です。月次のDB利用料目標をそのまま入力すると、実際の月間コミットが730倍近くに膨らみます。§5-2のコード例のように、月次目標額を730(月平均時間数)で割ってからcommitmentに渡す実装を徹底してください。Database Savings Plansは1年・前払いなしの単一オプションであり、Compute SPのように短期解約や条件変更の余地がないため、この種の入力ミスの影響がフルタームにわたって継続する点がCompute SP以上に深刻です。

6-2. Compute SPとの「二重最適化」の混同

§3-3で整理したとおり、Compute SPとDatabase SPは対象サービスが完全に排他的であるため、両者の間に適用競合(優先順位)は発生しません。しかし実務では、この「競合しない」という事実を「無条件に両方フル購入してよい」と誤解するケースが見られます。実際に注意すべき二重コミットは、Database SPと既存のRDS予約インスタンス・DynamoDB予約キャパシティ(Reserved Capacity)との重複です。同一ワークロードに対してDatabase SPと従来の予約商品を両方購入すると、片方の割引が実質的に無駄になります。購入前に既存の予約商品を棚卸しし、Database SPへの移行(予約商品の更新停止 + Database SP購入)か、既存予約商品の継続かを明確に選択してください。

6-3. 対象サービス拡大(2026-03 OpenSearch/Neptune Analytics追加)の見落とし

§1-3で整理したとおり、Database Savings PlansはGA時点の9サービスから2026-03時点で11サービスへ対象が拡大しています。GA直後(2025年12月〜2026年2月)の時点でコミット額を決定した組織では、当時対象外だったOpenSearch Service・Neptune Analyticsの利用料が、その後自動的にカバレッジへ算入されるようになりました。この変化に気づかないまま、カバレッジ・利用率の変動の原因を誤認するケースが想定されます。対象サービスは今後も拡大が見込まれるため、四半期に一度など定期的に、AWS公式のSavings Plans対象サービスページとCost Explorerのカバレッジレポート(サービス別内訳)を突き合わせる棚卸しをrunbook化しておくことを推奨します。

6-4. Terraform化に伴うアンチパターン — 購入リソースの通常運用への混入

§5-2で解説したaws_savingsplans_savings_planは、プロバイダー公式に「best effort」と明記された新しいリソースです。このリソースを他のインフラリソースと同じstate・同じCI/CDパイプラインで管理し、通常のPRマージで自動applyされる運用に混入させると、金融コミットメントであるとレビュー担当者が気づかないまま、高額なcommitment変更をマージしてしまいます。§5-2で述べた「購入操作の分離」を徹底し、通常のインフラ変更とは異なる承認フローを設けてください。

6-5. アンチパターン早見表

7. まとめ + シリーズクロスリンク

7-1. 到達点チェックリスト

§2-7で定義したゴール状態に対する到達状況を振り返ります。

• [x] Database Savings Plansの対象11サービス(2026-03時点)と、それぞれが属する割引率区分を§2で一覧化しました
• [x] 自動適用の対象判定条件と、Compute SPとの関係(適用競合は発生しないこと)を§3で整理しました
• [x] Cost ExplorerのSP推奨とカバレッジ分析に基づく段階購入の考え方を§4で解説しました
• [x] Terraformで管理できる範囲(購入・Budgetsとも管理可能、ただし購入は2026-01-28〜のbest-effortリソース)を§5で切り分けました
• [x] 過剰コミット・二重コミット・対象拡大の見落としといった典型的なアンチパターンを§6で整理しました

7-2. まとめ

本記事では、2025年12月にGAとなったDatabase Savings Plansを対象に、対象サービス・割引率・自動適用の仕組みから、購入戦略、Terraform/Budgetsによる実装まで一気通貫で解説しました。最大の要点は、Database SPが「Compute SPとは対象サービスが完全に排他的な独立したコミット」であるという点です。両者は適用時に競合しないため、それぞれの利用実績の安定性に応じて独立に購入判断できます。一方で、Terraform管理については「購入(2026-01-28〜のbest-effortリソース)」と「監視(枯れたBudgets機能)」で成熟度が大きく異なるため、本章で整理した分離運用を前提に導入することを推奨します。

基礎編:Cost Optimization Vol1(Compute SP編)を読む
コンピュート最適化編:Cost Optimization Vol2(RI×Spot×Graviton)を読む
組織横断コスト管理編:Cost Optimization Vol3(Billing Conductor×Cost Categories)を読む

AWS FinOps運用モデル・組織ガバナンス Vol1を読む
Database本番運用入門 Vol1(RDS×Aurora×DynamoDB)を読む