Amazon RDS とは？マネージドリレーショナル DB の仕組みと特徴
RDS は AWS のマネージド RDB サービス。MySQL / PostgreSQL / Oracle / SQL Server / MariaDB の 5 商用エンジン + Aurora の合計 6 エンジンに対応する。バックアップ・パッチ・冗長化 を AWS が代行...
AWS のフルマネージド リレーショナルデータベース。MySQL / Postgres / Oracle / SQL Server / MariaDB / Aurora 対応。
1. 概要（端的に）
RDS は AWS のマネージド RDB サービス。MySQL / PostgreSQL / Oracle / SQL Server / MariaDB の 5 商用エンジン + Aurora の合計 6 エンジンに対応する。バックアップ・パッチ・冗長化 を AWS が代行し、利用者は SQL とデータに集中できる。Multi-AZ・Read Replica・暗号化を組み合わせて高可用性 DB を構築できる。
2. 何ができるか
- 6 エンジン対応：MySQL / PostgreSQL / MariaDB / Oracle / SQL Server / Aurora
- 自動バックアップ：日次 + トランザクションログ
- PITR：任意の時点への復元（Point-in-Time Recovery）
- Multi-AZ：別 AZ にスタンバイ自動構築
- Read Replica：読み取り用レプリカ
- 暗号化：KMS 統合
- パッチ自動化：メンテナンスウィンドウで自動
- モニタリング：Performance Insights / Enhanced Monitoring
3. 特徴
| 観点 | 特徴 |
|---|---|
| 追加料金 | インスタンス時間 + ストレージ + バックアップ + I/O |
| マネージド範囲 | OS・DB エンジン・パッチ・バックアップは AWS |
| 利用者管理 | スキーマ・データ・パフォーマンスチューニング |
| 最大ストレージ | 64 TB（Aurora は 128 TB 以上） |
| インスタンスタイプ | db.t3 / db.m5 / db.r5 等 |
| マルチエンジン | 1 アカウントで複数エンジン同居可 |
vs Aurora
| 観点 | RDS（標準） | Aurora |
|---|---|---|
| エンジン | 5 商用 + Aurora | MySQL / Postgres 互換 |
| 性能 | 標準 | MySQL の 5 倍、Postgres の 3 倍 |
| 可用性 | Multi-AZ で 99.95% | デフォルトで 99.99% |
| ストレージ | EBS（最大 64 TB） | 専用ストレージ（最大 128 TB） |
| 料金 | 安め | 高め（性能比で安い） |
4. 仕組み
RDS は EC2 + EBS + AWS マネージドソフトウェアで構成される。利用者は DB エンドポイントへの接続のみで、裏のインスタンスは AWS が管理する。
構成要素
- DB インスタンス：DB を実行するサーバー
- DB エンジン：MySQL / PostgreSQL 等
- ストレージ：EBS（gp3 / io1 / io2）
- エンドポイント：接続先 DNS 名
- DB サブネットグループ：複数 AZ のサブネット集合
- パラメータグループ：DB エンジンの設定
- オプショングループ：拡張機能（暗号化等）
動作の流れ
- DB インスタンス作成：エンジン・タイプ・ストレージ・VPC 指定
- エンドポイント取得：
mydb.xxx.region.rds.amazonaws.com - 接続：通常の DB クライアントから
- AWS が管理：バックアップ・パッチ・モニタリング
高可用性パターン
- Single AZ：1 インスタンスのみ（開発用）
- Multi-AZ：2 AZ にプライマリ + スタンバイ（本番標準）
- Multi-AZ + Read Replica：高可用 + 読み取りスケール
バックアップ
- 自動バックアップ：1〜35 日保持
- 手動スナップショット：明示削除まで保持
- PITR：5 分単位での時点復元
5. ユースケース
ユースケース 1：Web サービスの基幹 DB
ユーザー情報・トランザクション。
ユースケース 2：CMS / ECサイト
WordPress / Magento の MySQL バックエンド。
ユースケース 3：分析バックエンド
PostgreSQL の高度なクエリ機能を活用。
ユースケース 4：エンタープライズ
Oracle / SQL Server の既存資産を AWS へ移行。
ユースケース 5：マイクロサービスごとの DB
各サービスに小規模 RDS。
6. 関連用語
- Aurora — AWS 独自の高性能 RDB
- RDS-MultiAZ — 高可用性構成
- RDS-ReadReplica — 読み取り専用レプリカ
- RDS-Proxy — 接続プール
- KMS — 暗号化キー
- AWS-Backup — バックアップ統合管理
7. 関連サイト
AWS 公式
参考
🎓 試験での出題傾向
| 試験 | 重要度 | 主な出題パターン |
|---|---|---|
| CLF | 高 | RDS の基本概念 |
| SAA | 高 | 高可用性設計、Multi-AZ vs Read Replica |
| DVA | 高 | アプリからの接続、RDS Proxy 利用 |
| SOA | 高 | バックアップ・運用・パフォーマンス |
🛠 現場ノート：公式ドキュメントに載っていない実務の勘所
RDS は Multi-AZ と Read Replica の混同が試験・実務の最大の落とし穴。ここを外すと設計問題で必ず間違える。
Multi-AZ と Read Replica は別物（最重要）
| 観点 | Multi-AZ | Read Replica |
|---|---|---|
| 目的 | 可用性（障害時フェイルオーバー） | 性能（読み取り負荷分散） |
| レプリケーション | 同期 | 非同期 |
| スタンバイを読めるか | 読めない（待機専用・Aurora は例外） | 読める |
| 切替 | 自動（DNS エンドポイント切替） | 手動昇格 |
→ 「読み取りが重い」は Read Replica、「落ちたら困る」は Multi-AZ。併用も可能（排他ではない）。
よくあるコスト・運用事故
| やりがちなミス | 何が起きるか | 回避策 |
|---|---|---|
| Multi-AZ で料金が約 2 倍 | スタンバイ分のインスタンス代が乗る | 検証環境では Single-AZ。本番のみ Multi-AZ |
| 停止しても 7 日で自動再起動 | RDS の「停止」は最大 7 日。放置すると勝手に起動し課金 | 長期不要ならスナップショット取得後に削除 |
| 自動バックアップ保持 0 日 | 自動バックアップが無効化され PITR できない | 保持期間を 1 日以上に（0 は無効の意味） |
試験のひっかけ（SAA 頻出）
- 「読み取りスケール」→ Read Replica、「高可用性」→ Multi-AZ（毎回どちらか問われる）
- フェイルオーバーは DNS エンドポイントの向き先切替で実現（IP は変わる前提でアプリは名前解決する）
- さらに性能・可用性を両取りしたい → Aurora（スタンバイも読める・自動スケール）を検討