SAA データベース選択ガイド｜RDS・Aurora・DynamoDB・ElastiCache・Redshift の要件別選択基準
AWS SAA-C03 で問われるデータベース選択の判断軸を完全整理。RDS・Aurora（OLTP リレーショナル）・DynamoDB（NoSQL）・ElastiCache（キャッシュ）・Redshift（OLAP）の5サービスを「ワークロード型」「データモデル」「スケール要件」の3軸で即断できる粒度で解説。試験頻出ひっかけと正しい打ち手も完全網羅。
「どのデータベースを選ぶか」という問いに、SAA-C03 は3軸しか使わない。 RDS・Aurora・DynamoDB・ElastiCache・Redshift はいずれも「データを保存・検索する」サービスだが、「トランザクション処理が必要」「スキーマレスで毎秒数百万リクエスト」「クエリ結果を高速に返したい（キャッシュ）」「数十億行を集計・分析したい」の局面で答えが明確に分岐する。攻略の核心は**「ワークロード型（OLTP vs OLAP vs キャッシュ）」「データモデル（リレーショナル vs NoSQL）」「スケール・可用性要件（固定規模 vs 任意規模 / 単リージョン vs マルチリージョン）」の3軸**で要件を分類することだ。本記事では、SAA-C03 のデータベース問題を即断できる4設計パターンを、要件キーワードから逆引きできる粒度で解説する。
※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます
📑 目次
- 結論：データベース選択の4設計パターン
- 3軸の判断フレームワーク
- パターン1：RDS — マネージド OLTP リレーショナル DB
- パターン2：Aurora — クラウドネイティブ高可用性 RDB
- パターン3：DynamoDB + DAX — NoSQL サーバーレス・任意スケール
- パターン4：Redshift — OLAP データウェアハウス
- キャッシュ層：ElastiCache（Redis / Memcached）
- サービス比較：5サービスの特性一覧
- 要件キーワード早見表
- 頻出ひっかけパターンと正しい打ち手
- 次のアクション チェックリスト
- 関連記事
- 関連サイト
1. 結論：データベース選択の4設計パターン
SAA-C03 のデータベース問題を最短で解く骨格は、「どんな処理をするか（ワークロード型）」と「どんなデータ構造か（データモデル）」を先に決めることだ。
| パターン | 主な技術 | 典型的なシナリオ | 試験での見分け方 |
|---|---|---|---|
| 1. RDS | MySQL / PostgreSQL / Oracle / SQL Server / MariaDB / Db2 | EC2 と連携する一般的な OLTP アプリ | 「リレーショナル DB」「SQL」「マルチ AZ」「リードレプリカ」「既存エンジン移行」 |
| 2. Aurora | Aurora MySQL / Aurora PostgreSQL / Aurora Serverless / Aurora Global | 高可用性・高スループットの OLTP・グローバル展開 | 「MySQL/PostgreSQL 互換」「5倍高速」「6コピー3AZ」「グローバルデータベース」「サーバーレス」 |
| 3. DynamoDB | DynamoDB + DAX + Global Tables | スキーマレス・任意スケール・サーバーレス | 「NoSQL」「キーバリュー」「シングルケタミリ秒」「毎秒百万リクエスト」「スケールアウト」 |
| 4. Redshift | Redshift + Redshift Spectrum | 大規模分析・DWH・BI レポート | 「データウェアハウス」「OLAP」「大規模集計」「列指向」「S3 のデータを直接クエリ」 |
3軸の判断フレームワークを先に固めれば、4パターンのうちどれが正解かを即断できる。「トランザクション処理（SQL）」なら RDS か Aurora、「任意スケールの NoSQL」なら DynamoDB、「大規模分析」なら Redshift、そして「DB の前段にキャッシュが欲しい」なら ElastiCache という流れだ。
2. 3軸の判断フレームワーク
データベース選択の3軸
AWS データベースは「ワークロード型」「データモデル」「スケール・可用性要件」の3軸で分類すると、選択肢が絞り込める。
データベース選択フローチャート：
Step1: ワークロード型は？
├── OLTP（トランザクション処理） → RDS / Aurora / DynamoDB
├── OLAP（大規模分析・集計） → Redshift
└── キャッシュ（低レイテンシ読み込み） → ElastiCache
Step2: データモデルは？
├── リレーショナル（SQL・テーブル・JOIN） → RDS / Aurora
└── NoSQL（キーバリュー・ドキュメント） → DynamoDB
Step3: スケール・可用性要件は？
├── 既存エンジン・固定規模 → RDS（マルチAZ + リードレプリカ）
├── 高スループット・グローバル展開 → Aurora（Global Database）
└── 任意規模・サーバーレス → DynamoDB / Aurora Serverless| 軸 | 問い | 答えの分岐 |
|---|---|---|
| ワークロード型 | OLTP / OLAP / キャッシュ | OLTP → RDS/Aurora/DynamoDB、OLAP → Redshift、キャッシュ → ElastiCache |
| データモデル | リレーショナル / NoSQL | リレーショナル → RDS/Aurora、NoSQL → DynamoDB |
| スケール・可用性 | 固定規模 / 任意スケール / グローバル | 固定 → RDS、高速/グローバル → Aurora、任意 → DynamoDB/Aurora Serverless |
3. パターン1：RDS — マネージド OLTP リレーショナル DB
概要
既存の DB エンジン（MySQL・PostgreSQL・Oracle・SQL Server・MariaDB・Db2）をフルマネージドで使うパターン。OS パッチ・バックアップ・フェイルオーバーを AWS が担当し、マルチ AZ（同期レプリケーション）でシステム障害に備える。リードレプリカ（非同期レプリケーション）で読み込みを水平スケールできる。
RDS マルチAZ 構成：
Primary DB（AZ-a）────同期レプリカ────▶ Standby DB（AZ-b）
│ ↑
自動フェイルオーバー（1〜2分）──────────────────┘
│
読み込みスケール ──▶ Read Replica（AZ-c）RDS の主なエンジンと選択基準
| エンジン | 選ぶシナリオ | SAA での注目ポイント |
|---|---|---|
| MySQL | LAMP スタック・汎用 Web アプリ | Aurora MySQL への移行元 |
| PostgreSQL | 複雑なクエリ・GIS・拡張機能 | Aurora PostgreSQL への移行元 |
| Oracle | 既存商用 DB のリフト&シフト | BYOL or License Included |
| SQL Server | Windows ベースアプリ | Always On → RDS Multi-AZ |
| MariaDB | MySQL 互換でコスト重視 | MySQL の代替 |
試験での要件キーワード
- 「既存 MySQL / PostgreSQL をフルマネージドで移行したい」→ RDS
- 「DB 障害時に自動フェイルオーバーしたい」→ RDS マルチ AZ
- 「読み込み負荷を分散したい」→ RDS リードレプリカ（最大 15 台）
- 「Lambda から DB 接続数が急増して接続プール枯渇する」→ RDS Proxy
4. パターン2：Aurora — クラウドネイティブ高可用性 RDB
概要
MySQL / PostgreSQL と互換性を保ちながら、クラウドネイティブ設計で高パフォーマンス・高可用性を実現するパターン。ストレージが6コピー3AZ に自動分散されるため、耐久性が著しく高い。標準 MySQL の最大5倍、PostgreSQL の最大3倍のスループットを発揮。グローバルデータベース（Aurora Global）やキャパシティを自動調整するサーバーレス（Aurora Serverless v2）も提供。
Aurora クラスター構成：
Aurora Writer（AZ-a）
├─── Aurora Reader 1（AZ-b）─── 読み込みエンドポイント
├─── Aurora Reader 2（AZ-c）─── 読み込みエンドポイント
└─── 共有ストレージ（6コピー × 3AZ = 自動レプリケーション）
Aurora Global Database：
Primary リージョン ──▶ Secondary リージョン（RPO 1秒以内）Aurora vs RDS の選択基準
| 評価項目 | Aurora | RDS |
|---|---|---|
| エンジン | MySQL / PostgreSQL 互換（独自クラウドエンジン） | MySQL / PostgreSQL / Oracle / SQL Server / MariaDB / Db2 |
| スループット | MySQL の最大5倍・PostgreSQL の最大3倍 | 標準的なエンジン性能 |
| ストレージ | 自動拡張（10GB〜128TiB、6コピー3AZ） | 固定プロビジョン（gp3/io1/io2） |
| フェイルオーバー | 30秒以内（ストレージ共有のため高速） | 1〜2分（Multi-AZ 同期レプリカへの切替） |
| リードレプリカ | 最大15台・レプリケーション遅延ミリ秒以内 | 最大15台・遅延は秒単位の場合あり |
| サーバーレス | Aurora Serverless v2（容量を自動調整） | 非対応 |
| グローバル展開 | Aurora Global Database（クロスリージョン RPO 1秒以内） | 非対応（クロスリージョンリードレプリカは可） |
| コスト | RDS より約20%高い（ただし性能効率で逆転することも） | Aurora より安価（ただし同スループット達成にはインスタンスを大きくする必要あり） |
試験での要件キーワード
- 「MySQL 互換で高スループット・高可用性が必要」→ Aurora MySQL
- 「PostgreSQL を5倍高速に動かしたい」→ Aurora PostgreSQL
- 「ストレージ容量を事前に見積もりたくない」→ Aurora（自動拡張）
- 「クロスリージョンで RTO/RPO を最小化（DR）」→ Aurora Global Database
- 「開発環境で使わないとき DB を完全停止してコスト削減したい」→ Aurora Serverless v2
5. パターン3：DynamoDB + DAX — NoSQL サーバーレス・任意スケール
概要
スキーマレスのキーバリュー型 NoSQL でシングルケタミリ秒のレイテンシを任意のスケールで提供するパターン。1日に10兆件のリクエストを処理し、毎秒2000万件のピーク対応実績を持つフルマネージドサービス。サーバーレス（容量を事前プロビジョン不要）で、グローバルテーブルによるマルチリージョン展開も可能。さらに高速なレイテンシが必要な場合は DAX（DynamoDB Accelerator）でマイクロ秒台のキャッシュを追加できる。
DynamoDB + DAX の構成：
アプリ ──▶ DAX クラスター（マイクロ秒キャッシュ）──▶ DynamoDB（シングルケタミリ秒）
キャッシュヒット時: ~microseconds
キャッシュミス時: DynamoDB へ通過 (~single-digit ms)
DynamoDB Global Tables（マルチリージョン）：
ap-northeast-1 ◀──── 双方向レプリカ ────▶ us-east-1DynamoDB の主な機能
| 機能 | 説明 | SAA でのキーワード |
|---|---|---|
| プロビジョンドスループット | RCU/WCU を事前設定（予測可能な負荷向け） | 「一定の読み書き負荷」 |
| オンデマンドモード | 使った分だけ課金（トラフィック変動が大きい場合） | 「急増するトラフィック」「予測困難」 |
| Global Tables | マルチリージョン双方向レプリカ | 「グローバル展開」「多リージョン Active-Active」 |
| DynamoDB Streams | テーブル変更をリアルタイムストリームで受信 | 「変更トリガー」「Lambda との連携」 |
| DAX | インメモリキャッシュ（マイクロ秒台） | 「DynamoDB をさらに高速化」「読み込み負荷軽減」 |
| TTL（Time to Live） | 期限切れアイテムを自動削除 | 「セッション管理」「一時データ自動削除」 |
試験での要件キーワード
- 「スキーマレスで毎秒数百万リクエスト、シングルケタミリ秒」→ DynamoDB
- 「DynamoDB の読み込みをさらにマイクロ秒台に高速化したい」→ DAX
- 「ゲームのスコアボード・ランキング（ソート済みセット）」→ DynamoDB（ソートキー活用）
- 「マルチリージョンで Active-Active DB が必要」→ DynamoDB Global Tables
- 「DynamoDB の変更で Lambda を起動したい」→ DynamoDB Streams + Lambda
6. パターン4：Redshift — OLAP データウェアハウス
概要
数十億行・ペタバイト規模のデータを高速集計・分析するクラウドデータウェアハウスパターン。列指向ストレージ（Columnar Storage）と並列クエリ処理（MPP）で OLAP クエリを高速化。Redshift Spectrum を使えば S3 上のデータを Redshift テーブルと結合してクエリ可能で、BI・データレイク分析の中心に置ける。
Redshift アーキテクチャ：
S3 データレイク ──▶ Redshift Spectrum（外部テーブル）──┐
DynamoDB / RDS ──▶ zero-ETL 統合（自動取込） ├── Redshift クラスター（MPP）──▶ BI ツール
Kinesis / MSK ──▶ ストリーミング取込 ┘Redshift の主な機能
| 機能 | 説明 | SAA でのキーワード |
|---|---|---|
| 列指向ストレージ | 集計クエリで必要列のみ読み込み → I/O 削減 | 「大規模 SELECT / GROUP BY / JOIN」 |
| MPP（並列クエリ） | 複数ノードで並列実行 | 「ペタバイト規模の高速分析」 |
| Redshift Spectrum | S3 データを外部テーブルとして直接クエリ | 「S3 のデータを SQL で分析」「データレイク統合」 |
| RA3 ノード | コンピュートとストレージを分離してスケール | 「コンピュートとストレージを独立スケール」 |
| zero-ETL 統合 | Aurora / DynamoDB → Redshift をリアルタイム同期 | 「ETL パイプライン不要」「リアルタイム分析」 |
試験での要件キーワード
- 「数十億行のデータを集計・分析したい（DWH）」→ Redshift
- 「S3 に保存した大量ログを SQL で分析したい」→ Redshift Spectrum
- 「RDS のトランザクションを分析用に Redshift へリアルタイム同期したい」→ zero-ETL 統合
- 「BI ツール（QuickSight・Tableau）からクエリしたい」→ Redshift（JDBC/ODBC 接続）
7. キャッシュ層：ElastiCache（Redis / Memcached）
概要
データベースの前段にインメモリキャッシュを置き、レイテンシを削減・DB 負荷を軽減するパターン。ElastiCache は Redis OSS 互換（ElastiCache for Redis）と Memcached 互換（ElastiCache for Memcached）を提供。RDS・Aurora・DynamoDB どのデータベースとも組み合わせて使えるが、単体でデータを永続化する用途には MemoryDB for Redis が適切。
キャッシュ層パターン（Cache-Aside）：
アプリ ──▶ ElastiCache（キャッシュあり）──▶ 即返答（マイクロ秒〜サブミリ秒）
└─▶（キャッシュなし）──▶ RDS/Aurora ──▶ 結果をキャッシュに書き込みRedis vs Memcached の選択
| 評価項目 | Redis（推奨） | Memcached |
|---|---|---|
| データ構造 | 文字列・リスト・セット・ハッシュ・ソートセット・Bitmap 等 | 文字列（キーバリュー）のみ |
| パーシステンス | RDB スナップショット / AOF ログで永続化可 | 非対応（再起動でデータが消える） |
| レプリケーション | なし | |
| マルチスレッド | Redis 7以降は I/O マルチスレッド対応 | 完全マルチスレッド（CPU コアを最大活用） |
| 典型用途 | セッション管理・リーダーボード・Pub/Sub・ML キャッシュ | 単純な大規模 KV キャッシュ・マルチコア最大活用 |
試験での要件キーワード
- 「DB のクエリ結果をキャッシュして応答速度を上げたい」→ ElastiCache（どちらでも可）
- 「セッション情報をアプリサーバー間で共有したい」→ ElastiCache for Redis
- 「ゲームリーダーボード（スコア順ランキング）」→ ElastiCache for Redis（Sorted Set）
- 「最もシンプルなキャッシュ・マルチスレッドで高スループット」→ ElastiCache for Memcached
- 「インメモリ DB として永続性が必要（キャッシュ以上の用途）」→ MemoryDB for Redis
8. サービス比較：5サービスの特性一覧
| 評価項目 | RDS | Aurora | DynamoDB | ElastiCache | Redshift |
|---|---|---|---|---|---|
| ワークロード | OLTP（汎用 RDB） | OLTP（高性能 RDB） | OLTP（NoSQL） | キャッシュ | OLAP（DWH） |
| データモデル | リレーショナル | リレーショナル | キーバリュー / ドキュメント | キーバリュー | 列指向リレーショナル |
| SQL | ✅ | ✅（互換） | ❌（PartiQL は可） | ❌ | ✅（拡張 SQL） |
| スケール | 垂直スケール | 自動拡張 + 水平 Reader | 水平スケール（無制限） | 水平スケール | MPP 並列処理 |
| レイテンシ | ミリ秒〜秒 | ミリ秒（高スループット） | シングルケタミリ秒 | マイクロ秒〜サブミリ秒 | 秒〜分（大量データ集計） |
| フルマネージド | ✅ | ✅ | ✅ | ✅ | ✅ |
| マルチリージョン | リードレプリカのみ | Global Database（双方向） | Global Tables（双方向） | ❌（リージョン内のみ） | ❌（RA3 はリージョン内） |
| サーバーレス | ❌ | ✅（Serverless v2） | ✅（オンデマンドモード） | ❌ | ✅（Redshift Serverless） |
9. 要件キーワード早見表
SAA-C03 のデータベース問題は、問題文のキーワードから最短1秒で答えを特定できるようになるまで練習すること。
| キーワード | 正解サービス | 理由 |
|---|---|---|
| 「既存 MySQL / PostgreSQL を移行」 | RDS（または Aurora） | マネージド OLTP リレーショナル DB |
| 「MySQL 互換で5倍高速・高可用性」 | Aurora | クラウドネイティブ RDB |
| 「自動フェイルオーバー 30秒以内」 | Aurora（RDS Multi-AZ より高速） | ストレージ共有により Writer 切替のみ |
| 「クロスリージョン DR（RPO 1秒以内）」 | Aurora Global Database | グローバル展開 RDB |
| 「サーバーレス・使わないとき0コスト」 | Aurora Serverless v2 | 開発/テスト環境・不定期ワークロード |
| 「NoSQL・シングルケタミリ秒・任意スケール」 | DynamoDB | キーバリュー型 NoSQL |
| 「DynamoDB をさらにマイクロ秒に高速化」 | DAX | DynamoDB 専用キャッシュ |
| 「マルチリージョン Active-Active DB」 | DynamoDB Global Tables | 双方向レプリカ |
| 「セッション管理・ゲームリーダーボード」 | ElastiCache for Redis | 永続化・Sorted Set 対応 |
| 「単純キャッシュ・マルチコア最大活用」 | ElastiCache for Memcached | 高スループットキャッシュ |
| 「ペタバイト規模の大規模集計・DWH」 | Redshift | OLAP 列指向 MPP |
| 「S3 のデータを SQL で直接クエリ」 | Redshift Spectrum | ETL なし S3 結合 |
| 「RDS の分析クエリが重い→別サービスへ」 | Redshift（OLAP に移管） | OLTP/OLAP を分離 |
| 「Lambda から RDS への接続が枯渇する」 | RDS Proxy | 接続プール管理 |
10. 頻出ひっかけパターンと正しい打ち手
ひっかけ1：「SQL が使えるから RDS を選ぶ」
誤： 「SQL クエリが必要 → RDS を選ぶ」
正： SQL が使えるサービスは RDS・Aurora・Redshift の3つ。要件がスケールや高可用性を重視するなら Aurora、大規模集計なら Redshift。「SQL が使える」だけでは RDS に絞れない。
ひっかけ2：「NoSQL だから DynamoDB をキャッシュに使う」
誤： 「キャッシュが必要・レイテンシを下げたい → DynamoDB（NoSQL）を選ぶ」
正： DynamoDB はシングルケタミリ秒の OLTP データストア。マイクロ秒台のキャッシュが必要なら ElastiCache（または DAX）。「低レイテンシキャッシュ」というキーワードには ElastiCache/DAX が正解。
ひっかけ3：「グローバル展開 → Multi-AZ RDS を選ぶ」
誤： 「マルチリージョンで低レイテンシが必要 → RDS マルチ AZ」
正： RDS マルチ AZ は同一リージョン内の AZ 障害対策。クロスリージョン展開には Aurora Global Database（リレーショナル）または DynamoDB Global Tables（NoSQL）が正解。
ひっかけ4：「Redshift で OLTP トランザクションを処理する」
誤： 「大量のユーザーリクエストを処理 → Redshift を使う」
正： Redshift は OLAP（分析・集計）専用。大量の短いトランザクション（ユーザー操作・注文処理など）は RDS / Aurora / DynamoDB が正解。OLTP と OLAP を別サービスに分離することが設計の基本。
ひっかけ5：「ElastiCache を永続データストアとして使う」
誤： 「インメモリで高速に読み書きしたい → ElastiCache を Primary DB として使う」
正： ElastiCache（特に Memcached）は再起動でデータが消えるキャッシュ専用。インメモリ DB として永続性が必要な場合は MemoryDB for Redis（Multi-AZ 永続化対応）が正解。
11. 次のアクションチェックリスト
- RDS の6エンジン（MySQL・PostgreSQL・Oracle・SQL Server・MariaDB・Db2）と選択理由を確認
- Aurora vs RDS の差別化ポイント（フェイルオーバー速度・ストレージ自動拡張・サーバーレス）を確認
- DynamoDB の「オンデマンド vs プロビジョンドスループット」の切り替えシナリオを確認
- DAX（DynamoDB 専用）と ElastiCache（汎用）の使い分けを説明できるか確認
- ElastiCache for Redis vs Memcached の差別化ポイント（永続化・レプリカ・データ構造）を確認
- Redshift Spectrum と Athena の違い（既存 Redshift クラスターがある場合は Spectrum）を確認
- 「OLTP → OLAP 分離」「NoSQL → キャッシュ追加（DAX）」「グローバル展開（Aurora Global / DynamoDB Global Tables）」の3シナリオで即答できるか模擬問題で確認
12. 関連記事
- SAA RDS/Aurora設計パターン
- SAA DynamoDB設計パターン
- SAA ストレージ選択ガイド（S3/EBS/EFS/FSx/Storage Gateway）
- SAA コスト最適化設計パターン4選（EC2購入オプション・S3ライフサイクル）
- SAA データレイク設計パターン
- Amazon RDS 詳細解説
- Amazon Aurora 詳細解説
- Amazon DynamoDB 詳細解説
- Amazon ElastiCache for Redis 詳細解説
- Amazon Redshift 詳細解説