AWS SAA-C03 RDS vs Aurora vs DynamoDB｜SAA-C03で迷わない“要件逆算”の選び方

試験は“要件→サービス”の逆算で解ける

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は「講義→演習→模試」の導線が作りやすく、スキマ時間でも進めやすいのが強みです。

まとめ

SAA-C03の「RDS vs Aurora vs DynamoDB」は、サービス比較の暗記ではなく、要件から逆算して“最短で満たせる選択”を当てる問題です。判断はまず土俵分けから始めましょう。

SQL/Join/ACIDが必須ならRDS/Aurora、予測不能な急増や低遅延・水平スケールが主役ならDynamoDBが有力です。RDSとAuroraで迷ったら、RDBのまま可用性・性能・読み取り拡張を強く求めるかを見てAurora寄りかどうかを詰めます。

最後は、この記事の「要件キーワード決定表」と「10項目チェックリスト」を使えば、選択肢はほぼ自動で絞れます。仕上げはUdemyで、講義→ハンズオン→模試の順に回し、問題文から要件ワードを抜く訓練を積めば、DB選定問題は得点源になります。

SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇

SAA-C03対策｜Udemyのおすすめ講座を見る