AWS中級 #4 RDS — マネージド DB、バックアップ、パラメータグループ

2026年4月21日火曜日

読了 9分

#3 S3 がオブジェクトの場だったとすれば、ここからは リレーショナル DB の場へ。AWS のリレーショナル DB マネージドサービスが RDS (Relational Database Service) です。PostgreSQL / MySQL / MariaDB / Oracle / SQL Server / Aurora を 1 つのコンソールから立ち上げて運用できます。

この記事では RDS のマネージドモデル → 自動バックアップと PITR → Multi-AZ と Read Replica → パラメータ / オプショングループ → アップグレードの場を順に整理します。

EC2 上 DB vs RDS #

クラウドに初めて出会うと誰もが一度は迷います。「EC2 1 台立てて PostgreSQL 自前で入れるか、RDS にするか?」

項目	EC2 上 DB	RDS
インストール / セットアップ	自分で	コンソールクリック
パッチ / マイナーアップグレード	自分で	クリック (または自動)
バックアップ	自分で (`pg_dump`、cron)	自動 + PITR
Multi-AZ failover	自分で (Patroni 等)	オプション有効化
Read Replica	自分で (replication 構築)	コンソールクリック
監視	自分で (`pg_stat_*`)	CloudWatch + Performance Insights
費用	インスタンス費用のみ	インスタンス + ライセンス + マネージドプレミアム
自由度	OS / 拡張 / カーネル全部触れる	制限あり (例: superuser 不可)

運用システムは 99% RDS が答え。EC2 上 DB は 拡張が RDS で未サポート または OS レベルチューニングが必要 な特殊用途のみ。

エンジン選択 #

RDS が対応するエンジン:

RDS エンジン

PostgreSQL  ── 新規プロジェクトの第一候補。JSONB / 拡張が豊富
MySQL       ── 最もよく使われる場。互換性重視
MariaDB     ── MySQL フォーク。ほぼ MySQL の場
Oracle      ── ライセンス高めのエンタープライズ
SQL Server  ── マイクロソフト系
Aurora      ── AWS 自社エンジン。PostgreSQL / MySQL 互換

Aurora の場 #

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

	Aurora	RDS PostgreSQL/MySQL
ストレージ	分散型 (自動 6 コピー)	EBS
最大サイズ	128 TB 自動拡張	64 TB
Read Replica	最大 15 個 (ミリ秒同期)	5 個 (非同期)
failover 時間	< 30 秒	1~2 分
費用	RDS より ~20% 高い	標準
新機能	Serverless v2、Global Database	RDS の基本

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

Aurora Serverless v2 は 使用量ベースで自動スケール する RDS — トラフィックが揺れる場合に魅力的です。コールドスタートがほぼない (v1 の弱点が解消)。

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

RDS PostgreSQL 作成

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-instance-class`	インスタンスタイプ。`db.t3` (小)、`db.m5` (一般)、`db.r5` (メモリ)
`engine` / `engine-version`	エンジンとバージョン
`allocated-storage`	ディスク GB。`storage-type=gp3` がデフォルト
`multi-az`	Standby を別 AZ に自動作成
`publicly-accessible`	パブリック IP。運用は `false`
`backup-retention-period`	自動バックアップ保持日数 (0~35)

DB Subnet Group #

RDS は Multi-AZ 用のサブネットを事前指定 する必要があります。それが DB Subnet Group。通常はプライベートサブネットを 2 AZ 以上。

DB Subnet Group 作成

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 サブネット (#1 VPC) です。インターネットに直接露出しません。アプリサーバー SG だけ SG 単位で入れるよう許可します。

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

RDS の本当の価値はバックアップにあります。

Automated Backup #

backup-retention-period が 0 より大きければ自動バックアップが有効。

毎日 1 回 フルバックアップ (バックアップウィンドウ時間に)
トランザクションログ 5 分ごと
保持期間 (1~35 日) の間保管
DB 削除時は自動バックアップも一緒に削除 (SkipFinalSnapshot=false で防げる)

Point-in-Time Recovery (PITR) #

自動バックアップが有効な RDS は 保持期間内の任意時点に復元 可能。トランザクションログ 5 分単位の精度。

3 時間前の時点に復元

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-04-21T08:30:00Z

復元は 新規インスタンスを作る形 — 元はそのまま。「今日 3 時 27 分直前の状態が必要」が可能。

Manual Snapshot #

自動バックアップとは別にユーザーが明示的に作るバックアップ。DB を削除しても消えない、保持期限もなし。

手動スナップショット

aws rds create-db-snapshot \
  --db-instance-identifier my-postgres \
  --db-snapshot-identifier my-postgres-2026-04-21-prerelease

運用での使いどころ:

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

Multi-AZ — 高可用性 #

--multi-az を有効にすると RDS が Standby インスタンスを別 AZ に自動レプリカ。

Multi-AZ の形

   ┌──────────────────────────────────┐
   │           VPC                    │
   │                                  │
   │    AZ a              AZ b        │
   │    ┌──────┐          ┌──────┐    │
   │    │ Pri  │ ◀══════▶ │Stand │    │
   │    │mary  │  同期レプリカ│ by   │    │
   │    └──────┘          └──────┘    │
   │       ▲                          │
   │       │ DNS endpoint             │
   │       │ (自動 failover)            │
   └───────┼──────────────────────────┘
           │
       アプリサーバー

同期レプリカ — Standby も毎トランザクション commit まで受け取る
障害時の自動 failover — 30 秒~2 分以内に Standby が Primary になり DNS endpoint がそちらを指す
読み取り分散はしない — Standby は 読み取りでも使われない (Aurora と異なる点)

Multi-AZ の費用 #

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

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

PostgreSQL / MySQL に新たに登場した Multi-AZ DB Cluster は standby が 読み取り可能 で、failover 時間も 35 秒以下。ただし AZ 3 つ使用 (インスタンス 3 つ分の費用)。

Read Replica — 読み取り分散 #

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 の場 #

用途	適合度
読み取りトラフィック分散	⭐⭐⭐
分析 / レポート	⭐⭐⭐
バックアップ / DR	⭐⭐ (スナップショットの方が安全)
自動 failover	❌ — 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"

種別:

Static — DB 再起動後に適用 (max_connections 等)
Dynamic — 即時適用 (log_statement 等)

よく触るパラメータ:

パラメータ	PostgreSQL	MySQL
最大接続	`max_connections`	`max_connections`
クエリログ	`log_min_duration_statement`	`slow_query_log`
メモリ	`shared_buffers`、`work_mem`	`innodb_buffer_pool_size`
タイムゾーン	`timezone`	`time_zone`

Option Group #

エンジン別の追加機能 (例: SQL Server の SSIS、Oracle の OEM) を有効化するためのものです。PostgreSQL / MySQL ではほとんど触りません。

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

RDS はエンジンバージョンを 2 種類に分けます。

Minor Upgrade — 安全 #

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

自動マイナーアップグレード有効化

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

ダウンタイムは 30 秒~5 分。Multi-AZ ならさらに短い (Standby を先に → failover → 旧 Primary)。

Major Upgrade — 慎重に #

PostgreSQL 16 → 17 のようなメジャーアップグレード。壊れる可能性あり。手順:

手動スナップショット 作成 (ロールバック用)
テスト環境で同じバージョンへの移行を試行
Read Replica を先にアップグレード (可能なら)
業務時間外のダウンタイムウィンドウを確保
aws rds modify-db-instance --engine-version 17.0
アップグレード監視
問題ならスナップショットから新インスタンスを復元

メジャーアップグレード前は PostgreSQL の deprecated SQL / MySQL の strict mode 変更 といった互換性問題を先に点検。

Blue/Green Deployment #

RDS の Blue/Green Deployment はメジャーアップグレード / 大規模変更のダウンタイムを減らす新機能。レプリカ (green) を作り cutover の瞬間だけ短く止める。

Blue/Green 作成

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 が時間を最も食っているかをグラフで見せます。

Performance Insights の場

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

7 日無料、それ以上は追加費用
スロークエリ / ロック / 待機分析
Django 上級 #3 クエリ最適化で出会う N+1 のようなパターンがグラフで見えます

RDS Proxy — 接続プール #

Lambda / コンテナから RDS へ接続するときの TCP / TLS ハンドシェイクが高くつく作業です。RDS Proxy が接続プールをマネージドで提供します。

用途:

Lambda + RDS — 毎回 invocation で新しい接続 → Proxy でプール
コンテナ自動スケール — インスタンス増加で接続数爆発
failover の自動回復

費用は vCPU 時間単位 — 小規模ワークロードにはオーバーキルかも。

よくハマる罠 #

1) パブリック RDS #

publicly-accessible=true で作って SG が 0.0.0.0/0 → 数日内にブルートフォース攻撃が来ます。運用は常に Private サブネット + アプリ SG のみ。

2) `master-user-password` を git に #

スクリプト / Terraform に平文パスワード → 漏洩。Secrets Manager (上級 #6) で管理。

3) Multi-AZ なしで運用 #

費用節約で Multi-AZ をオフ → AZ 障害で DB 1~2 時間ダウン。運用は有効化。

4) backup-retention 0 #

費用節約で自動バックアップをオフ → PITR も同時にオフ。事故時の復旧不可。最低 7 日 推奨。

5) Final Snapshot を作らずに削除 #

DB 削除時に --skip-final-snapshot で素早く削除 → データ恒久損失。terraform destroy のような自動化に final snapshot を強制。

6) Storage Auto-Scaling オフ #

ディスクが 80% に達した深夜 → 書き込み失敗。max-allocated-storage オプションで自動拡張を有効化。

Storage Auto-Scaling 有効化

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

7) Read Replica を failover として使う #

Read Replica は自動 failover しません。手動 promote が必要。自動 failover は Multi-AZ。

8) Connection リーク #

アプリが接続を閉じず max_connections を埋める → 新リクエスト拒否。PgBouncer / RDS Proxy またはアプリプール設定を点検。

まとめ #

今回押さえたこと:

RDS = AWS のマネージドリレーショナル DB。PostgreSQL / MySQL / Aurora が一般的
Aurora = AWS 自社エンジン。分散ストレージ、高速 failover、より多くの RR
DB Subnet Group で Private サブネットへ。publicly-accessible=false が運用デフォルト
自動バックアップ + PITR = 5 分精度で任意時点に復元
Manual Snapshot = 明示的、DB 削除しても残る
Multi-AZ = 同期レプリカ + 自動 failover、ただし standby は読み取り不可
Read Replica = 非同期コピー、読み取り分散 / 分析。自動 failover ではない
Parameter Group でエンジン設定管理。Static / Dynamic の違い
マイナーアップグレード = 自動適用可。メジャーアップグレード = Blue/Green 推奨
Performance Insights + RDS Proxy で運用を補強
罠 — パブリック、パスワード、Multi-AZ オフ、バックアップ 0、final snapshot 抜け、storage 自動拡張、RR failover の誤解、connection リーク

次回 — Route 53 #

DB の場は片付きました。次はユーザーが私たちのシステムと最初に出会う場 — DNS へ。

#5 Route 53 — ドメインと DNS では、ドメイン登録 / Hosted Zone / レコード種別と Alias / ルーティングポリシー (Failover / Latency / Geolocation) まで運用ドメインの取り回しを整理します。

EC2 上 DB vs RDS #

エンジン選択 #

Aurora の場 #

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

DB Subnet Group #

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

Automated Backup #

Point-in-Time Recovery (PITR) #

Manual Snapshot #

Multi-AZ — 高可用性 #

Multi-AZ の費用 #

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

Read Replica — 読み取り分散 #

Read Replica の場 #

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

Parameter Group #

Option Group #

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

Minor Upgrade — 安全 #

Major Upgrade — 慎重に #

Blue/Green Deployment #

Performance Insights — 性能の場 #

RDS Proxy — 接続プール #

よくハマる罠 #

1) パブリック RDS #

2) master-user-password を git に #

3) Multi-AZ なしで運用 #

4) backup-retention 0 #

5) Final Snapshot を作らずに削除 #

6) Storage Auto-Scaling オフ #

7) Read Replica を failover として使う #

8) Connection リーク #

まとめ #

次回 — Route 53 #

2) `master-user-password` を git に #