先に要点
- AWS で関係 DB は RDS / Aurora / Aurora Serverless v2 の 3 つから選ぶ。「基本は同じ MySQL / PostgreSQL を動かせる」 が、料金体系・スケール特性・運用負荷がまるで違う。
- RDS: AWS 標準のマネージド DB。固定インスタンス + EBS ストレージでシンプル。MySQL / PostgreSQL / MariaDB / Oracle / SQL Server に対応。料金が予測しやすく、小〜中規模で安定運用に向く。
- Aurora: AWS が独自開発した クラウドネイティブな関係 DB。「MySQL / PostgreSQL 互換」 で、ストレージが自動拡張 + 6 重レプリケーション + 読み取りレプリカ最大 15 台。性能は RDS の数倍、「高可用性が標準」 だが 料金は 20〜30% 高い。
- Aurora Serverless v2: ACU (Aurora Capacity Unit) 単位でリアルタイムにスケールするサーバレス Aurora。「使った分だけ課金」 で 負荷の変動が大きいワークロードに最適。「v1 と違って ms 単位の自動スケール」 が現代的。
- 判断軸: 「予測可能な負荷 + コスト最優先 → RDS」「常時高負荷 + 高可用性必要 → Aurora」「負荷変動大 + 開発 / 検証環境 → Aurora Serverless v2」。「新規プロジェクトの本番は Aurora、検証 / dev は Aurora Serverless v2」 が現代の標準パターン。
「AWS で DB を立てよう」と思ったとき、「RDS と Aurora、どっち選べばいいの?」 という質問は AWS DB 全体比較 でもよく出る論点です。さらに 2022 年に Aurora Serverless v2 が GA(正式リリース)してから、選択肢が 3 つに増えました。
ざっくり言うと、RDS は古典的なマネージド DB、Aurora は AWS 独自の高性能版、Aurora Serverless v2 は自動スケール版です。それぞれ料金体系とスケール特性が違うので、「ワークロードに合わせて選び分ける」 のが本質。
この記事では、3 者の 仕組み・料金構造・スケール・典型用途 を実務目線で整理します。AWS DB 全体の俯瞰は AWS のデータベース比較、コンピュート選択との関係は コンテナ vs サーバレス vs VM も併読してください。
まず 3 者を一覧で
主要な違いを表で並べます。
| 項目 | RDS | Aurora | Aurora Serverless v2 |
|---|---|---|---|
| サービスの本質 | マネージド標準 DB | AWS 独自の高性能 DB | 自動スケール版 Aurora |
| 対応エンジン | MySQL / PostgreSQL / MariaDB / Oracle / SQL Server | MySQL 互換 / PostgreSQL 互換 | MySQL 互換 / PostgreSQL 互換 |
| ストレージ | EBS(事前確保、最大 64TB) | 共有ストレージ(自動拡張、最大 128TB) | 共有ストレージ(自動拡張) |
| レプリケーション | Multi-AZ で 1 台スタンバイ | 6 重レプリケーション(3 AZ × 2 コピー) | Aurora と同じ 6 重 |
| 読み取りレプリカ | 最大 5 台(エンジン依存) | 最大 15 台 | 最大 15 台 |
| 料金体系 | インスタンス時間 + ストレージ GB | インスタンス時間 + ストレージ GB + I/O リクエスト課金(または I/O Optimized) | ACU 秒 + ストレージ + I/O |
| スケール方式 | 手動 or Auto Scaling(リードレプリカ) | 手動 or Auto Scaling | 負荷に応じて自動 ms 単位 |
| 典型用途 | 予測可能な負荷の本番 / 開発 | 常時高負荷の本番 / 高可用性要件 | 負荷変動大 / 検証 / 一時的負荷 |
「同じ MySQL / PostgreSQL を動かせるが、提供されるインフラの特性が違う」 のが核心です。
RDS の仕組みと位置づけ
Amazon RDS (Relational Database Service) は AWS で最も古くからあるマネージド DB サービスで、「EC2 上に DB を自前運用する手間を省く」 ために設計されています。
仕組み
「 指定したインスタンスタイプの EC2 上で MySQL / PostgreSQL / Oracle / SQL Server などが動く』 構成。OS / DB エンジン / パッチ管理 / バックアップ」 を AWS が代行。利用者は SQL を投げるだけ。
対応エンジンの幅
5 つのエンジン(MySQL / PostgreSQL / MariaDB / Oracle / SQL Server)に対応。「既存 DB をそのまま移行したい」 場合に互換性が高い。Oracle / SQL Server は Aurora にない選択肢。
Multi-AZ 構成
「プライマリ + スタンバイ」 の 2 台で動かす冗長構成。プライマリ障害時に自動フェイルオーバー(60〜120 秒)。「スタンバイは読み取りに使えない」 のが Aurora との大きな違い。
料金が分かりやすい
「 インスタンス時間 + ストレージ GB」 のシンプルな料金体系。予測可能で経理処理が楽。Reserved Instance / Savings Plans で大幅割引(最大 70% 削減)できる。
Aurora の仕組みと強み
Amazon Aurora は 2014 年に AWS が独自開発した クラウドネイティブ関係 DB。「MySQL / PostgreSQL 互換のラッパー」 ではなく、ストレージ層を AWS が完全に作り直した新世代の DB。
分散共有ストレージ
「 3 つの AZ にそれぞれ 2 コピー(計 6 重)で自動分散保存」。2 つの AZ 障害でもデータ無事。「ストレージは 10GB から始まり、データ量に応じて自動拡張(最大 128TB)」。
高速フェイルオーバー
「30 秒未満でフェイルオーバー完了」(RDS Multi-AZ より高速)。「リードレプリカが即座にプライマリ昇格」 する設計。
読み取りレプリカ最大 15 台
RDS の 5 台に対し Aurora は 15 台まで。「大量読み取りに強い」 ため、「分析クエリ + Web 読み取り」 を同じ DB で捌ける。
パフォーマンス
Amazon 公式では MySQL の 5 倍、PostgreSQL の 3 倍のスループット(同等インスタンス比)。実際のワークロードでも 2〜3 倍は出ることが多い。「高負荷で並列処理が多い」 ほど効果が出る。
Aurora Serverless v2 の仕組み
Aurora Serverless v2 は 2022 年に GA した 自動スケール版 Aurora。「サーバレス感覚で関係 DB を使える」 のが核心。
ACU 単位の課金
「 Aurora Capacity Unit (ACU)」 という単位で計算リソースを表現。「1 ACU = 約 2GiB メモリ + CPU / ネットワーク」。ms 単位で ACU が自動増減するため、「負荷に応じて瞬時にスケール」 する。
スケール特性
「最小 ACU」 と 「最大 ACU」 を設定するだけ。「負荷が増えれば最大まで自動拡張、減れば自動縮小」。v1 の 30〜60 秒のラグが、v2 では ms 単位に短縮。
スケール 0 はできない
v1 と違って 「完全停止(0 ACU)」 は不可。最小 ACU(0.5 以上)を常に動かす必要があり、「完全に未使用時は無料」 ではない。「真のサーバレス感」 を求めると v1 のほうが優れる場面もある。
料金構造
「 ACU 秒 + ストレージ + I/O」。同じワークロードで Aurora の通常インスタンスより 30〜50% 高くなる傾向。「常時高負荷」 ならプロビジョンド Aurora のほうが安く、「負荷変動が大きい」 とサーバレスのほうが安くなる損益分岐点がある。
料金の構造比較
実際の料金感を比較します(2026 年 5 月時点の東京リージョン)。
| 項目 | RDS (db.m5.large MySQL) | Aurora (db.r6g.large MySQL 互換) | Aurora Serverless v2 (1 ACU) |
|---|---|---|---|
| 時間単価 | 約 $0.20/h | 約 $0.29/h | 約 $0.12/h(1 ACU) |
| 月額(常時起動) | 約 $144 | 約 $209 | 1 ACU 固定なら約 $86、最大 32 ACU だと最大 $2,756 |
| ストレージ | $0.115/GB(汎用 SSD) | $0.10/GB(自動拡張) | $0.10/GB(自動拡張) |
| I/O | 追加なし | 100 万 I/O あたり $0.20(I/O Optimized なら追加なし) | 100 万 I/O あたり $0.20 |
| Reserved 割引 | 最大 70% 削減 | 最大 60% 削減 | 不可(サーバレスのため) |
「Aurora は RDS より 20〜30% 高い」 が 「性能が数倍出る」 ので、性能 / 円では Aurora が有利なケースが多い。Aurora Serverless v2 は 負荷変動が大きいほど安く、常時高負荷だと逆に高くなる。
判断フロー — どれを選ぶか
「どれを選ぶか」 を 6 ステップで決めるフロー。
「新規本番は Aurora、検証 / dev は Aurora Serverless v2、既存 Oracle / SQL Server は RDS」 が現代の標準パターンです。
典型ユースケース別の推奨
具体的な用途別の推奨を整理します。
| ユースケース | 推奨 | 理由 |
|---|---|---|
| 新規 Web サービス本番 | Aurora MySQL / PostgreSQL 互換 | 高可用性 + 高性能 + スケールが標準で揃う |
| スタートアップ初期 MVP | Aurora Serverless v2 (最小 ACU 0.5) | 初期は安く、伸びれば自動スケール |
| 開発 / ステージング環境 | Aurora Serverless v2 | 使わない時間が長く、自動縮小で節約 |
| 既存 Oracle / SQL Server 移行 | RDS | Aurora は MySQL / PostgreSQL 互換のみ |
| BI / 集計ワークロード | Aurora(リードレプリカで分離) | 15 台までレプリカで読み取り負荷分離 |
| 常時超高負荷の SaaS | Aurora プロビジョンド(Reserved) | 大幅 Reserved 割引、Aurora Serverless より安くなる |
| イベント駆動アプリ(突発負荷) | Aurora Serverless v2 | 突発負荷にも自動スケールで対応 |
| 個人開発 / 小規模ブログ | RDS (db.t3.micro) or Aurora Serverless v2 (最小 ACU) | RDS db.t3.micro は月 $13、Aurora Serverless v2 は最小 $86 から |
| レガシー基幹システム移行 | RDS(段階移行) | 互換性を最優先し、段階的に Aurora 移行を検討 |
Aurora Serverless v2 が向く / 向かない場面
「Aurora Serverless v2 は良さそう」 と思いがちですが、向き不向きがあります。
ハマりやすいポイント
実装で踏みやすい落とし穴を整理します。
Aurora Serverless v2 のコスト誤算
「最小 ACU で常時動く料金」 を見落とし、「使わない時間も最小 ACU 分の課金」 になっていた、という事故が頻発。最小 ACU を 0.5 にしても月 $86 からかかる。「完全に未使用時は無料」 ではないので注意。
I/O Optimized vs Standard
Aurora には 「I/O Optimized」 オプションがあり、「月のストレージ + コンピュート の 25% アップで I/O 課金がゼロ」 になる。I/O が多いワークロードでは I/O Optimized のほうが大幅に安い(50% 以上削減することも)。「I/O リクエストが多いか?」 を必ず試算する。
Aurora のバージョン管理
「Aurora MySQL 5.7 互換』 『 Aurora MySQL 8.0 互換」 のようにエンジンバージョンが選べる。古いバージョンは EOL があり、強制アップグレードのタイミングがある。「本番運用を始めたら定期的にバージョン確認」 する習慣を持つ。
RDS vs Aurora vs Aurora Serverless v2 に関するよくある質問
Q. 新規プロジェクトはどれを選ぶべき?
A. Aurora が現代の標準。「高可用性 + 高性能 + スケール」 が一通り揃っており、「MySQL / PostgreSQL 互換』 で既存ツールがそのまま使える。開発 / ステージング環境は Aurora Serverless v2」 でコスト削減、「本番は Aurora プロビジョンド」 が定番の組み合わせ。
Q. Aurora Serverless v1 と v2 の違いは?
A. v1 は古いアーキテクチャで、AWS が v2 への移行を推奨している。v1 は 「スケールに 30〜60 秒のラグ』 『 完全停止(0 ACU)可能だが復帰に時間」、v2 は 「ms 単位のスケール』 『 完全停止は不可だが ACU 単位で細かく増減」。新規は v2 一択。
Q. Aurora の料金が高くて困っています
A. I/O Optimized オプションを試す価値あり。「I/O リクエスト課金」 が高くついている場合、「月のコンピュート + ストレージの 25% アップで I/O 課金ゼロ」 になる。試算して安くなるなら切替。Reserved Instance(1〜3 年)で 30〜60% 割引も検討。
Q. RDS から Aurora への移行は難しい?
A. MySQL / PostgreSQL なら比較的容易。「スナップショットから Aurora を作成』 『 RDS から Aurora にレプリケーション後切替」 のような方法がある。互換性は高いが、「Aurora 独自のパラメータ』 『 ストレージ動作の違い」 はチューニングで調整。
Q. Aurora Serverless v2 の最大 ACU はどれくらいまで上げるべき?
A. 余裕を持って大きく設定。「最大 ACU に達した瞬間に応答が悪化」 するので、想定ピークの 1.5〜2 倍に設定する。「料金は最大 ACU では決まらず、実際に使った ACU 分のみ」 なので、上限を高く設定しても固定費が増えない。
Q. Aurora と DynamoDB、どちらを選ぶ?
A. データの構造で決まる。「構造化データ + 関係性のあるクエリ」 なら Aurora、「単純な KV / 大量データ + 低レイテンシ」 なら DynamoDB。詳しくは AWS DB 全体比較 を参照。「両方併用(Aurora + DynamoDB)」 も多いパターン。
Q. グローバル展開する場合は?
A. Aurora Global Database(複数リージョン間で 1 秒以下のレプリケーション)を使う。「東京 + バージニア + シンガポール」 のような多地域構成で、各リージョンに読み取りレプリカを置ける。「災害復旧 + 地域別読み取り高速化」 が同時に実現できる。
まとめ
AWS で関係 DB を立てるとき、RDS / Aurora / Aurora Serverless v2 の選び分けは「ワークロードと料金体系で決まる」 のが本質です。「新規本番は Aurora プロビジョンド、開発 / ステージングは Aurora Serverless v2、既存 Oracle / SQL Server は RDS」 が現代の標準パターン。
「Aurora は高性能だが料金が 20〜30% 高い、Aurora Serverless v2 は変動課金で予測しにくいが負荷変動に強い、RDS は料金が予測しやすく Reserved で割引最大」 という特性を理解して選び分ければ、無駄なコストを払わずに最適なインフラを組めます。AWS DB 全体の選び方は AWS のデータベース比較 も併読してください。
参考リンク
- AWS: Amazon RDS
- AWS: Amazon Aurora
- AWS: Aurora Serverless v2
- AWS Docs: Aurora と RDS の比較
- AWS Pricing Calculator: 料金見積もりツール