SAA：RDS と Aurora の使い分け問題対策｜Multi-AZ・リードレプリカ・Serverless・Global Database を要件文で即断する
AWS SAA-C03 で「RDS と Aurora のどちらを選ぶか」は頻出テーマ。本記事は RDS と Aurora の使い分けを「エンジン要件（Oracle/SQL Server の有無）／可用性（Multi-AZ とフェイルオーバー）／読み取りスケール（リードレプリカ）／自動スケールとコスト（Aurora Serverless）／地理分散（Aurora Global Database）」の評価軸に分解し、要件文のどのキーワードが正解を一意に決めるかを示す。Multi-AZ とリードレプリカの違い、Aurora の6コピー3AZストレージ、Serverless v2 のスケール、Global Database の1秒未満レプリケーションまで、SAA 本番でそのまま選択肢を絞れる粒度で整理する。結論は「RDS/Aurora 問題はエンジン制約・可用性・読み取りスケール・地理分散の4軸で解く」こと。
リレーショナルデータベースの設問を「RDBだから RDS」で片づけようとすると、エンジン制約・可用性・読み取りスケール・地理分散で足をすくわれる。 SAA-C03 で Amazon RDS と Amazon Aurora は、データ層の設計を問う最重要サービスだ。だが問われるのは「マネージド RDB の一般論」ではなく、どのエンジンが要るのか・どこまでの可用性が要るのか・読み取り負荷をどう捌くのか・複数リージョンにどう広げるのかという設計判断である。攻略の鍵は、頻出テーマを「エンジン要件」「可用性（Multi-AZ）」「読み取りスケール（リードレプリカ）」「自動スケールとコスト（Serverless）」「地理分散（Global Database）」の評価軸に畳み、要件文のキーワードから正解を一意に引く反射を作ること。本記事では、SAA 本番でそのまま選択肢を絞れる粒度で、RDS と Aurora の使い分け問題を分解する。読み終えれば、「要件を満たす最もマネージドで適切なデータベース構成はどれか」という問いに、迷わず正解を当てられるようになる。
※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます
📑 目次
- 結論：RDS/Aurora 問題は「4つの評価軸」で解く
- 軸1：エンジン要件で RDS か Aurora かを決める
- 軸2：可用性（Multi-AZ とフェイルオーバー）
- 軸3：読み取りスケール（リードレプリカ）
- 軸4：自動スケール・コスト・地理分散（Serverless / Global Database）
- 頻出ひっかけパターンと打ち手の整理
- 次のアクション チェックリスト
- 関連記事
- 関連サイト
1. 結論：RDS/Aurora 問題は「4つの評価軸」で解く
SAA-C03 の RDS/Aurora 問題を最短で解く骨格は、**「要件文が4つの評価軸——エンジン要件・可用性・読み取りスケール・地理分散——のどれを問うているかを特定し、その軸で選択肢を振るう」**ことだ。これが本記事の結論である。
理由は明快で、RDS と Aurora の各機能はどれも「ある評価軸を制御するための道具」だからだ。対応エンジンは「Oracle/SQL Server が要るか」を、Multi-AZ 配置は「可用性と自動フェイルオーバー」を、リードレプリカは「読み取り負荷分散」を、Aurora Serverless と Global Database は「コスト最適化と地理分散」を担う。つまり要件文のキーワードが軸を指し示し、軸が正解の機能を一意に決める構造になっている。
具体例で見よう。「Oracle を使い続けたい」——これはエンジンの軸だから RDS for Oracle を選ぶ。「単一障害点をなくし自動でフェイルオーバーさせたい」——可用性の軸だから Multi-AZ。「読み取りが急増しレポート処理を分離したい」——スケールの軸だから リードレプリカ。「複数リージョンで低遅延に読み、リージョン障害からも数分で復旧したい」——地理分散の軸だから Aurora Global Database。ここで「Aurora は高性能だから常に Aurora」と考えると、Oracle 要件やコスト重視の設問で誤答する。軸で解く——この一点が RDS/Aurora 問題の攻略法だ。
2. 軸1：エンジン要件で RDS か Aurora かを決める
最初に振るうべきはエンジンの軸だ。Aurora は MySQL 互換・PostgreSQL 互換の2エンジンのみ。Oracle・SQL Server・MariaDB・Db2 が要件に出たら、その瞬間に答えは RDS に決まる（Aurora はこれらをサポートしない）。逆に「MySQL/PostgreSQL 互換で、より高いスループットと自動スケールするストレージが欲しい」なら Aurora が第一候補になる。
| 評価項目 | Amazon RDS | Amazon Aurora 推奨 |
|---|---|---|
| 対応エンジン | MySQL/PostgreSQL/MariaDB/Oracle/SQL Server/Db2 | MySQL 互換・PostgreSQL 互換のみ |
| ストレージ | EBS ベース（事前割当・上限管理） | 専用分散ストレージ（自動拡張・最大128TB超） |
| 性能 | エンジン標準の性能 | 最大 MySQL の5倍・PostgreSQL の3倍 |
| 可用性 | Multi-AZ で単一スタンバイ | 6コピーを3AZに分散・高速フェイルオーバー |
| 向くケース | Oracle/SQL Server 継続・小規模で低コスト | 高トラフィック・自動スケール・地理分散 |
| キーワード | 「Oracle」「SQL Server」「最小コスト」 | 「高性能」「自動拡張」「マルチリージョン」 |
Aurora の技術的な強みはストレージアーキテクチャにある。データは 10GB のチャンク単位で 3つのアベイラビリティゾーンに合計6コピー保存され、ストレージは使用量に応じて自動で拡張される。RDS のように事前にボリュームサイズを見積もって割り当てる必要がない。これが「ストレージ容量の管理をなくしたい」「予測しづらいデータ増加に備えたい」という要件で Aurora が選ばれる理由だ。
3. 軸2：可用性（Multi-AZ とフェイルオーバー）
次の軸は可用性だ。SAA で最頻出のひっかけが「Multi-AZ とリードレプリカの混同」である。この2つは目的がまったく異なる。
Multi-AZ 配置は高可用性（HA）と自動フェイルオーバーのための機能だ。別の AZ に同期レプリケーションされたスタンバイを持ち、プライマリ障害時に自動でフェイルオーバーする。スタンバイは通常読み取りには使えない（RDS の従来型 Multi-AZ の場合）。キーワードは「単一障害点の排除」「自動フェイルオーバー」「災害対策（AZ 障害）」だ。
Aurora の可用性はさらに強力で、6コピー3AZのストレージによりほぼダウンタイムなしでフェイルオーバーする。RDS の従来型 Multi-AZ がフェイルオーバーに1分以上かかることがあるのに対し、Aurora は数十秒以内に切り替わる。「フェイルオーバー時間を最小化したい」という要件は Aurora レプリカへの昇格が正解になりやすい。
| 評価項目 | Multi-AZ 配置 推奨 | リードレプリカ |
|---|---|---|
| 主目的 | 高可用性・自動フェイルオーバー | 読み取り負荷分散・スケール |
| レプリケーション | 同期（データ損失なし） | 非同期（わずかな遅延あり） |
| 読み取り利用 | 原則不可（スタンバイは待機） | 可能（読み取り専用エンドポイント） |
| 対応リージョン | 同一リージョン内の別AZ | 同一/別AZ・クロスリージョン可 |
| キーワード | 「フェイルオーバー」「AZ障害対策」 | 「読み取り急増」「レポート分離」 |
4. 軸3：読み取りスケール（リードレプリカ）
3つめの軸は読み取りスケールだ。「読み取りトラフィックが急増する」「分析・レポート処理を本番から分離したい」——これはリードレプリカの設問である。リードレプリカは非同期レプリケーションで複製され、読み取り専用として負荷を分散する。
RDS のリードレプリカは最大5〜15個（エンジンにより異なる）、Aurora レプリカは最大15個まで作成でき、Aurora の場合は共有ストレージを参照するためレプリケーション遅延が非常に小さい。クロスリージョンリードレプリカを使えば、地理的に離れたユーザーの読み取りレイテンシを下げつつ、DR のセカンダリとしても活用できる。
5. 軸4：自動スケール・コスト・地理分散（Serverless / Global Database）
最後の軸は自動スケール／コスト／地理分散だ。ここは Aurora の上位機能で差がつく。
Aurora Serverless v2 は、負荷に応じて容量（ACU）を自動で細かくスケールする構成だ。「トラフィックが読めない」「開発・検証環境で使わない時間はコストを抑えたい」「断続的なワークロード」がキーワードになる。逆に安定して高負荷が続く本番では、プロビジョンド（固定インスタンス）＋リザーブドの方が割安になることが多く、そこで Serverless を選ぶと誤答だ。
Aurora Global Database は、1つのプライマリリージョンと最大5つのセカンダリリージョンを、通常1秒未満のレプリケーション遅延で結ぶ。マルチリージョンでの低遅延読み取りと、リージョン障害からの高速な災害復旧（RTO/RPO の最小化）を両立する。「複数リージョンのユーザーに低遅延で読ませたい」「リージョン全体の障害に備えたい」という要件は Global Database が正解になる。
6. 頻出ひっかけパターンと打ち手の整理
SAA 本番で RDS/Aurora が絡む設問のひっかけは、ほぼ次の5パターンに収束する。要件キーワードから軸を特定すれば、いずれも反射で外せる。
- 可用性 vs 読み取りスケールのすり替え：「フェイルオーバー」なのにリードレプリカを、「読み取り急増」なのに Multi-AZ を選ばせようとする。目的（落とさない／読ませる）で振るう。
- 非対応エンジンの罠：Oracle/SQL Server 要件に Aurora を混ぜてくる。エンジン名で即除外。
- コストの読み違い：安定高負荷に Serverless、断続負荷にプロビジョンドを選ばせる。負荷パターンで振るう。
- マルチリージョンの自作：クロスリージョンの低遅延・DR を、手動のリードレプリカやスナップショットコピーで解かせる。Global Database の1秒未満複製を思い出す。
- 接続枯渇の見落とし：Lambda 大量接続の枯渇にスケールアップで対処させる。RDS Proxy を思い出す。
7. 次のアクション チェックリスト
- 要件文に Oracle/SQL Server/MariaDB/Db2 が出たら Aurora を即除外し RDS を選ぶ
- 「フェイルオーバー」「単一障害点」「AZ障害」 は Multi-AZ（同期・原則読めない）
- 「読み取り急増」「レポート分離」 はリードレプリカ（非同期・読み取り専用）
- 「断続的」「予測不能」「使わない時間は節約」 は Aurora Serverless v2
- 「複数リージョン低遅延」「リージョンDR」 は Aurora Global Database（1秒未満複製）
- Lambda 大量接続で枯渇 は RDS Proxy（接続プール）
- DynamoDB の頻出パターンと合わせ「RDB か NoSQL か」の上位分岐も反射化する
8. 関連記事
- SAA 試験完全ガイド｜SAA-C03 の出題範囲・難易度・3ヶ月合格戦略 — 本シリーズの上位ガイド
- SAA 試験範囲：4ドメイン詳細解説 — ドメイン1〜4の全体像
- SAA ドメイン2：弾力性のあるアーキテクチャの設計 — Multi-AZ・DR の上位
- SAA ドメイン3：高パフォーマンスアーキテクチャの設計 — リードレプリカ・Aurora 性能の上位
- SAA ドメイン4：コスト最適化アーキテクチャの設計 — Serverless・インスタンス選定の上位
- SAA DynamoDB 設計問題の頻出パターン10選 — 隣接する頻出テーマ（RDB vs NoSQL）
- Amazon RDS とは？マネージド RDB の仕組みと料金 — RDS の基礎
- Amazon Aurora とは？クラウドネイティブ RDB の仕組み — Aurora の基礎
- RDS Multi-AZ 配置の仕組みと自動フェイルオーバー — 可用性の詳細
- RDS リードレプリカの仕組みと読み取りスケール — 読み取りスケールの詳細
- RDS Proxy とは？接続プールでコネクション枯渇を防ぐ — 接続管理の詳細
- Aurora Global Database の仕組みとマルチリージョン設計 — 地理分散の詳細
- Aurora Serverless とは？自動スケールする RDB — コスト最適化の詳細
9. 関連サイト
AWS 公式
- Amazon Aurora と Amazon RDS の違い（公式比較）
- Amazon RDS（サービス紹介・公式）
- Amazon Aurora（サービス紹介・公式）
- RDS のマルチ AZ 配置（公式ユーザーガイド）
- RDS リードレプリカの使用（公式ユーザーガイド）
- Amazon Aurora の概要（公式ユーザーガイド）
- AWS Certified Solutions Architect – Associate（公式）
- SAA-C03 試験ガイド（公式 PDF）