Cloud Service
データベース選定（RDS / Aurora / DynamoDB / ElastiCache / Redshift）
AWSのDBの選び方。リレーショナルか、NoSQLか、キャッシュか、分析(DWH)か。要件から逆引き。
基礎
最終更新: 2026-05-31
要件から逆引き
| 要件 | 選ぶもの |
|---|---|
| 一般的なリレーショナルDB(SQL/JOIN) | RDS |
| 高可用・高性能なリレーショナル | Aurora |
| 超低遅延・大量アクセス・サーバーレスNoSQL | DynamoDB |
| 読み取りを高速化するキャッシュ | ElastiCache (Redis/Memcached) |
| 大量データの集計・分析(DWH) | Redshift |
| 全文検索/ログ分析 | OpenSearch Service |
詳細比較
| 観点 | RDS | Aurora | DynamoDB |
|---|---|---|---|
| モデル | リレーショナル | リレーショナル(高性能) | NoSQL(キーバリュー) |
| スケール | 縦＋リードレプリカ | ストレージ自動・最大15レプリカ | 水平・ほぼ無限・自動 |
| 可用性 | Multi-AZ(同期スタンバイ) | 6コピー(3AZ)・高速FO | マルチAZ・グローバル |
| クエリ | 柔軟なSQL/JOIN | 柔軟なSQL/JOIN | キー中心(JOINなし) |
| 運用 | マネージド | マネージド | サーバーレス |
| 向き | 既存資産/汎用 | 高負荷RDB | 超低遅延・大量 |
迷ったら
- JOINや複雑なSQLが要る → RDS / Aurora（高負荷ならAurora）
- キー引きで超低遅延・青天井スケール → DynamoDB
- DBの前にキャッシュして高速化/負荷軽減 → ElastiCache
- TB級を集計・BI → Redshift
試験のひっかけ
- Multi-AZ=可用性 / リードレプリカ=読み取りスケール（RDS）
- DynamoDBはアクセスパターン駆動設計・結果整合性が既定
- セッション/リーダーボード等の高速アクセスはElastiCache
AWS Service
データベース選定（RDS / Aurora / DynamoDB / ElastiCache / Redshift）を実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
cheatsheets
比較で見る軸
クラウド: AWS / カテゴリ: cheatsheets / 難易度: basic
導入後に効く点
導入後の運用手順、権限、監視、更新方法まで含めて評価します。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
数字・仕様の読み方
- クラウド
- AWS
- カテゴリ
- cheatsheets
- 難易度
- basic
- 関連資格
- —
- 設計柱
- —
判断チェックリスト
- 自社の用途が「cheatsheets」に近いか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。
次に確認する観点
cheatsheets