RDS

1. サービス概要¶

Amazon RDS（Relational Database Service）は、AWS が提供するフルマネージドなリレーショナルデータベースサービスである。
MySQL、PostgreSQL、MariaDB、Oracle、Microsoft SQL Server、Amazon Aurora など、複数のデータベースエンジンを選択でき、データベースのセットアップ・管理・スケーリングを簡素化する。

主なユースケースとして、

Web アプリケーションのメインデータベース
社内システムのリフト＆シフト（オンプレからの移行）
開発/テスト環境

などが挙げられる。
インフラ管理を AWS に任せることで、開発チームはアプリケーションロジックに集中できる。

2. 主な特徴と機能¶

2.1 マネージドで簡易的な運用¶

RDS は OS や DB ソフトウェアのインストール、パッチ適用、バックアップ、自動フェイルオーバーなどを AWS が自動化して管理する。
手動でのアップデート作業や冗長化構成の構築が不要になるため、運用負荷を大幅に削減できる。

2.2 バックアップとリカバリ¶

スナップショットおよびポイントインタイムリカバリをサポートし、バックアップウィンドウを自動スケジュールできる。
自動スナップショットの保持期間を設定し、過去の任意時点までデータベースを巻き戻せるため、障害時のリカバリが容易である。

2.3 マルチ AZ 配置とレプリケーション¶

マルチ AZ オプションを有効にすると、プライマリ DB の変更が同期的に別 AZ のスタンバイ DB へレプリケーションされ、障害時には自動的にスタンバイが昇格してフェイルオーバーする。
また、リードレプリカを作成し、読み込み負荷を分散する構成も可能である（エンジンによって異なる）。

2.4 スケーラビリティ¶

需要の増減に合わせて、DB インスタンスタイプやストレージ容量を変更できる。
手動スケールアップ/ダウンはコンソールや CLI から行い、自動ストレージスケーリング機能をサポートするエンジン（Aurora など）も存在する。

2.5 多彩なエンジンサポート¶

RDS は多様な RDB エンジンを提供し、既存の SQL 知識やツールを活かした移行が容易である。
例: MySQL、MariaDB、PostgreSQL、Oracle Database、SQL Server、Aurora など。

3. アーキテクチャおよび技術要素¶

RDS インスタンス（プライマリ）を作成し、VPC やセキュリティグループを設定
マルチ AZ オプションを有効にすると、スタンバイインスタンスが自動作成される
読み取り性能の拡張が必要な場合、リードレプリカを追加（MySQL、PostgreSQL 等対応エンジン）
自動バックアップやスナップショットが定期的に取得され、障害時には Point-in-Time リカバリ
フェイルオーバーやメンテナンスは AWS によってマネージドされる

このように、オンプレミスで必要だった多くの運用作業（ハードウェア調達、OS 管理、ソフトウェアパッチ等）を AWS に任せつつ、高可用性とスケーラブルな RDB を利用できる。

4. セキュリティと認証・認可¶

RDS では以下のセキュリティモデルを利用できる:

VPC 内配置: インスタンスをプライベートサブネットで保護し、セキュリティグループで通信を制御
暗号化: KMS を利用した暗号化をオプションとして有効化し、スナップショットやバックアップも含めた保護
AWS IAM 連携: IAM Database Authentication（MySQL、PostgreSQL 対応）で IAM ユーザーを DB 認証に利用可能
ログ監査: エンジンごとのエラーログ、スロークエリログなどを CloudWatch Logs に転送し、監査しやすくする

5. 料金形態¶

RDS の料金は以下に基づく:

インスタンスタイプ: 選択する CPU/メモリ性能と稼働時間の従量課金
ストレージ: プロビジョンド IOPS、汎用 SSD などのタイプと容量に応じた課金
IOPS: 高速ストレージモードを選択時、指定した IOPS に応じて追加コスト
データ転送料: リージョン外への転送やクロスリージョンレプリカで発生する通信料金

6. よくあるアーキテクチャ・設計パターン¶

RDS を活用するアーキテクチャ上のパターンは下記の通りである:

マルチ AZ で高可用性: プライマリ＆スタンバイ構成でフェイルオーバー対応
リードレプリカで読み込み分散: 運用報告ダッシュボードや分析クエリをレプリカへ振り分け
サーバーレスアプリ: Lambda や API Gateway から RDS へ直接接続（VPC 内）し、小規模アプリを構築
オンプレとのハイブリッド: Direct Connect や VPN を使い、オンプレシステムの DB を RDS へ移行またはレプリケーション

7. 設定・デプロイ手順（ハンズオン例）¶

AWS コンソールで「RDS」を開き、「データベースの作成」をクリック
データベースエンジンを選択（例: MySQL、PostgreSQL など）、テンプレート（Dev/Test、Production）を指定
インスタンスタイプやストレージサイズを選択し、マルチ AZ オプションを ON にするか決める
VPC、サブネットグループ、セキュリティグループを設定し、パブリックアクセスの可否を指定
DB インスタンス識別子、マスターユーザー名/パスワードを入力して「作成」
作成後、エンドポイントが発行されるのでクライアントやアプリケーションから接続テスト

8. 試験で問われやすいポイント¶

8.1 マルチ AZ とリードレプリカの違い¶

マルチ AZ: 同期的にスタンバイへレプリケーションし、障害時のフェイルオーバーを提供
リードレプリカ: 非同期的にレプリケーションし、読み取り負荷を分散。障害時の自動昇格はエンジンによって異なる

8.2 セキュリティグループとネットワーク構成¶

VPC 内: パブリックアクセスをオフにすると安全性向上
セキュリティグループ: アプリサーバのみが DB ポートにアクセスできるよう制限
IAM DB 認証: 各ユーザー固有の IAM 認証で、DB ユーザー管理を簡素化

8.3 バックアップとリストア¶

自動バックアップウィンドウ: 指定時間にスナップショットを取得
Point-in-Time リカバリ: 障害発生時に過去の任意時点へロールバック
手動スナップショット: 特定の状態を保持するためのスナップショット

8.4 スケーリングと性能調整¶

インスタンスタイプ変更: CPU/メモリ性能をアップダウン
ストレージ増加: スナップショット無しで拡張が可能（エンジンによるが拡張が容易）
パラメータグループ: DB 固有の設定（例: max_connections など）を一括管理

8.5 料金とコスト最適化¶

リザーブドインスタンス: 長期利用なら 1 ～ 3 年の予約でコスト削減
Auto Scaling Storage: Aurora など一部エンジンでは容量を自動調整し、過剰プロビジョニングを防ぐ
リードレプリカ最適化: 不要なレプリカを作りすぎないように管理

8.6 試験で頻出となる具体的な問われ方と答え¶

Q: RDS で高可用性を実現するには？
A: マルチ AZ 配置を有効にして、プライマリ障害時にはスタンバイへ自動フェイルオーバー。
Q: 読み取り負荷を分散したい場合は？
A: リードレプリカを作成し、アプリ側で読み込みトラフィックを分散。
Q: バックアップで過去に戻すには？
A: ポイントインタイムリカバリ（PITR）を使い、指定日時の状態に復元。
Q: パブリックアクセスを有効にするリスクは？
A: インターネットから直接 DB にアクセス可能になるため、基本的には安全な VPC 内運用を推奨。
Q: MySQL/PostgreSQL で IAM Database Authentication を使うメリットは？
A: DB ユーザー管理を IAM で一元管理でき、パスワードローテーションも容易。