AWS RDS コスト最適化入門｜リザーブドインスタンス・Auroraサーバーレス・マルチAZ見直しでDB料金を最大60%削減する実践ガイド

「RDSの請求書を見るたびに、思っていた金額よりずっと高くて頭を抱えている」

そんな経験はないでしょうか。オンプレミス時代のDBサーバーは導入コストが大きい代わりに、一度構築してしまえばランニングコストはほぼ固定でした。ところがAmazon RDS（Relational Database Service）に移行すると、インスタンスの起動時間・ストレージ容量・マルチAZ料金・バックアップ保持期間——あらゆる軸で課金が発生します。

気づかないうちに「全環境をマルチAZにしていた」「バックアップを35日保持していた」「gp2のままだった」という状態が続き、月末請求が想定の1.5倍に膨れ上がることも珍しくありません。

この記事では、RDSのコスト構造をオンプレ経験者向けに整理したうえで、①リザーブドインスタンス、②Aurora Serverless v2、③マルチAZ設計の見直し、④ストレージ最適化という4つのアプローチを中心に、DBコストを最大60%削減するための実践的な手順を解説します。

RDSコストの内訳を把握する（まず「何に課金されているか」を知る）

コスト最適化の第一歩は、現状の把握です。RDSの主な課金ポイントは以下の通りです。

・インスタンス料金: 起動時間に対して発生。オンデマンドとリザーブドインスタンスで単価が大きく異なる
・ストレージ料金: プロビジョニングした容量に対して発生（gp2は旧世代で割高）
・マルチAZ料金: スタンバイインスタンスが追加で起動する分がかかる（シングルAZ比でほぼ2倍）
・バックアップストレージ料金: 自動バックアップの保持期間 × データ量で課金（DB容量の範囲内は無料）
・データ転送料金: RDSからEC2への転送は同一AZ内なら無料、AZ間は有料
・I/Oリクエスト料金: Aurora（プロビジョンド）の場合は読み書きリクエスト数でも課金

オンプレ経験者が特に見落としがちなのは「マルチAZ」と「バックアップ保持期間」です。本番構築直後からこれらが有効になっており、開発・ステージング環境でも同じ設定のまま数カ月が過ぎることがよくあります。

現状把握にはAWS Cost Explorerが便利です。サービスをAmazon RDSに絞り込み、さらに「UsageType」ディメンションでインスタンス料金・ストレージ料金・マルチAZ料金を分解すると、どこに費用が偏っているかが一目でわかります。

リザーブドインスタンス（RI）でインスタンス料金を最大60%削減する

RDSのコスト削減で最も効果が大きいのは、リザーブドインスタンス（RI）の購入です。「使用量を予約する代わりに単価を大幅に下げる」という仕組みで、EC2のRIと同様のモデルです。

1. RIの種類と割引率

RDSのRIには主に以下の構成があります（東京リージョン・MySQL・db.m5.largeの場合、2026年3月時点）。

割引率はインスタンスファミリー・リージョン・DBエンジンによって変わります。実際の購入前にAWSマネジメントコンソールで最新の料金を確認してください。

2. RI購入前に確認すること

RI購入は1〜3年の契約になるため、以下の点を事前に整理します。

・稼働率が高いか: 常時起動している本番DBはRIが有効。逆に止める機会が多い開発環境にはオンデマンドが向いている
・インスタンスタイプの変更予定がないか: RI購入後のファミリー変更は原則できない（同一ファミリー内のサイズ変更は可能）
・DBエンジンの変更予定がないか: MySQLからAuroraへの移行を検討している場合はタイミングに注意
・マルチAZとシングルAZを分けてRIを購入する: マルチAZ用RI・シングルAZ用RIは別々に購入する必要がある

AWS Cost ExplorerにはRI推奨機能が用意されており、過去30〜60日の実際の使用状況をもとに最適なRI構成を自動提案してくれます。まずここを確認するのが最短経路です。

# AWS CLIでRDS リザーブドインスタンスの購入推奨を確認する
aws ce get-reservation-purchase-recommendation \
  --service "Amazon RDS" \
  --region ap-northeast-1 \
  --term-in-years ONE_YEAR \
  --payment-option ALL_UPFRONT

3. RIを買い損ねた場合はRIマーケットプレイスも活用できる

RIは購入後に不要になった場合、「リザーブドインスタンスマーケットプレイス」で他のAWSユーザーに売却できます（EC2は可能、RDSは現時点では一部制限あり）。購入に踏み切れない場合は、まず1年・一部前払いの小さなインスタンスで試してみるのが現実的なアプローチです。

Aurora Serverless v2でスパイク対応とコスト最適化を両立する

Aurora Serverless v2は、負荷に応じてDBの処理能力（ACU: Aurora Capacity Unit）を秒単位で自動スケールする仕組みです。オンプレでいえば「常に最大スペックで動かしている専有サーバー」を、「負荷に比例して動的にリソースを割り当てる仮想基盤」に置き換えるイメージです。

1. どんなワークロードに向いているか

2. 料金の考え方と設定ポイント

Aurora Serverless v2は「ACU時間（ACU-hour）」単位で課金されます。東京リージョン（ap-northeast-1）では1 ACU-hourあたり約$0.12（2026年3月時点）。最小ACUと最大ACUを設定し、その範囲内で自動スケールします。

たとえば最小0.5 ACUで深夜8時間稼働した場合、0.5 × 8 × $0.12 = $0.48。オンデマンドのdb.t3.mediumが同8時間で約$0.68かかるのと比べると、低負荷帯での節約効果が見えてきます。

注意点として、最低ACUを0.5に設定するとアイドル後の初回クエリで数秒の遅延が発生することがあります。レイテンシが重要な本番環境では最低ACUを1〜2に設定するのが現実的な落としどころです。

# AWS CLIでAurora Serverless v2のスケーリング設定を変更する
aws rds modify-db-cluster \
  --db-cluster-identifier my-aurora-cluster \
  --serverless-v2-scaling-configuration MinCapacity=1,MaxCapacity=16 \
  --apply-immediately

マルチAZ設計を見直してコストを適正化する

1. マルチAZが本当に必要な環境を整理する

マルチAZはプライマリDBに障害が発生した際にスタンバイへ自動フェイルオーバーする仕組みで、オンプレのアクティブ/スタンバイ構成に相当します。可用性は向上しますが、コストはシングルAZのほぼ2倍になります。

現場でよくあるのが、「本番のコピーだから」という理由でステージング・開発環境もマルチAZにしている状態です。環境ごとの必要性を整理します。

・本番環境: サービス継続性が求められるため、基本的にマルチAZが必須
・ステージング環境: DR訓練目的でなければシングルAZで十分な場合が多い
・開発・QA環境: ほぼ全ケースでシングルAZで問題ない

2. マルチAZ設定を変更する手順

RDSのマルチAZ設定変更は、コンソールまたはCLIから実施できます。変更適用のタイミングは「即時」と「次回メンテナンスウィンドウ」から選べますが、本番環境では業務影響の少ない時間帯に計画的に実施してください。

# AWS CLIでマルチAZを無効化する（ステージング・開発環境向け）
aws rds modify-db-instance \
  --db-instance-identifier my-staging-db \
  --no-multi-az \
  --apply-immediately

変更によって短時間の再起動が発生する場合があります。接続プールの再試行設定などをアプリ側で確認してから実施するのが安全です。

ストレージコストを見直す（gp2からgp3への移行）

RDSのデフォルトストレージタイプは旧世代のgp2（汎用SSD）です。gp2はストレージ容量が増えるとIOPSも連動して増加する仕組みで、「IOPSが足りないから容量を増やす」という本末転倒な拡張を強いられるケースが現場でよく起きていました。

gp3に移行すると以下の改善が得られます。

・コスト: gp2比で最大20%安価（東京リージョン: gp2約$0.138/GB-月 → gp3約$0.115/GB-月、2026年3月時点）
・IOPS: 容量とは独立して設定可能（デフォルト3,000 IOPS、最大16,000 IOPS）
・スループット: デフォルト125 MB/s、最大1,000 MB/sまで別途設定可能

デフォルトのIOPS（3,000）とスループット（125 MB/s）は追加費用なしで利用でき、ほとんどのワークロードでは追加コストなしに移行できます。

# AWS CLIでRDSストレージをgp2からgp3へ移行する（無停止で実施可能）
aws rds modify-db-instance \
  --db-instance-identifier my-production-db \
  --storage-type gp3 \
  --iops 3000 \
  --storage-throughput 125 \
  --apply-immediately

# 変更状態を確認する
aws rds describe-db-instances \
  --db-instance-identifier my-production-db \
  --query "DBInstances[0].StorageType"

gp3移行はストレージの変更であるため、完了までに数分〜数十分かかります。変更中もDBは引き続き利用可能ですが、完了前は再度の変更が受け付けられないため注意してください。

移行前にCloudWatchで`ReadIOPS`と`WriteIOPS`メトリクスを確認し、現在のI/O使用量がgp3のデフォルト値（3,000 IOPS）で賄えるかを確認しておくと安心です。

バックアップ保持期間と自動バックアップの見直し

自動バックアップの保持期間は1〜35日で設定できます。デフォルトは7日ですが、開発環境でも35日に設定されたままになっているケースは珍しくありません。

自動バックアップが占有するストレージはプロビジョニングしたDB容量の100%分までは無料です。それを超えた分だけGB単位で課金されます。

実際のコスト影響を確認する手順は次の通りです。

・AWSコンソール → Cost Explorer → サービス: Amazon RDS → UsageType: RDS:StorageUsage を確認
・保持期間が不必要に長い環境を特定したら、RDSコンソールの「変更」→「バックアップ保持期間」から短縮する

・本番環境: 7〜14日が実務上の目安（RPO要件に合わせて設定）
・ステージング・開発: 1〜3日で十分なケースが多い

なお、保持期間を0日にすると自動バックアップが完全に無効化されます。これはDB削除時にスナップショットが作成されなくなることを意味するため、本番環境では行わないでください。

よくあるトラブルと注意点

【注意】RI購入後にインスタンスを削除しても料金が発生し続ける

RIは「インスタンスを使用するかどうかに関わらず」課金されます。削除したインスタンスのRIが残っている場合、対応するインスタンスを新たに起動するか、RIマーケットプレイスでの売却を検討します。誤って購入した場合はAWSサポートへ早期に相談すると対応策の選択肢が広がります。

【注意】gp2→gp3移行後にIOPSが不足する

gp2時代はIOPSを確保するためにストレージサイズを大きくしていたケースがあります。その場合、gp3のデフォルトIOPS（3,000）では不足する可能性があります。CloudWatchで`ReadIOPS`/`WriteIOPS`の最大値を事前確認してから移行してください。

【注意】Aurora Serverless v2のコールドスタート遅延

最低ACUを0.5に設定してアイドル状態が続くと、次のクエリ発行時に数秒の応答遅延が発生することがあります。レスポンスタイムが重要なAPIバックエンドのDBには最低ACUを1〜2に設定するのが現実的です。

本記事のまとめ

4つの施策の効果と難易度を整理します。

RDSのコスト最適化は「まず現状を把握する」ことが出発点です。AWS Cost ExplorerでサービスをAmazon RDSに絞り込み、インスタンス別・環境別に料金を分解してから、効果の大きい施策から順番に着手していくのが現場的なアプローチです。

姉妹サイトLinuxMaster.JPでは、クラウドDB接続に必要なLinuxサーバーの基礎スキルも詳しく解説しています。RDS移行と並行してLinuxの基盤知識を固めたい方はあわせてご参照ください。