6年越しのFinOps革命！AWS Database Savings Plansで最大35%のコスト削減を実現する方法

なぜ今、Database Savings Plansがアツいのか

re:Invent 2025で発表されたAWS Database Savings Plans、チェックされましたか？正直、個人的にはかなりアツいアップデートだと思っています。

というのも、僕がサーバーレス開発を始めた2017年頃から、ずっと「データベースのSavings Plansってなんでないんだろう」と感じていたんですよね。EC2やLambdaにはCompute Savings Plansがあるのに、RDSやDynamoDBには個別のReserved InstancesやReserved Capacityしかなくて。

複数のデータベースサービスを使い分けるモダンなアーキテクチャだと、それぞれに対して別々のコミットメントを管理するのって、なかなか骨が折れるわけです。実際、僕がクライアント支援をしている中でも「RIの管理が複雑すぎて結局オンデマンドのまま放置している」というケースを何度も見てきました。

そんな課題を解決してくれるのが、今回のDatabase Savings Plans。さっそく中身を見ていきましょう。

Database Savings Plansで何ができるのか

対象となる9つのサービス

Database Savings Plansがカバーするのは、Aurora、RDS、DynamoDB、ElastiCache（Valkeyのみ）、DocumentDB、Neptune、Keyspaces、Timestream（InfluxDBのみ）、そしてDMSの9サービスです。

僕が特に注目しているのは、DocumentDB、Neptune、Keyspaces、Timestream、DMSについてはDatabase Savings Plansが初めてのコミットメント購入オプションになるという点。これまで割引の手段がなかったサービスにも、ようやくコスト最適化の道が開かれたわけですね。正直、Neptune使っているお客さんから「割引オプションないの？」と聞かれて困ったことが何度かあったので、これは嬉しい。

割引率はどれくらいか

割引率はデプロイメントモデルによって異なります。サーバーレス（Aurora Serverless v2、DocumentDB Serverless等）が最大35%、プロビジョンドインスタンスが20%、DynamoDBオンデマンドスループットが18%、DynamoDBプロビジョンドキャパシティが12%という構成です。

ここで「おっ」と思った方もいるかもしれません。そう、サーバーレスデプロイメントが最も高い割引率なんです。これは僕にとってかなりの朗報でした。Ragateではサーバーレスファーストでシステム設計をすることが多いんですが、これまでサーバーレスDBには割引オプション自体がなかったので、この35%は完全に「増分的な節約」になります。

Reserved Instancesとどう使い分けるか

「じゃあReserved Instances（RI）はもう要らないの？」という疑問が浮かびますよね。結論から言うと、両方を上手く使い分けるのがベストです。

正直に言うと、純粋な割引率ではRIのほうが上です。Aurora/RDSのRIは1年で最大45%、3年で最大66〜69%。DynamoDB Reserved Capacityは1年で最大54%、3年で最大77%。対してDatabase Savings Plansは最大35%（サーバーレス）なので、「とにかく安くしたい」ならRIを選ぶべきです。

でも、Database Savings Plansの真価は柔軟性にあります。エンジン間の変更（Oracle→PostgreSQL、RDS→DynamoDB）、インスタンスサイズの変更、リージョン間移動、プロビジョンドとサーバーレスの切り替え…こういった変更があっても割引が継続するんです。

Reserved Instances vs Database Savings Plansの比較

僕がクライアントワークでよく見るパターンとして、「最初はRDS MySQLで作ったけど、途中からAurora PostgreSQLにモダナイゼーションしたい」みたいなケースがあります。RIだとこういう変更で割引が無駄になりがちですが、Savings Plansなら継続して使えるんです。この柔軟性は、特にシステムの変化が激しいスタートアップや、モダナイゼーション真っ最中の企業にとって大きな価値があると思います。

実践的な使い分け戦略

経験則も含めて、僕なりの使い分けの考え方をお伝えします。

本番環境で構成が完全に固まっていて、3年間は変更予定がないワークロードであれば、迷わずReserved Instancesを選ぶべきです。最大割引を取りに行くのが合理的ですし、安定したワークロードなら予測もしやすい。

一方で、開発・テスト環境や、インスタンスタイプやエンジンを頻繁に変えたいケース、モダナイゼーションを計画しているケース、複数のDBサービスを使い分けているケースでは、Database Savings Plansのほうが向いています。僕の感覚だと、SMB市場のお客さんはこっちのパターンが多い印象です。

そして、サーバーレスワークロードについては、正直Database Savings Plans一択だと思っています。これまで割引手段がなかったところに最大35%の割引が来たわけで、使わない理由がない。特にAurora Serverless v2を本番で使っているお客さんには、すぐにでも検討をおすすめしたいですね。

導入時に注意したい3つのポイント

実際に導入を検討する際、僕が気をつけてほしいと思っているポイントが3つあります。

まず、現時点では1年間のコミットメントのみという点。Compute Savings Plansのように3年オプションはまだありません。逆に言えば、まずは1年で試してみて、効果を確認してから継続するかどうか判断できるので、導入のハードルは低いとも言えます。

次に、Database Savings Plansはdb.r7g、db.r8gなど第7世代以降のインスタンスが対象です。旧世代のインスタンスを使っているなら、まずアップグレードを検討しましょう。どのみち旧世代は性能面でもコスト効率面でも不利なので、これを機にアップグレードするのは良い判断だと思います。

最後に、Savings Plansは$/時間でコミットするという点を忘れずに。AWSの推奨ツール（Recommendations、Purchase Analyzer）を活用して、過去の時間単位の使用量パターンを分析したうえでコミットメント額を決めるのがコツです。いきなり100%カバーを目指すのではなく、まずは70-80%程度のカバー率から始めて、様子を見ながら調整していくのが現実的なアプローチだと考えています。