RDS — マネージド DB, バックアップ, パラメータグループ

第10章 S3 がオブジェクト領域だったなら、本章はリレーショナル DB の番です。AWS のリレーショナル DB マネージドサービスは RDS (Relational Database Service) です。PostgreSQL / MySQL / MariaDB / Oracle / SQL Server / Aurora を1つのコンソールで立ち上げて運用できます。

本章では RDS のマネージドモデルから始め、自動バックアップと PITR、Multi-AZ と Read Replica、パラメータ / オプショングループ、アップグレードまで順に整理します。RDS が住む Private サブネットは 第8章 EC2 と VPC の基礎 のサブネット設計の上に置かれ、パスワード管理は 第20章 Secrets Manager と Parameter Store、バックアップと復元の全体像は 第30章 災害復旧・バックアップ へつながります。

EC2 上の DB vs RDS #

初めてクラウドに出会うと、みんな一度はためらいます。「EC2 を1台立ち上げて PostgreSQL を直接入れるか、RDS へ行くか?」

運用システムではほぼ RDS が答えです。EC2 上の DB は、拡張が RDS で未サポートだったり OS レベルのチューニングが必要な特殊な場合にだけ使います。

エンジンの選択 #

RDS がサポートするエンジンは次のとおりです。

PostgreSQL  ── 新規プロジェクトの第一候補。JSONB / 拡張が豊富
MySQL       ── 最も一般的な選択。互換性重視
MariaDB     ── MySQL フォーク。ほぼ MySQL と同じ
Oracle      ── ライセンスの高いエンタープライズ
SQL Server  ── マイクロソフトのエコシステム
Aurora      ── AWS 製エンジン。PostgreSQL / MySQL 互換

Aurora の特徴 #

Aurora は AWS が作ったクラウドネイティブ DB です。PostgreSQL / MySQL のワイヤ互換なので、コード変更ほぼなしで移せます。

運用規模と可用性が重要なら Aurora、費用と単純さが重要なら RDS PostgreSQL です。

Aurora Serverless v2 は使用量ベースで自動スケールする RDS です。トラフィックがばらつく場合に魅力的で、コールドスタートがほとんどありません(v1 の短所が解決されました)。

RDS インスタンスを立ち上げる #

aws rds create-db-instance \
  --db-instance-identifier my-postgres \
  --db-instance-class db.t3.micro \
  --engine postgres \
  --engine-version 16.4 \
  --master-username postgres \
  --master-user-password "very-strong-password" \
  --allocated-storage 20 \
  --storage-type gp3 \
  --vpc-security-group-ids sg-0abc... \
  --db-subnet-group-name my-db-subnet-group \
  --backup-retention-period 7 \
  --multi-az \
  --no-publicly-accessible

よく触るオプションは次のとおりです。

DB Subnet Group #

RDS は Multi-AZ 構成に置くサブネットをあらかじめ指定しなければなりません。それが DB Subnet Group です。通常は Private サブネットを2 AZ 以上で置きます。

aws rds create-db-subnet-group \
  --db-subnet-group-name my-db-subnet-group \
  --db-subnet-group-description "DB private subnets" \
  --subnet-ids subnet-0a1... subnet-0b2... subnet-0c3...

DB が住む場所は Private サブネット(第8章 VPC)で、インターネットに直接露出しません。アプリサーバー SG だけを SG 単位で入ってこられるように許可します。

自動バックアップ — マネージドの核心価値 #

RDS の本当の価値はバックアップです。

Automated Backup #

backup-retention-period が 0 より大きければ自動バックアップが ON になります。

• 毎日1回、全体バックアップがバックアップウィンドウの時間に行われます。
• トランザクションログが5分ごとに保存されます。
• 保存期間(1 ~ 35 日)の間、保管されます。
• DB 削除時に自動バックアップも一緒に削除されます(SkipFinalSnapshot=false で防げます)。

Point-in-Time Recovery (PITR) #

自動バックアップが ON の RDS は、保存期間内の任意の時点に復元できます。トランザクションログの5分単位の精度です。

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier my-postgres \
  --target-db-instance-identifier my-postgres-restored \
  --restore-time 2026-05-24T08:30:00Z

復元は新しいインスタンスを作る形です。元のものはそのまま残します。「今日の未明3時27分直前の状態が必要だ」が可能です。

Manual Snapshot #

自動バックアップとは別に、ユーザーが明示的に作るバックアップです。DB を削除しても消えず、保存期限もありません。

aws rds create-db-snapshot \
  --db-instance-identifier my-postgres \
  --db-snapshot-identifier my-postgres-2026-05-24-prerelease

運用で手動スナップショットを使う場合は次のとおりです。

• メジャーアップグレード直前。
• 大きなマイグレーション直前。
• DB 削除時の final snapshot。
• 別のリージョン / アカウントへコピー(DR 構成)。

Multi-AZ — 高可用性 #

--multi-az オプションを ON にすると、RDS が Standby インスタンスを別の AZ に自動複製します。

   ┌──────────────────────────────────┐
   │           VPC                    │
   │                                  │
   │    AZ a              AZ b        │
   │    ┌──────┐          ┌──────┐    │
   │    │ Pri  │ ◀══════▶ │Stand │    │
   │    │mary  │  複製(同期) │ by   │    │
   │    └──────┘          └──────┘    │
   │       ▲                          │
   │       │ DNS endpoint             │
   │       │ (自動フェイルオーバー)              │
   └───────┼──────────────────────────┘
           │
       アプリサーバー

• 同期複製 — Standby も毎トランザクションの commit まで受け取っておきます。
• 障害時に自動フェイルオーバー — 30秒 ~ 2分以内に Standby が Primary になり、DNS endpoint がそちらを指します。
• 読み取り分散はできない — Standby は読み取りにも使われません(Aurora と違う点です)。

Multi-AZ の費用 #

二重化の代償はインスタンス / ストレージ費用の2倍です。学習やサイドプロジェクトは単一 AZ、運用は Multi-AZ です。

Multi-AZ Cluster (オプション) #

PostgreSQL / MySQL に新しく出た Multi-AZ DB Cluster は standby が読み取り可能で、フェイルオーバー時間も35秒以下です。ただし AZ を3つ使います(インスタンス3つの費用)。

Read Replica — 読み取り分散 #

Read Replica は非同期複製で作られる読み取り専用の複製です。読み取りトラフィックの多い場所に負荷を分散します。

aws rds create-db-instance-read-replica \
  --db-instance-identifier my-postgres-read-1 \
  --source-db-instance-identifier my-postgres \
  --availability-zone ap-northeast-2c

特徴は次のとおりです。

• 非同期複製 — 若干の遅延があります(通常 ms ~ 秒)。
• 別のリージョンにも可能 — グローバル読み取り分散 / DR に使います。
• 最大5個 — Aurora は15個です。
• Promote で別のインスタンスに分離できます。

Read Replica の適合度 #

読み取りトラフィックが多くなければ、Read Replica より Multi-AZ Cluster のほうが単純です。

パラメータグループとオプショングループ #

DB エンジンの設定(max_connections、shared_buffers のような)を、RDS では パラメータグループ で管理します。

Parameter Group #

aws rds create-db-parameter-group \
  --db-parameter-group-name my-postgres-16-params \
  --db-parameter-group-family postgres16 \
  --description "Custom params for my workload"

aws rds modify-db-parameter-group \
  --db-parameter-group-name my-postgres-16-params \
  --parameters \
    "ParameterName=max_connections,ParameterValue=200,ApplyMethod=pending-reboot" \
    "ParameterName=log_statement,ParameterValue=ddl,ApplyMethod=immediate"

パラメータは2種類です。

• Static — DB 再起動後に適用されます(max_connections など)。
• Dynamic — 即時に適用されます(log_statement など)。

よく触るパラメータは次のとおりです。

Option Group #

エンジン別の追加機能(例: SQL Server の SSIS、Oracle の OEM)を ON にする役割です。PostgreSQL / MySQL はほぼ触りません。

アップグレード — 運用の流れ #

RDS はエンジンバージョンのアップグレードを2種類に分けます。

Minor Upgrade — 安全 #

16.3 → 16.4 のようなマイナーアップグレードです。通常はセキュリティパッチと小さな改善です。自動適用オプションを ON にすると、バックアップウィンドウに自動で行われます。

aws rds modify-db-instance \
  --db-instance-identifier my-postgres \
  --auto-minor-version-upgrade \
  --apply-immediately

ダウンタイムは30秒 ~ 5分です。Multi-AZ ならより短いです(Standby を先にアップグレードした後フェイルオーバー、その次に旧 Primary)。

Major Upgrade — 慎重に #

PostgreSQL 16 → 17 のようなメジャーアップグレードです。壊れることがあります。手順は次のとおりです。

1. 手動スナップショットを作ります(ロールバック用)。
2. テスト環境で同じバージョンのマイグレーションを試します。
3. 可能なら Read Replica を先にアップグレードします。
4. 運用時間外のダウンタイムウィンドウを取ります。
5. aws rds modify-db-instance --engine-version 17.0 を実行します。
6. アップグレードをモニタリングします。
7. 問題が生じたらスナップショットから新しいインスタンスを復元します。

メジャーアップグレードの前に、PostgreSQL の deprecated SQL や MySQL の strict mode の変更のような互換性の問題を先に点検します。

Blue/Green Deployment #

RDS の Blue/Green Deployment は、メジャーアップグレードや大きな変更のダウンタイムを減らす方式です。複製(green)を作り、cutover の時点だけ短く止めます。

aws rds create-blue-green-deployment \
  --blue-green-deployment-name my-postgres-bg \
  --source arn:aws:rds:ap-northeast-2:123456789012:db:my-postgres \
  --target-engine-version 17.0

Performance Insights — 性能モニタリング #

RDS の性能モニタリングツールです。どの SQL が時間を最も多く取るかをグラフで見ます。

時間軸 ──▶
DB Load ▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮
        │ ── SELECT ... FROM users WHERE ...
        │ ── UPDATE products SET ...
        │ ── lock:relation

• 7日は無料で、それ以上は追加費用です。
• スロークエリ / ロック / 待機を分析します。
• アプリケーションの N+1 クエリのようなパターンがグラフで見えます。

RDS Proxy — 接続プール #

Lambda やコンテナから RDS へ接続するとき、毎回 TCP / TLS のハンドシェイクが高くつきます。RDS Proxy が接続プールをマネージドで作ってくれます。

使う場合は次のとおりです。

• Lambda + RDS — 毎 invocation ごとに新しい接続が生まれるのを Proxy でプーリングします(第18章 API Gateway と Lambda)。
• コンテナの自動スケール — インスタンスが増えて connection が暴増するのを防ぎます。
• failover の自動回復。

費用は vCPU 時間あたりです。小さなワークロードにはオーバーキルになり得ます。

よく出会う落とし穴 #

• パブリック RDS — publicly-accessible=true で作り SG が 0.0.0.0/0 なら、数日以内に brute-force 攻撃が来ます。運用は常に Private サブネットとアプリ SG だけを許可します。
• master-user-password を git に置く — スクリプトや Terraform に平文のパスワードを置くと露出します。Secrets Manager(第20章)で管理します。
• Multi-AZ を ON にせず運用 — 費用削減で Multi-AZ を OFF にすると、AZ 障害時に DB が1 ~ 2時間ダウンします。運用は ON にします。
• backup-retention 0 — 費用削減で自動バックアップを OFF にすると、PITR も同時に OFF になります。事故時に復旧が不可能です。最低7日を推奨します。
• Final Snapshot なしで削除 — DB 削除時に --skip-final-snapshot で速く消すと、データが永久に失われます。terraform destroy のような自動化には final snapshot を強制します。
• Storage Auto-Scaling を OFF にする — ディスクが80%まで埋まった未明に書き込みが失敗します。--max-allocated-storage オプションで自動拡張を ON にします。

aws rds modify-db-instance \
  --db-instance-identifier my-postgres \
  --max-allocated-storage 200

• Read Replica をフェイルオーバー用途と誤解 — Read Replica は自動フェイルオーバーができません。手動の promote が必要です。自動フェイルオーバーは Multi-AZ です。
• Connection リーク — アプリが接続を閉じず max_connections を埋めると、新しいリクエストが拒否されます。PgBouncer / RDS Proxy またはアプリのプール設定を点検します。

練習問題 #

1. §「EC2 上の DB vs RDS」の表を見ずに、RDS を選んだとき自分でしなくてよい運用作業を3つ書いてみてください。そして逆に、EC2 上の DB が必要な特殊な状況を1つメモしておいてください。
2. 自動バックアップ(PITR)、手動スナップショット、Read Replica の3つをバックアップ / DR の観点で比較し、「昨夜誤って実行した DELETE を戻さなければならない」と「メジャーアップグレード直前に安全装置が必要だ」の2つの状況にそれぞれ何を使うかを、§「自動バックアップ」を根拠に選んでみてください。この比較は 第30章 災害復旧・バックアップ で再び拡張されます。
3. 運用 RDS を立ち上げる create-db-instance コマンドで、§「よく出会う落とし穴」の6項目を防ぐために、どのフラグをどの値にすべきかを一文ずつつなげてみてください(例: publicly-accessible、backup-retention-period、multi-az)。

一行まとめ: RDS はマネージドのリレーショナル DB で運用システムではほぼ RDS が答え、Aurora は分散ストレージと速いフェイルオーバーを加えた AWS 製エンジン。自動バックアップと PITR が5分精度で任意の時点を復元し、手動スナップショットは DB を消しても生き残る。Multi-AZ は同期複製 + 自動フェイルオーバーだが standby は読み取りに使えず、Read Replica は非同期の読み取り複製であって自動フェイルオーバーではない。運用の基本は Private サブネット、publicly-accessible=false、バックアップ7日以上。

次の章 #

DB 領域はつかめました。次の 第12章 Route 53 では、ユーザーが私たちのシステムに出会う最初の地点である DNS へ移ります。ドメイン登録と Hosted Zone、レコードの種類と Alias、ルーティングポリシー(Failover / Latency / Geolocation)までドメイン運用を整理します。