データベース選定（RDS / Aurora / DynamoDB / ElastiCache / Redshift）
要件から逆引きで最適な DB を選べる。リレーショナルか NoSQL か、キャッシュか分析(DWH)か、RDS / Aurora / DynamoDB / ElastiCache / Redshift の使い分けを一枚で。
要件から逆引き
| 要件 | 選ぶもの |
|---|---|
| 一般的なリレーショナル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 Cheat Sheet
データベース選定（RDS / Aurora / DynamoDB / ElastiCache / Redshift）を実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
RDS
比較で見る軸
クラウド: AWS / 形式: 比較早見表 / タグ数: 5
導入後に効く点
要件から逆引きで最適な DB を選べる。リレーショナルか NoSQL か、キャッシュか分析(DWH)か、RDS / Aurora / DynamoDB / ElastiCache / Redshift の使い分けを一枚で。
先に潰すリスク
早見表は入口なので、最終判断では要件、制約、料金、運用責任の違いまで確認する。
数字・仕様の読み方
- クラウド
- AWS
- 形式
- 比較早見表
- タグ数
- 5
判断チェックリスト
- 自社の用途が「RDS / Aurora」に近いか確認する。
- 強みである「要件から逆引きで最適な DB を選べる。リレーショナルか NoSQL か、キャッシュか分析(DWH)か、RDS / Aurora / DynamoDB / ElastiCache / Redshift の使い分けを一枚で。」が本当に評価軸になるか確認する。
- 注意点の「早見表は入口なので、最終判断では要件、制約、料金、運用責任の違いまで確認する。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。
次に確認する観点
RDSAuroraDynamoDBRedshiftDB選定