試験は“要件→サービス”の逆算で解ける
SAA-C03のDB選定問題で多いのが、「RDS？Aurora？DynamoDB？」で名前の違いに引っ張られて迷うパターンです。
でも、試験が見ているのはサービス名の暗記ではなく、要件に対して最も筋が通る設計判断ができるかです。
ポイントはシンプルで、次の順番で逆算します。
- ① 要件（何を満たしたい？）：整合性・性能・可用性・スケール・レイテンシ
- ② 制約（何ができない？）：SQL必須、Join必須、スキーマ固定、運用体制、移行期限
- ③ 運用（誰が回す？）：バックアップ、パッチ、スケーリング、障害対応
- ④ コスト（変動？固定？）：スパイク時のコスト、読み取り増時のコスト
- ⑤ サービス（何が最短で満たす？）：RDS / Aurora / DynamoDB に落とす
この記事では、SAA-C03でそのまま使えるように、「要件キーワード→最有力サービス」へ即変換できる決定表と、よく出るシナリオ別の選び方をまとめます。
読み終える頃には、選択問題でこう判断できるようになります。
- 「SQL/Join/ACIDが必須」→ まずRDS/Auroraに絞る
- 「アクセスが急増・予測不能・低遅延が最優先」→ DynamoDBが最短
- 「RDBのまま高可用・高性能を狙いたい」→ Auroraを疑う
3サービスの位置づけを最短で理解
ここでは細かい機能一覧はやりません。SAA-C03で必要なのは、**“どの土俵のサービスか”**を即答できることです。
RDS：マネージドRDB
Amazon RDSは、MySQL / PostgreSQL / MariaDB / Oracle / SQL Server などの一般的なリレーショナルDBをマネージドで提供します。
試験での立ち位置は「SQL前提の業務システム」の第一候補です。
- SQLが必要
- Joinやトランザクションが必要
- 既存のRDB資産（設計・運用・知見）を活かしたい
- 一般的な性能・可用性でOK（マルチAZなどで担保）
Aurora：クラウド最適化RDB
Amazon Auroraは、MySQL互換 / PostgreSQL互換の高性能・高可用を狙いやすいRDBです。
試験では「RDBが必要だが、より強い可用性・性能・スケールが欲しい」ときに選ばれがちです。
- RDB（SQL/ACID）を維持したまま、可用性・性能を上げたい
- 読み取りが増える（読み取り分離/スケールの文脈）
- 障害耐性を厚くしたい（設計の意図として）
※細部の実装差は問題文が補ってくれます。あなたがやることは「Auroraを選ぶべき要件ワード」を拾うこと。
DynamoDB：マネージドNoSQL
DynamoDBは、キー・バリュー/ドキュメント型のNoSQLで、大規模スケールと一貫した低遅延に強い選択肢として出ます。
- アクセスが急増・予測不能（スパイク）
- 1桁ミリ秒級の低レイテンシを求める（文脈で）
- スキーマが柔軟でOK、Join不要
- “運用を極小化したい”が強い（サーバレス寄りの文脈）
まず覚える結論：
- SQL/Join/複雑な検索が必要 → RDS or Aurora
- 予測不能なスケール/低遅延/キーアクセス中心 → DynamoDB
- RDBのまま可用性・性能を強く → Aurora
要件キーワード決定表
SAA-C03では、長い文章の中に“判定ワード”が埋め込まれます。
次の表を頭に入れておくと、選択肢が一気に2つ以下に絞れます。
要件→サービス決定表
| 要件キーワード（問題文の匂い） | 最有力 | 理由（1行で） | よくある引っかけ |
|---|---|---|---|
| SQLが必要 / Joinが必要 / 正規化 / 複雑な検索 | RDS or Aurora | RDBの土俵 | DynamoDBを選ばせたい誘惑（Joinが必要なら基本NG） |
| ACIDトランザクションが重要 | RDS or Aurora | 一貫性が最優先 | “高速”だけでDynamoDBに飛ばない |
| 既存がMySQL/PostgreSQLで移行を急ぐ | RDS（またはAurora互換） | 互換性・移行容易性 | “Auroraの方が新しいから”は理由にならない |
| 高可用・高性能のRDBが必要 | Aurora | RDBのまま性能/可用性を盛る文脈 | RDSでも満たせる要件ならRDSが正解の場合もある |
| 読み取りが爆増（Read-heavy） | Aurora（文脈次第でRDS） | 読み取り拡張の意図 | “書き込みが中心”なら別判断 |
| 秒間数万、急増、予測不能、グローバル規模 | DynamoDB | スケールと低遅延 | SQLが必要なら戻る |
| 1桁msの低遅延が必須 | DynamoDB | 低遅延の定番 | ただの“高速化したい”程度なら断定しない |
| スキーマ柔軟 / 属性が増える / 半構造データ | DynamoDB | ドキュメント型に寄る | 逆に“厳密な参照整合性”があればRDB |
| 運用を最小化（パッチ/スケールを意識したくない） | DynamoDB（or Aurora Serverless文脈） | マネージド＋スケールが楽 | “既存RDB資産”が強いならRDS/Aurora |
| 集計や分析クエリが多い（複雑なWHERE/GROUP BY） | RDS or Aurora | クエリ表現力 | DynamoDBはクエリ自由度で苦戦しやすい |
迷いを消す最短ルール
- Joinが必要と書いてあったら、まずDynamoDBを外す
- 予測不能な急増が強いなら、まずDynamoDBを疑う
- **RDBのまま“可用性・性能を強く”**が見えたらAuroraを疑う
- 最後に「移行・互換性・運用体制」でRDSとAuroraのどちらかを詰める
頻出パターン別の選び方
ここが本番です。SAA-C03は“現場の要件あるある”に寄せて出してきます。
よくある5パターンを、要件→選定理由で固定化しましょう。
パターンA：業務DB → RDS/Aurora
例：受発注、在庫、会計、顧客管理。
- 要件：参照整合性、トランザクション、複雑な検索、レポート出力
- 判断：SQL/Join/ACIDが主役なので RDS or Aurora
さらに分岐：
- “普通の業務DBで十分、既存運用を踏襲したい” → RDS
- “可用性や性能を強く求める（落とせない、負荷が高い）” → Aurora
試験の言い回し例（拾うべきワード）
「トランザクション」「参照整合性」「複雑なクエリ」「レポート」「既存MySQL」
パターンB：EC/ゲーム/チケット → DynamoDB
例：セール開始、テレビ放送直後、アクセスが読めない。
- 要件：急増に耐える、低遅延、水平スケール、運用最小
- 判断：スパイク＋低遅延＋予測不能は DynamoDBが最短
ここで重要なのは、「RDBでもスケールできる」は試験の罠になりやすい点です。
問題文が“予測不能な急増”を強く押してきたら、最初からスケール前提で設計された選択が正解になりやすいです。
拾うべきワード
「予測不能」「急激に増加」「1桁ms」「水平スケール」「運用を最小化」
パターンC：読み取り爆増 → Aurora
例：記事閲覧、商品一覧、カタログ、プロフィール参照。
- 要件：読み取りが多い、参照中心、応答速度、可用性
- 判断：RDBで読み取りが強いなら Aurora がハマりやすい
ただし、問題によっては「RDSのリードレプリカ」なども選択肢に出ます。
この場合は、本文のニュアンスで見分けます。
- “RDBでOK、読み取りは増えるが段階的” → RDS（リードレプリカ）
- “読み取りが非常に多い、可用性・性能を強めたい” → Aurora
パターンD：移行・互換性・既存資産 → RDSが強い
例：オンプレの商用DB、既存アプリの改修が難しい、短納期移行。
- 要件：互換性、既存ツール、運用手順、移行期間
- 判断：“変えないこと”が要件なら RDS が選ばれやすい
SAA-C03では「理想構成」より「要件を満たす現実解」を選ぶ問題が多いです。
アプリ改修が困難、SQL前提、スキーマ前提が強いなら、DynamoDBに寄せるのは危険です。
パターンE：運用最小・スケール自動 → DynamoDB
例：SREがいない、小規模チーム、運用工数を減らしたい。
- 要件：自動スケール、運用を最小化、障害対応を減らす
- 判断：キーアクセス中心でOKなら DynamoDB が強い
ただし、SQLやJoinが必要なら、いくら運用最小でもRDBを選ぶ必要があります。
このときは「運用最小＝NoSQL」と短絡せず、“SQLが必要か？”で先に分岐してください。
落とし穴（よくある誤選択）＋ 学習ロードマップ
最後に、試験で落ちる“もったいないミス”を潰します。
よくある誤選択トップ5
- “高速そう”だけでDynamoDBを選ぶ
→ SQL/Join/複雑な検索があるならRDBの土俵です。 - Auroraを“とりあえず上位”として選ぶ
→ 要件が普通ならRDSで十分、が正解の問題もあります。 - 移行要件を読み落とす（改修不可・短納期）
→ 現実要件が強いときはRDS寄りになりやすいです。 - 要件の主語を見誤る（読み取り？書き込み？）
→ Read-heavyかWrite-heavyかで判断が変わります。 - “運用最小”を最優先しすぎる
→ 必要なデータモデル（SQL/Join/整合性）を満たせなければ意味がありません。
迷ったときのチェックリスト
次の10項目を上から順に確認すると、ほぼ決着します。
- SQLが必須か？
- Joinが必須か？
- ACIDトランザクションが必須か？
- 参照整合性（外部キー相当）が強く必要か？
- アクセスは予測不能に急増するか？
- 低遅延（1桁ms）を強く求めるか？
- データ構造は柔軟でよいか？（属性追加が多い等）
- 読み取り中心か、書き込み中心か？
- 既存DBからの移行で改修が難しいか？
- 運用体制（バックアップ/パッチ/スケール）に制約があるか？
判定の最短結論：
- 1〜4に「YES」が多い → RDS/Aurora
- 5〜7に「YES」が多い → DynamoDB
- RDS/Auroraで迷う → 可用性・性能・読み取り拡張の要求が強いかでAurora寄り
“選択肢の潰し方”テンプレ
- 問題文から「必須」を抜く（SQL必須、Join必須、急増、低遅延…）
- 必須がRDB側ならDynamoDBを切る / 必須がスパイクならDynamoDBを残す
- 残った2択を「移行・運用・コスト」の文脈で詰める
- 最後に“最小の労力で要件達成できる”を選ぶ（試験の思想）
Udemyでのおすすめ学習
SAA-C03のDB選定は、文章を読んで判断する力が必要なので、ハンズオン＋問題演習の反復が最短です。
特にUdemyは「講義→演習→模試」の導線が作りやすく、スキマ時間でも進めやすいのが強みです。
おすすめの使い方（最短ルート）
- ① まず講義で全体像（RDS/Aurora/DynamoDBの立ち位置）を掴む
- ② ハンズオンで“どこが嬉しいのか”を体感する（作成・接続・スケール感）
- ③ 模試で要件文を読む訓練（キーワード抽出→決定表で判定）
まとめ
SAA-C03の「RDS vs Aurora vs DynamoDB」は、サービス比較の暗記ではなく、要件から逆算して“最短で満たせる選択”を当てる問題です。判断はまず土俵分けから始めましょう。
SQL/Join/ACIDが必須ならRDS/Aurora、予測不能な急増や低遅延・水平スケールが主役ならDynamoDBが有力です。RDSとAuroraで迷ったら、RDBのまま可用性・性能・読み取り拡張を強く求めるかを見てAurora寄りかどうかを詰めます。
最後は、この記事の「要件キーワード決定表」と「10項目チェックリスト」を使えば、選択肢はほぼ自動で絞れます。仕上げはUdemyで、講義→ハンズオン→模試の順に回し、問題文から要件ワードを抜く訓練を積めば、DB選定問題は得点源になります。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
