Amazon RDS と Aurora の料金の仕組みと節約する方法

RDS や Aurora の請求が思ったより高いとき、料金の内訳を分解すると原因が見えてきます。費用の大半はインスタンスの時間、ストレージ、I/O、マルチ AZ といった構成の選び方で決まるので、仕組みが分かれば下げどころも分かります。

料金の数字は、とくに断りがない限り 2026 年 11 月時点の米国東部 (バージニア北部) オンデマンド料金です。単価はリージョンやエンジン、クラスで変わり、改定されることもあるので、見積もりの前に記事末尾の公式ページで自分のリージョンを確認するのが確実です。数字は仕組みを理解するための概算で、実際の請求額を保証するものではありません。

RDS の料金は何で決まるのか

おもにインスタンス、ストレージ、バックアップ、データ転送の 4 つです。使った時間と容量に応じた従量課金で、止めたインスタンスにもストレージなど一部の料金はかかり続けます。

項目	課金の単位	補足
インスタンス	時間あたり (秒単位)	インスタンスクラスと DB エンジンで単価が決まる
ストレージ	GB・月	種類 (gp3、io1 など) で単価が違う
プロビジョンド IOPS	IOPS・月	io1 / io2 などで追加でかかる
バックアップ	GB・月	DB の容量と同じ分までは無料。超えた分が課金される
データ転送	GB	同じリージョン内の転送は低いか無料。インターネットへの外向きは有料

請求の中心はたいていインスタンスです。ストレージを大量に取っていなければ、インスタンスの時間料金が全体の半分以上という DB は珍しくありません。まずインスタンスクラスの単価と台数を押さえるのが手っ取り早いです。

インスタンスの料金

単価はクラス (db.t4g、db.m6g、db.r6g など)、サイズ (medium、large、xlarge など)、DB エンジンの組み合わせで決まります。サイズが 1 段階上がると単価はだいたい 2 倍。Oracle や SQL Server はライセンス込みなので、MySQL や PostgreSQL より高くなります。

たとえば MySQL の db.r6g.large (メモリ 16 GiB) はオンデマンドで 1 時間あたりおよそ $0.26。1 か月を 730 時間とすると 1 台で約 $190 です。常時動かす本番インスタンスは、この額が毎月かかり続けます。

ストレージと I/O の料金

汎用 SSD の gp3 は 1 GB・月あたりおよそ $0.115 です。gp3 には一定の IOPS とスループットが最初から含まれていて、足りないときだけ追加で払います。プロビジョンド IOPS の io1 は容量に加えて IOPS ごとの料金がかかるので、本当に必要な場合だけ選びます。

RDS では通常のストレージ I/O そのものには課金されません。I/O の速さは選んだストレージの種類と IOPS の設定で決まり、それが容量や IOPS の料金に反映される形です。I/O の回数に応じて払うのは Aurora の話で、これは後述します。

マルチ AZ の料金

マルチ AZ は、別のアベイラビリティゾーンに待機用インスタンスを置いて障害時に自動で切り替える構成です。待機分も課金されるので、インスタンスとストレージの料金がどちらもおよそ 2 倍になります。

構成 (db.r6g.large、MySQL、gp3 100 GB)	月額の目安
シングル AZ	インスタンス約 $190 + ストレージ約 $11.5 = 約 $200
マルチ AZ (インスタンス 1 台 + スタンバイ)	インスタンス約 $380 + ストレージ約 $23 = 約 $403

同じ DB でも、マルチ AZ にするかどうかだけで月に約 $200 の差が出ます。RDS には、スタンバイを 2 台持つ「マルチ AZ DB クラスター」という構成もあり、読み取りに使えるスタンバイが付く代わりに費用はさらに増えます。

リードレプリカの料金

リードレプリカは読み取りを分散するための読み取り専用コピーです。1 台ごとにインスタンスとストレージの料金がかかり、元の DB と同じくらいの費用が上乗せされます。リージョンをまたぐレプリカは、リージョン間のデータ転送料金も発生します。

「念のため」で作ったレプリカが、読み取りがほとんどないまま動き続けていることがあります。CloudWatch の ReadIOPS や CPUUtilization で使われていないレプリカがないか見ておくと無駄が減ります。

Aurora の料金は何で決まるのか

インスタンス (または ACU)、ストレージ、I/O の 3 つが中心です。Aurora はストレージがクラスターで共有されていて、使った分だけ自動で増えます。容量を先に決める必要がなく、複数 AZ へのコピー分もストレージ料金に込みです。

標準構成と I/O Optimized

Aurora のストレージ構成には Aurora Standard (標準) と Aurora I/O-Optimized があります。大きな違いは I/O の回数に課金があるかないかです。

項目	Aurora Standard	Aurora I/O-Optimized
ストレージ	1 GB・月あたり約 $0.10	1 GB・月あたり約 $0.225
I/O	100 万リクエストあたり約 $0.20	無料
インスタンス	標準の単価	標準のおよそ 1.3 倍

標準構成は I/O が少ない DB 向きです。I/O-Optimized は、請求の中で I/O の料金が大きな割合を占めるときにお得になります。AWS の目安では、Aurora の費用のうち I/O が 25% を超えるなら I/O-Optimized のほうが安くなるとされています。構成はクラスターごとに 30 日に 1 回まで切り替え可能です。

ACU と Aurora Serverless v2

Aurora Serverless v2 は、負荷に合わせて処理能力が自動で増減するインスタンスです。能力の単位は ACU (Aurora Capacity Unit) で、1 ACU はメモリ約 2 GiB と、それに見合う CPU・ネットワーク。料金は ACU・時間で決まり、標準構成で 1 ACU・時間あたり約 $0.12、I/O-Optimized で約 $0.16 です。

最小と最大の ACU を設定すると、その範囲で 0.5 ACU 刻みで細かく増減し、使った分だけ秒単位で課金されます。最小を 0 ACU にすれば、一定時間アクセスがないときに自動停止し、その間は ACU の料金がかかりません。ただし再開に数秒かかり、ストレージの料金は続きます。

Aurora でも残る費用

バックアップの保存、リージョン間のデータ転送、Performance Insights の長期保存などには別途料金がかかります。レプリカ (Aurora ではリーダー) は 1 台ごとにインスタンスまたは ACU の料金が増えますが、ストレージは共有なのでリーダーを増やしてもストレージ料金は変わりません。

RDS と Aurora の費用を比べる

同じ規模で比べると、小さい DB では RDS が安く、読み取りが多く可用性も重視する DB では Aurora がお得になることが多いです。以下は db.r6g.large・MySQL 互換・データ 100 GB・I/O 月 5 億リクエストという想定での概算です。

構成	内訳	月額の目安
RDS シングル AZ	インスタンス約 $190 + gp3 約 $11.5	約 $200
RDS マルチ AZ	インスタンス約 $380 + gp3 約 $23	約 $403
Aurora Standard (ライター 1 + リーダー 1)	インスタンス約 $380 + ストレージ約 $10 + I/O 約 $100	約 $490
Aurora I/O-Optimized (同じ構成)	インスタンス約 $494 + ストレージ約 $22.5	約 $516

この想定では Aurora の標準構成が I/O-Optimized よりわずかに安くなっています。I/O が月 10 億リクエストなら標準構成の I/O が約 $200 になり、合計は約 $590 で I/O-Optimized の約 $516 を上回ります。I/O が多いほど I/O-Optimized が安くなるので、自分の DB の I/O 量を測って比べるのが大事です。

ただ、Aurora には費用だけでは見えないメリットもあります。リーダーが共有ストレージを読むのでレプリカの遅れが小さいこと、障害時の切り替えが速いこと、ストレージが自動で増えること。マルチ AZ の RDS と同じ可用性を求めるなら、台数の差も含めて比べるのが公平です。

節約する方法

まずは今の費用がどこにかかっているかを把握して、効果の大きいものから手をつけていきます。

0. まず費用の内訳を調べる

Cost Explorer でサービスを「Amazon Relational Database Service」に絞り、使用タイプでグループ化すると、インスタンス・ストレージ・I/O・バックアップのどれが大きいか分かります。CLI でも取れます。

aws ce get-cost-and-usage \
  --time-period Start=2026-10-01,End=2026-11-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Relational Database Service"]}}' \
  --group-by Type=DIMENSION,Key=USAGE_TYPE

Aurora の費用もサービス名は RDS として出ます。使用タイプの名前に Aurora や IO が入っているものが Aurora や I/O の費用です。

1. リザーブドインスタンスで単価を下げる

リザーブドインスタンス (RI) は、1 年または 3 年の利用を約束する代わりにオンデマンドより安くなる割引です。前払いなし・一部前払い・全額前払いから選べて、前払いが多いほど割引率が上がります。おおむね 1 年で 3 割前後、3 年でさらに大きくなります。

RDS の RI はエンジンによっては同じインスタンスファミリー内でサイズが違っても割引が効きます (サイズ柔軟性)。常時動いていてサイズを変える予定がない本番 DB から検討するのが向いています。購入できる RI は CLI で調べられます。

aws rds describe-reserved-db-instances-offerings \
  --db-instance-class db.r6g.large \
  --product-description mysql \
  --duration 31536000 \
  --offering-type "No Upfront" \
  --no-multi-az

2. Savings Plans で使い方の変化に備える

RDS や Aurora も対象の Database Savings Plans もあります。1 時間あたりの利用額を 1 年間約束すると、その額まで割引されます。インスタンスクラスやリージョン、エンジンを変えても割引が続くのが RI との違いです。対象サービスと割引率は公式ページに載っています。

RI と Savings Plans のどちらにするかは、構成を変える頻度次第です。しばらく同じ構成で使うなら RI、移行やスケール変更がありそうなら Savings Plans。どちらも買いすぎて使い切れないと損になるので、最低限必要な分から始めるのが安全です。

3. 不要なマルチ AZ を見直す

マルチ AZ は本番 DB には有効ですが、開発・検証の DB には過剰なことが多いです。シングル AZ にするだけでインスタンスとストレージの費用がおよそ半分になります。

aws rds modify-db-instance \
  --db-instance-identifier example-staging-db \
  --no-multi-az \
  --apply-immediately

本番でも、停止が許される時間や復旧時間の目標によっては、シングル AZ + バックアップ + 自動スナップショットで足りる場合があります。ただし可用性は業務の要件なので、費用だけで決めず関係者と合意してから変更します。

4. ストレージの種類と容量を見直す

gp2 をまだ使っているなら gp3 に切り替えると安くなります。同じ容量でも単価が低く、IOPS とスループットを容量と別に調整できます。DB は止まりませんが、切り替え中に性能が落ちることがあるので、負荷の低い時間帯がおすすめです。

aws rds modify-db-instance \
  --db-instance-identifier example-app-db \
  --storage-type gp3 \
  --apply-immediately

io1 や io2 のプロビジョンド IOPS を使っている場合は、CloudWatch の ReadIOPS と WriteIOPS で実際の IOPS を測り、設定が過剰なら gp3 に切り替えます。なお RDS のストレージは増やせても減らせないので、余裕を見て大きくしすぎると使わない容量の料金を払い続けることになります。

5. Aurora Serverless v2 でスケールダウンする

使う時間帯が偏っている DB や開発・検証の DB には Aurora Serverless v2 が向いています。夜間や休日に負荷が下がると ACU が最小まで自動で下がり、その分の費用が減ります。

aws rds modify-db-cluster \
  --db-cluster-identifier example-aurora-cluster \
  --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=8 \
  --apply-immediately

最小 ACU を大きくしすぎると、負荷が低い時間でも常にその分が課金されます。逆に小さくしすぎると、急な負荷で ACU が増えるまで時間がかかります。ServerlessDatabaseCapacity と ACUUtilization のメトリクスを見て、実際の使用範囲に合わせて調整するのがコツです。常に高負荷が続く DB なら、固定インスタンス + RI のほうが安くなることもあります。

6. 小さいインスタンスと使われていない DB を見直す

CPU 使用率がほとんど 10% を超えない DB は、1 段階小さいクラスにできる可能性があります。小さくすると単価が半分になるので、効果の大きい見直しです。CPU の推移は CloudWatch で調べられます。

aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name CPUUtilization \
  --dimensions Name=DBInstanceIdentifier,Value=example-app-db \
  --start-time 2026-10-01T00:00:00Z \
  --end-time 2026-11-01T00:00:00Z \
  --period 86400 \
  --statistics Average Maximum

最大値が低いままならクラスを下げる候補です。使われていない DB はスナップショットを取ってから削除します。停止しただけの RDS インスタンスは 7 日たつと自動で再開されるので注意が必要です。開発用の DB は夜間に自動停止する仕組みを作ると、その時間のインスタンス料金を省けます。

aws rds stop-db-instance --db-instance-identifier example-dev-db

7. Performance Insights の無料枠を使う

Performance Insights は DB の負荷をクエリごとに調べられる機能です。7 日間分のデータ保存は無料で、それより長く保存すると vCPU あたりの料金がかかります。普段の調査は 7 日で足りることが多いので、長期保存は必要なインスタンスだけに絞ります。

今の保存期間を確認するコマンドです。

aws rds describe-db-instances \
  --query 'DBInstances[].[DBInstanceIdentifier,PerformanceInsightsEnabled,PerformanceInsightsRetentionPeriod]' \
  --output table

PerformanceInsightsRetentionPeriod が 7 より大きければ長期保存の料金がかかっています。なお AWS は Performance Insights を Database Insights に統合する方針を出しており、モードによって料金が変わるので、移行前に公式ページで確認しておくと安心です。

8. 古いバージョンとスナップショットの費用に気をつける

サポートが終わった古いエンジンバージョンを使い続けると、延長サポート (Extended Support) の料金が vCPU あたりの時間料金で上乗せされます。バージョンを上げれば止まる費用なので、請求にこの項目が出ていないか確認しておきます。手動スナップショットも削除するまで保存料金がかかり続けます。古い手動スナップショットの一覧はこのコマンドで出せます。

aws rds describe-db-snapshots \
  --snapshot-type manual \
  --query 'DBSnapshots[].[DBSnapshotIdentifier,SnapshotCreateTime,AllocatedStorage]' \
  --output table

節約の優先順位

効果が大きくてリスクの小さいものから手をつけるのが基本です。

使われていない DB、レプリカ、古いスナップショットを消す (リスクが小さい)
開発・検証の DB をシングル AZ にして夜間に停止する
gp2 から gp3 へ切り替える
常時動かす本番の DB に RI または Savings Plans を買う
負荷が大きく変動する DB を Aurora Serverless v2 にする
Aurora の I/O の量を測って、標準と I/O-Optimized を選ぶ

節約は一度やって終わりではなく、アプリの変更や利用の増減で費用の形は変わっていきます。月に 1 回は Cost Explorer で先月と比べる習慣をつけておくと安心です。

費用の変化に気づくには

費用を下げた後も、新しいバッチが毎時全件を読むようになった、リードレプリカが増えた、I/O が急に増えた、といった変化は月末の請求で初めて気づくことがあります。AWS Budgets で月の予算を決め、予測が超えそうなときに通知を送る設定にしておくと早めに気づけます。DB の負荷やメトリクスの見方は RDS・Aurora の監視の記事で説明しています。

RDS・Aurora に入っている業務データの変化を見張りたい場合は、AI に任せる方法もあります。Scandock は RDS や Aurora に対応したデータベースの監視サービスで、AI がテーブルの構成と実データを読んで、売上や注文数など何を監視するかと、取得と判定の間隔を決めます。値の推移を踏まえて異常かどうかを判断し、異常のときは読み取り専用のクエリで関連するデータを調べて、根拠と対処案をつけて通知します。DB に詳しくない人でも、チャットで「先週から注文が減っていないか」と聞くと、AI が調べてグラフつきで答えます。