はじめに
AWS Solutions Architect Associate (SAA) の学習中に整理した Amazon RDS 関連の知識をまとめました。
Multi-AZ と Read Replica の違い、暗号化のルール、DB 移行パターンなど、試験で頻繁に問われるポイントを網羅しています。
本記事は個人の学習ノートをベースにしています。誤りがあればコメントでご指摘いただけると助かります。
サービス概要
対応エンジン
MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Aurora
Multi-AZ vs Read Replica
この2つの違いは SAA で最も問われるポイントの一つです。
| Multi-AZ | Read Replica | |
|---|---|---|
| レプリケーション | 同期 | 非同期 |
| 目的 | 可用性・データ耐久性 | 読み取りスケーリング |
| フェイルオーバー | 自動 | 手動昇格 |
| 読み取り可能 | ❌（スタンバイは読み取り不可） | ✅ |
| 最大数 | 1（スタンバイ） | 5 |
判断のポイントはシンプルです。
- 可用性を高めたい → Multi-AZ
- 読み取り性能を上げたい → Read Replica
- Multi-AZ のスタンバイは読み取りにも使えない（フェイルオーバー専用）
Multi-AZ フェイルオーバー時の動作
- CNAME レコードがスタンバイ DB を指すように自動更新される
- URL / エンドポイントは変わらない（アプリ側の変更は不要）
- 完全自動（手動介入不要）
- フェイルオーバー時間: 通常60〜120秒
IAM DB 認証
- パスワードの代わりに 15分有効な認証トークン を使用
- AWS Signature V4 で生成
- MySQL / PostgreSQL で対応
- Lambda などからの短期認証情報として有効
暗号化
- at-rest（保存時）: KMS 暗号化（DB 作成時のみ設定可能、後から有効化不可）
- in-transit（転送中）: SSL/TLS
既存の未暗号化 RDS を暗号化する方法
暗号化は DB 作成時にしか設定できないため、既存の未暗号化 RDS を暗号化するには以下の手順が必要です。
- 未暗号化 DB のスナップショットを作成
- スナップショットを暗号化付きでコピー
- 暗号化スナップショットから新しい DB を復元
- アプリを新 DB に切り替え、旧 DB を削除
Storage Auto Scaling
- 空き容量 < 10% かつ 5分以上継続 かつ 前回変更から6時間以上で自動拡張
- RDS 自体に備わっている機能（Aurora だけではない）
クロスアカウント共有
- 暗号化スナップショットを共有 + KMS キーのアクセス許可
- スナップショットの S3 は直接アクセス不可（AWS が管理）
DR オプション
- クロスリージョン Read Replica
- クロスリージョン自動バックアップ
- Multi-AZ（同一リージョン内）
- Database Cloning は Aurora のみ（RDS では不可）
RDS の重要ルール
試験の引っかけ選択肢として登場しやすいポイントです。
- クロスリージョン Multi-AZ は存在しない
- Multi-AZ はパフォーマンスではなく可用性のための機能
- Read Replica は書き込み不可 → dev DB としては不適
- Read Replica のレプリケーションラグは秒単位（Aurora Replica は10ミリ秒）
- RDS には SSH できない（マネージドサービス）
Babelfish for Aurora PostgreSQL
- Aurora PostgreSQL で T-SQL コマンドと SQL Server ワイヤプロトコルを理解可能にする機能
- SQL Server → Aurora PostgreSQL の移行でアプリ変更を最小化
試験で問われる設計パターン
SAA の試験では「RDS のどの機能を使うか」「どの移行ツールを選ぶか」といったシナリオが多く出題されます。
DB 移行系
SQL Server → Aurora PostgreSQL 移行（T-SQL 互換）→ Babelfish + SCT/DMS
シナリオ: オンプレミスの SQL Server を Aurora PostgreSQL に移行したいです。既存のアプリケーションは T-SQL を使用しており、アプリ変更は最小限にしたいです。どのサービスを組み合わせるべきでしょうか？（2つ選択）
正解:
- Babelfish for Aurora PostgreSQL
- AWS SCT + AWS DMS
- SCT: スキーマ変換、DMS: データ移行（最小ダウンタイム）
- Glue は ETL ツールであり、SQL 変換ツールではない
異種 DB 移行（複雑なスキーマ）→ SCT + DMS
シナリオ: 異なるデータベースエンジン間でセカンダリインデックス、外部キー、ストアドプロシージャを含む複雑なスキーマの移行が必要です。どのサービスを使うべきでしょうか？
正解: SCT + DMS
- SCT はセカンダリインデックス、外部キー、ストアドプロシージャも変換可能
- Basic Schema Copy はテーブル + PK のみ
- Snowball / Glue は DB 移行ツールではない
オンプレ Oracle → RDS Oracle + CDC + 自動スケール → DMS Serverless
シナリオ: オンプレミスの Oracle データベースを RDS Oracle に移行します。移行中も CDC（Change Data Capture）でデータ同期を維持し、ワークロードに応じて自動スケールさせたいです。どのサービスが適切でしょうか？
正解: AWS DMS Serverless
- DMS Serverless はワークロードに応じて自動スケール
- Full Load + CDC の両方に対応
- Glue はバッチ ETL（リアルタイム CDC に不向き）
- Lambda は高ボリュームのステートフルレプリケーションに不向き
読み取り性能系
RDS 読み取りスループット向上 + コアロジック変更なし → Read Replica
シナリオ: RDS で運用しているアプリケーションの読み取りパフォーマンスを向上させたいです。コアロジックの変更は最小限にしたいです。どの方法が最適でしょうか？
正解: RDS Read Replicas
- 「コアロジック変更最小」→ Read Replica（エンドポイント変更のみ）
- ElastiCache はキャッシュロジックの実装が必要
- DynamoDB は NoSQL 移行でクエリの書き換えが必要
レポート生成で本番 DB が遅い → Read Replica にレポートツールを接続
シナリオ: 本番 RDS でレポートを生成するとパフォーマンスが低下します。CPU / メモリ / ストレージの使用率は50%程度です。インスタンスサイズの増加は効果がないと考えられます。どうすべきでしょうか？
正解: Read Replica を作成し、レポートツールを Read Replica に接続
- リソース使用率が低い → サイズ増は効果なし（読み取り負荷の分離が必要）
- Multi-AZ スタンバイは読み取りトラフィックを処理できない
RDS 読み取り負荷分散 + レポートクエリ → Read Replica（同一スペック）
シナリオ: 本番 RDS の読み取り負荷を分散するため、レポートクエリを Read Replica に向けたいです。Read Replica のスペックはどうすべきでしょうか？
正解: プライマリと同じスペックの Read Replica を作成し、レポートクエリを向ける
- 半分のスペックだとレプリケーション遅延が発生する
- Standby は読み取りトラフィックを処理できない（フェイルオーバー専用）
可用性・DR 系
SQL Server 最大可用性 + 運用負荷最小 → RDS for SQL Server Multi-AZ
シナリオ: SQL Server の可用性を最大限に高めたいです。運用負荷は最小限にしたいです。どの構成が最適でしょうか？
正解: RDS for SQL Server（Multi-AZ）
- クロスリージョン Multi-AZ は存在しない
- Read Replica は読み取りスケーリング用（可用性向上ではない）
RDS PostgreSQL の DR → クロスリージョン Read Replica + 自動バックアップ
シナリオ: RDS PostgreSQL の DR（災害復旧）策を検討しています。どの機能を組み合わせるべきでしょうか？（2つ選択）
正解:
- クロスリージョン Read Replica
- Multi-AZ の自動バックアップ（クロスリージョン）
- Provisioned IOPS は DR 機能ではない
- Database Cloning は Aurora のみ（RDS では不可）
Multi-AZ フェイルオーバー時の動作
シナリオ: RDS Multi-AZ 構成でプライマリ DB に障害が発生した場合、フェイルオーバーはどのように動作しますか？
正解: CNAME レコードがスタンバイ DB を指すように自動更新される
- URL / エンドポイントは変わらない（アプリ変更不要）
- 完全自動（手動介入不要）
- 60〜120秒で切り替え
データ損失最小 + 2ノードにトランザクション保存 → RDS Multi-AZ
シナリオ: データ損失を最小限にするため、すべてのトランザクションが2つのノードに保存されるようにしたいです。どの構成が適切でしょうか？
正解: RDS MySQL Multi-AZ（同期レプリケーション）
- Read Replica は常に非同期（「同期 Read Replica」という選択肢は矛盾 → 不正解）
- Multi-AZ = 同期レプリケーション
本番 DB コピーの負荷軽減 → Aurora 自動バックアップから dev DB を復元
シナリオ: 開発用データベースを本番のコピーから作成したいですが、本番 DB に負荷をかけたくないです。どの方法が最適でしょうか？
正解: Aurora + 自動バックアップから dev DB を復元
- mysqldump は本番に負荷をかける
- Multi-AZ スタンバイは読み取り不可
- Read Replica は書き込み不可（dev DB として不適）
セキュリティ系
RDS 接続タイムアウト → SG にインバウンドルールがない
シナリオ: アプリケーションから RDS に接続しようとすると「connection timed out」エラーが発生します。原因として最も考えられるのはどれでしょうか？
正解: RDS インスタンスの SG にアプリサーバーからのインバウンドを許可していない
- 「connection timed out」= ネットワーク / SG の問題
- 「access denied」= 認証の問題
- RDS には SSH できない
RDS データ転送中の暗号化 → SSL/TLS
シナリオ: RDS のデータを転送中（in-transit）に暗号化したいです。どの方法を使うべきでしょうか？
正解: RDS で SSL/TLS を設定
- at-rest = KMS、in-transit = SSL/TLS
- RDS には SSH できない（SSH 関連の選択肢はダミー）
- IAM 認証は認証方式であり、暗号化の仕組みではない
Lambda → RDS の短期認証情報 → IAM DB 認証
シナリオ: Lambda から RDS PostgreSQL に接続する際、長期的なパスワードではなく短期の認証情報を使いたいです。どの方法が適切でしょうか？（2つ選択）
正解:
- IAM DB 認証
- Lambda に IAM ロールをアタッチ
- IAM DB 認証は15分有効なトークンを使用
- SG / VPC はネットワーク層の対策（認証層ではない）
RDS クロスアカウント共有 → 暗号化スナップショット + KMS キー共有
シナリオ: RDS のデータベースを別の AWS アカウントと共有したいです。データは暗号化されています。どのように共有すべきでしょうか？
正解: 暗号化スナップショット作成 → 共有 → KMS 暗号化キーのアクセスを許可
- スナップショットの S3 は直接アクセス不可
- Read Replica は「コピー」ではなく「レプリカ」
既存の未暗号化 RDS を暗号化
シナリオ: 既存の未暗号化 RDS データベースを暗号化する必要があります。どの手順が正しいでしょうか？
正解: スナップショット → 暗号化コピー → 暗号化スナップショットから復元 → 旧 DB 削除
- 暗号化は DB 作成時のみ設定可能（後からは有効化できない）
- コンソールから暗号化を有効化するオプションは存在しない
SQL Server 移行 + セキュリティ + 運用負荷最小 → RDS Multi-AZ + KMS
シナリオ: オンプレミスの SQL Server を AWS に移行します。データの暗号化が必要で、運用負荷を最小限にしたいです。どの構成が最適でしょうか？
正解: RDS for SQL Server（Multi-AZ）+ KMS
- EC2 + 暗号化 EBS は自己管理で運用負荷が大きい
- CSV → S3 はリレーショナル DB の機能を失う
その他
RDS ストレージ不足 + 最小工数 → Storage Auto Scaling
シナリオ: RDS のストレージ容量が不足し始めています。最も少ない工数で対応するにはどうすればよいでしょうか？
正解: Storage Auto Scaling を有効化
- RDS 自体に Auto Scaling 機能がある（Aurora だけではない）
- Aurora / DynamoDB への移行は工数が大きい
レプリケーションラグ削減 → RDS MySQL → Aurora MySQL 移行
シナリオ: RDS MySQL の Read Replica でレプリケーションラグが問題になっています。ラグを大幅に削減するにはどうすべきでしょうか？
正解: Aurora MySQL + Aurora Replicas + Auto Scaling
- Aurora Replica = 10ミリ秒台（共有ストレージにより高速）
- RDS MySQL Read Replica = 秒単位の非同期レプリケーション
- MySQL 互換なのでアプリ変更は最小限
RDS Read Replica のデータ転送料金
シナリオ: Read Replica を作成する場合、データ転送料金はどうなりますか？
- 同一リージョン内: 無料
- クロスリージョン: 有料
おわりに
RDS は SAA の中でも出題頻度が高く、特に「Multi-AZ vs Read Replica」の使い分けは必ず押さえておくべきポイントです。「可用性なら Multi-AZ」「読み取り性能なら Read Replica」「スタンバイは読み取り不可」「クロスリージョン Multi-AZ は存在しない」という4つのルールを覚えておけば、大半の問題に対応できます。
間違いや補足があればぜひコメントで教えてください。