先に要点
- AWS の DB サービスは 関係DB(RDS / Aurora)・KVS(DynamoDB)・キャッシュ(ElastiCache)・データウェアハウス(Redshift) の4系統に分かれていて、まずこの分類で `何のための DB か` を決めるのが先決。
- 多くの一般的な Web サービスは Aurora(または RDS for MySQL/PostgreSQL)+ DynamoDB(セッション・通知系)+ ElastiCache(セッション・キャッシュ) の組み合わせで足りる。Redshift は BI / 集計分析 のフェーズで初めて検討すべき。
- `Aurora は速い RDS` という雑な理解だと運用で迷うので、Aurora は RDS の高可用・高性能サブセット、DynamoDB は 関係DBの代替ではなくスケール特化の別物 と捉える。
- 選び方は ① データの形(構造化 / KV / 時系列 / グラフ)、② スケール特性、③ クエリパターン、④ 料金モデル の4軸で判断するのが筋。`性能が高そう` だけで選ばない。
AWS の DB ってサービスが多すぎてどれを選べばいいかわからない RDS と Aurora は何が違うの？ DynamoDB って結局いつ使うの？ ── オンプレ感覚で AWS に入ると、最初に詰まりやすいのが DB 選びです。
AWS は 汎用 DB 1つ ではなく 用途別に専用 DB を提供する という設計思想 でサービスを並べています。
このため、どれが優れているか ではなく 何のためのデータをどう扱うかで使い分ける という発想 が必須です。
ここを理解しないまま とりあえず Aurora とりあえず DynamoDB で始めると、後から手戻りやコスト膨張で痛い目を見やすい領域でもあります。
この記事では、2026年5月時点の AWS の主要 DB サービスを 5つに絞って比較 し、どんな業務で何を選ぶべきかを実務目線で整理します。 細かい価格やマイナーバージョン情報は変動するため、最終的には 公式のデータベース製品ページ も参照してください。
まず分類で押さえる
AWS DB サービスは、データの形と使い方で 4系統に分けて把握 するのが一番頭に入ります。
| 系統 | 役割 | 代表サービス |
|---|---|---|
| 関係 DB (RDBMS) | 表形式の業務データ、JOIN、トランザクション | RDS / Aurora |
| NoSQL / KVS | キー・バリュー、JSON 的なドキュメント、超高スケール | DynamoDB |
| キャッシュ | セッション、計算結果、ホットデータの高速アクセス | ElastiCache(Redis / Memcached) |
| データウェアハウス | BI / レポート / 集計分析 | Redshift |
使いたい機能 ではなく データの性質 で分けるのがコツです。
Web サービスの本体データは関係DB、セッションやレートリミットの一時データは KVS、過去ログの分析は DWH、という具合に、1つの DB で全部やる発想を捨てる のが AWS 流の設計です。
RDS と Aurora — 関係DBの主役
最も使われるのが RDS(Relational Database Service)と Aurora です。
RDS とは
MySQL / PostgreSQL / MariaDB / Oracle / SQL Server などの主要 RDBMS を、`バックアップ・パッチ適用・複製・スケール変更` などの運用を AWS に任せて使えるマネージドサービス。`普通の RDBMS をクラウドで楽に運用する` ためのもの。
Aurora とは
AWS が独自に作り直した、`MySQL / PostgreSQL 互換` の高性能・高可用 DB。RDS の中の `特殊エンジン` という位置づけで、MySQL の最大5倍 / PostgreSQL の最大3倍 と公式に謳う性能が出るケースもある。
違いをひと言で
RDS は `普通の MySQL/PostgreSQL をマネージドで動かす`。Aurora は `MySQL/PostgreSQL 互換だが、ストレージ層が完全に AWS 独自設計` で、複製・障害回復・スケールがクラウド前提に作られている。
ざっくり言うと、 RDS = 標準モデルのレンタカー、Aurora = AWS チューニング版 という感覚です。
Aurora は高性能と引き換えに 固定費がやや高め なので、最初の MVP やコスト最小化を優先するなら RDS から入って、規模に応じて Aurora に乗り換えるのが合理的なルートです。
バージョン互換とロックインの注意
Aurora は MySQL / PostgreSQL 互換 を謳っていますが、ストレージ層が独自なので、セルフホストや他クラウドへの移行コストは高め です。
気軽に MySQL に戻せる ではなく、Aurora を選んだら基本的には AWS にいる前提 と捉えるのが正しい認識です。
DynamoDB — NoSQL / KVS の主役
DynamoDB は、AWS が完全に自前で作っている キーバリュー / ドキュメント型 NoSQL です。
RDS や Aurora とは思想が違うので、関係DBの代わり ではなく 別物の道具 として理解 するのが安全です。
向いている用途
セッション、ユーザープロファイル、IoT のセンサーデータ、通知、メッセージ、レートリミット、URL 短縮、ゲームのアイテム情報など、キーが決まっていて高速・大量に読み書きしたい データ。
スケールの強さ
水平スケールが前提で、ピークアクセスにほぼ無制限で耐える。`スケールするか不安` が要らなくなる代わりに、設計時のキー設計が成否を左右する。
料金モデル
On-Demand(リクエスト単位の従量)と Provisioned(事前予約のキャパシティ)から選べる。スパイクの読みづらいワークロードは On-Demand、コスト最適化したいなら Provisioned + Auto Scaling。
関係DBを置き換える』ではなく、<strong> 関係DBが苦手な領域を補完する` のが DynamoDB の正しい役回りです。
Web サービス本体は Aurora、セッションやレートリミットは DynamoDB、というように 関係DBと組み合わせて使う のが定石です。
ElastiCache — キャッシュ専用
ElastiCache は Redis / Memcached をマネージドで提供するサービスで、頻繁に読み書きする一時データ のために使います。
Redis と Memcached の違い
Redis はデータ構造が豊富(リスト・集合・ソート集合・ストリーム等)、永続化や複製も対応。Memcached は機能を絞って軽量に。現代のほぼすべての案件は Redis で問題ない。
DynamoDB との使い分け
ElastiCache は 揮発前提 で `落ちて消えても致命的でない` データ向き。DynamoDB は 永続前提 でビジネスデータとして残したい情報向き。`同じセッション保管` でも、ELB セッションは ElastiCache、ユーザープロファイルは DynamoDB、と分けるのが現実的。
料金感
インスタンス時間単位。小さくて頻繁な読み込みで威力を発揮するので、`体感が遅い API がある` `DB が頻繁に同じクエリで叩かれている` ときに導入を検討。
ElastiCache は 関係DBが疲弊しているときの逃げ場 として使う のが基本で、最初から導入する必要は薄め。API が遅くなってきた DB の CPU が高い フェーズで初めて入れるのが、コスト面でも分かりやすい使い方です。
Redshift — データウェアハウス
Redshift は、業務システムの本番 DB ではなく、分析・BI 用に作られた DB です。
ペタバイト級のデータを 列指向ストレージ + 並列処理 で集計するために最適化されており、OLTP(オンライントランザクション)向けではありません。
典型用途
BI ツール(Tableau / QuickSight / Looker)から叩く分析クエリ、過去ログの月次集計、データレイク(S3)+ DWH の組み合わせ、機械学習の前処理用テーブル。
どこで光るか
`数億行を JOIN して GROUP BY` のような集計クエリ。Aurora や RDS で重くて時間がかかる類のクエリが、Redshift だと数秒で返る。
向いていないこと
Web サービス本体のリアルタイム更新、1件ごとの参照、頻繁な細かい UPDATE。`本番アプリの DB` として使う対象ではない。
分析の話が出てきた瞬間に Redshift ではなく、まずは Aurora の集計クエリで足りないか Athena で十分でないか を順に検討してから、それでも足りない / レポート用ユーザーが多い / リアルタイムに近い分析が必要、というフェーズで Redshift を入れるのが現実的です。
横断比較表
5つの主要サービスを1枚に並べて比較すると、選び方が一目で見えます。
| サービス | タイプ | 得意領域 | 料金感(目安) | スケール |
|---|---|---|---|---|
| RDS | 関係 DB(マネージド) | 標準的な業務 DB、安価に始めたい | 低〜中 | 縦スケール中心 + Read Replica |
| Aurora | 関係 DB(AWS 独自高性能版) | 高可用 + 大規模 + Serverless v2 | 中〜高 | 水平 Read + 自動拡張ストレージ |
| DynamoDB | NoSQL / KVS | セッション、IoT、通知、超高スケール | 低〜中(設計次第) | 無制限水平スケール |
| ElastiCache | キャッシュ(Redis/Memcached) | セッション、ホットデータ、レート制御 | 低〜中 | クラスタモードで水平拡張 |
| Redshift | データウェアハウス | BI、集計、分析、大規模 JOIN | 中〜高 | ノード単位の水平拡張 |
安いから RDS、速いから Aurora、何でもいいから DynamoDB という選び方は、ほぼ毎回ハマります。
何のデータを、どんなアクセスパターンで使うか を最初に整理してから、上の表に当てはめると この用途にはこれ がはっきり見えるはずです。
選び方の判断フロー
ユースケースに応じた選び方を、現場で使えるフローで整理します。
このフローの効用は、 何を選ぶか よりも 何を選ばないか がはっきりすること です。
Aurora で全部やる DynamoDB で全部やる の発想が消え、各 DB を持ち場に置く 思考に切り替えやすくなります。
失敗パターンと回避策
実際の現場でよくある DB 選択の失敗を、回避策とセットで挙げておきます。
①過小評価で RDS の t系を本番に使う
MVP は OK だが、本番でアクセスが伸びたら CPU バーストが切れて急に応答が遅くなる。本番に出すタイミングで m / r 系に上げる、もしくは Aurora に乗せ替える計画を最初から織り込んでおく。
② DynamoDB を関係DB感覚で使う
JOIN や複数条件検索を `仕方なく` Scan で頑張ると、料金と性能の両方で痛い目を見る。`どのアクセスパターンが頻発するか` を先に整理し、それに合わせて Partition Key / Sort Key / GSI を設計 する。
③ Redshift を小規模で持つ
データ量が小さい段階で Redshift を持つと、固定費の割に効果が薄い。まず Athena で S3 にクエリを投げて十分か検証、それでも足りなくなってから Redshift に進む方が経済的。
DB 選びの失敗は、 性能 ではなく 想定したアクセスパターンと実際のずれ で起きる のが大半です。
最初に どんなクエリが、どのくらいの頻度で、どのくらい複雑な条件で来るのか を洗い出すと、上のような事故はかなり防げます。
AWS の他要素との関係
DB だけを単独で語ると判断が偏るので、関連の AWS 設計記事と合わせて見ておくと立体的に把握できます。 AWS を 1 アカウントで運用すると辛くなる理由 や AWS の小規模 Web 構成パターン は、DB の置き方とアカウント / ネットワーク設計の関係を理解するのに役立ちます。
また、本番運用に入る前段階で抑えるべきセキュリティ・監査の話は AWS で最初にやるべきこと や AWS CloudTrail とは、IAM の基本は AWS IAM の基本 にまとめてあります。
DB 選びだけが先行して、認証・監査・ネットワークが置き去りになるのもよくあるパターンなので、DB は 全体設計の中の1ピース として置く という感覚で進めるのが安全です。
AWS DB に関するよくある質問
Q. MVP の段階ではどの DB を選べばいいですか？
A. ほぼ間違いなく RDS for MySQL もしくは Aurora MySQL/PostgreSQL の小さいインスタンス で十分です。AWS の DB を勉強したいから DynamoDB から入る のような技術好奇心ベースの選び方は、後で関係DBへの移行コストが重くのしかかるので避けるのが無難です。
Q. Aurora と RDS for MySQL の料金差はどう見ればいいですか？
A. Aurora は インスタンス料金 + ストレージ + I/O 料金 の3軸、RDS は インスタンス料金 + ストレージ料金 の2軸が中心です。小規模では RDS の方が安く済みやすく、規模が伸びると Aurora の方が運用負荷とトータルコストで有利になりがちです。
Q. DynamoDB を関係DBの代わりに使えますか？
A. 推奨しません。アクセスパターンが固定で、JOIN や複雑な検索が不要なケースなら成立しますが、多くの業務システムでは関係DBで設計した方が後の変化に耐えやすいです。関係DBで足りないところを補う のが DynamoDB の正しい位置づけです。
Q. キャッシュは ElastiCache、DynamoDB、それともアプリ内？
A. 用途で分けます。揮発可・高速・サーバ間共有が必要 なら ElastiCache、少し長く保ちたい・永続性が要る なら DynamoDB、1リクエスト内で完結 ならアプリ内メモリ、です。
Q. Redshift と Athena はどう違いますか？
A. Redshift は専用クラスタを持つ DWH、Athena は S3 上のファイルに直接 SQL を投げるサーバレスサービスです。常時クエリが走る BI 用途は Redshift、たまにバッチ分析する程度なら Athena がコスト的に向きます。
Q. AWS の DB はオンプレ DB と何が違いますか？
A. 大きな違いは 運用作業がマネージドで吸収される 点と、スケール / 冗長化がクラウド前提で設計されている 点です。バックアップ、パッチ、複製、フェイルオーバーなどを自前で運用しなくていい代わりに、AWS の流儀に合わせる ことを受け入れる必要があります。
Q. 後から DB サービスを乗り換えるのは大変ですか？
A. 同じ系統内(RDS → Aurora、Redis → DynamoDB Streams)は比較的容易ですが、関係DB ↔ DynamoDB のような系統跨ぎは事実上の再設計 です。データモデルとアクセスパターンが根本的に違うため、最初の選択を慎重にするのが結局いちばん安いです。
参考リンク
- AWS: Databases on AWS
- AWS: Amazon RDS
- AWS: Amazon Aurora
- AWS: Amazon DynamoDB
- AWS: Amazon ElastiCache
- AWS: Amazon Redshift
- AWS: Amazon Athena