AWS RDS ベストプラクティス

Amazon RDS（Aurora を含む）を本番運用する際の設計・運用上のベストプラクティスを、領域ごとに整理したドキュメントです。

---

目次

1. エンジン・インスタンス選定
2. 高可用性（HA）と耐障害性
3. バックアップとリカバリ
4. セキュリティ
5. ネットワーク設計
6. パフォーマンス
7. ストレージ
8. 監視・アラート
9. メンテナンス・アップグレード
10. コスト最適化
11. 運用・IaC
12. チェックリスト

---

1. エンジン・インスタンス選定

ポイント

• t 系はCPUクレジット枯渇で突然性能が落ちる。本番で使う場合は CPUCreditBalance を必ず監視する。
• 最初は小さめに始め、CloudWatch / Performance Insights の実測値をもとにスケールする。

---

2. 高可用性（HA）と耐障害性

Multi-AZ

• 本番環境では必ず Multi-AZ を有効化する。
  • Multi-AZ インスタンス配置: スタンバイ1台（読み取り不可）、同期レプリケーション
  • Multi-AZ DB クラスター（MySQL/PostgreSQL）: 読み取り可能なスタンバイ2台、フェイルオーバーが高速
  • Aurora: クラスターボリュームが3AZに6重複製。リーダーインスタンスを別AZに置くことでフェイルオーバー先を確保

フェイルオーバーに強いアプリケーション

• 接続先は IP ではなく エンドポイント（DNS名） を使う。
• アプリ側の DNS キャッシュ TTL を短く（例: JVM の networkaddress.cache.ttl）。
• 接続断を前提とした リトライ（指数バックオフ） を実装する。
• RDS Proxy を使うとフェイルオーバー時間の短縮とコネクション維持が期待できる。
• Aurora では AWS が提供するドライバ（AWS Advanced JDBC Wrapper 等）でフェイルオーバー検知を高速化できる。

リードレプリカ

• 読み取り負荷の分散に使う（HAの代替ではない点に注意。※Auroraのリーダーはフェイルオーバー先にもなる）。
• レプリカラグ（ReplicaLag / AuroraReplicaLag）を監視し、整合性が必要な読み取りはライターへ向ける。

DR（災害対策）

• フェイルオーバー／DR 手順は定期的に訓練する（reboot --force-failover 等で検証）。

---

3. バックアップとリカバリ

• 自動バックアップを有効化し、保持期間は要件に合わせて設定（本番は 7〜35 日が目安）。
• ポイントインタイムリカバリ（PITR） が使えることを確認する。
• 長期保存やコンプライアンス要件には AWS Backup でポリシー管理（別アカウント・別リージョンへのコピーも可能）。
• 削除保護（Deletion Protection）を有効化する。
• 削除時に最終スナップショットを取得する設定にする（IaC では skip_final_snapshot = false）。
• 重大な変更（メジャーアップグレード、スキーマ変更）の前に手動スナップショットを取得する。
• リストア手順を定期的にテストする（リストア所要時間＝実際の RTO を把握する）。
• Aurora MySQL では Backtrack による短時間の巻き戻しも選択肢。

---

4. セキュリティ

暗号化

• 保管時の暗号化（KMS）を作成時に有効化する（後から有効化できないため、既存の非暗号化DBはスナップショットを暗号化コピーして復元する必要がある）。
• 要件に応じてカスタマーマネージドキー（CMK）を使い、キーポリシーでアクセスを制御する。
• 転送中の暗号化（TLS）を強制する。
  • PostgreSQL: rds.force_ssl = 1
  • MySQL: require_secure_transport = ON
• CA 証明書の更新期限を把握し、計画的にローテーションする。

認証・認可

• マスターユーザーのパスワードは AWS Secrets Manager で管理（RDS 統合による自動ローテーション）。
• アプリケーション用に 最小権限の DB ユーザーを個別に作成し、マスターユーザーをアプリで使わない。
• IAM データベース認証を活用すると、パスワードレスで短期トークンによる接続が可能。
• IAM ポリシーで RDS API 操作（削除・変更など）を制限する。

監査・検知

• CloudTrail で RDS API 操作を記録する。
• DB の監査ログを有効化し CloudWatch Logs へ出力する。
  • PostgreSQL: pgaudit
  • MySQL / MariaDB: Audit プラグイン
• Amazon GuardDuty RDS Protection で不審なログイン（Aurora 対象）を検知する。
• AWS Config ルールで設定の逸脱（パブリックアクセス、暗号化なし等）を検出する。
• Security Hub でセキュリティ基準への準拠状況を確認する。

---

5. ネットワーク設計

• プライベートサブネットに配置し、PubliclyAccessible = false にする。
• DB サブネットグループは 複数 AZ のサブネットで構成する。
• セキュリティグループはアプリケーション層のSGからのみ、必要なポートだけを許可（CIDR 全開放はしない）。
• 運用者のアクセスは踏み台ではなく SSM Session Manager のポートフォワーディング などを使い、SSH 鍵管理や公開ポートを避ける。
• Lambda など接続数が急増しやすいワークロードからは RDS Proxy 経由で接続する。

---

6. パフォーマンス

パラメータ管理

• デフォルトのパラメータグループは変更できないため、カスタムパラメータグループを作成して使う。
• 変更は検証環境で効果を確認してから本番に適用する。動的／静的パラメータ（再起動要否）を区別する。

接続管理

• アプリ側で コネクションプーリングを使う。
• max_connections を意識し、接続数が多い場合は RDS Proxy を導入する。

クエリ・インデックス

• Performance Insights で待機イベント・上位 SQL を分析する。
• スロークエリログを有効化（slow_query_log / log_min_duration_statement）して定期的に確認する。
• 実行計画（EXPLAIN / EXPLAIN ANALYZE）でインデックスの効き具合を確認する。
• PostgreSQL では autovacuum の設定と、テーブル肥大化（bloat）を監視する。

読み取りのスケール

• 読み取り中心のワークロードはリードレプリカ／Aurora リーダーへ分散する。
• 頻繁に読まれるデータは ElastiCache 等でキャッシュする。

その他

• I/O 集約で読み取りが多い場合、ローカル NVMe を使う Optimized Reads（対応インスタンス）を検討。
• Aurora で I/O コストが大きい場合は Aurora I/O-Optimized を検討。

---

7. ストレージ

• 汎用用途は gp3 を推奨（gp2 よりベースライン性能を独立に設定でき、コスト効率が良いことが多い）。
• 高く安定した IOPS が必要なら io1 / io2 Block Express。
• ストレージの自動スケーリングを有効化し、最大ストレージを設定してディスクフルを防ぐ。
• FreeStorageSpace を監視し、閾値でアラートを出す。
• 注意: RDS のストレージは 縮小できない（縮小には新規作成＋移行が必要）。

---

8. 監視・アラート

有効化すべき機能

主要なアラーム対象メトリクス

• DevOps Guru for RDS を使うと、異常検知と原因の示唆が得られる。

---

9. メンテナンス・アップグレード

• メンテナンスウィンドウとバックアップウィンドウを業務影響の少ない時間帯に設定し、両者が重ならないようにする。
• マイナーバージョン自動アップグレードは、検証プロセスと合わせて方針を決める（検証環境で先行適用するのが望ましい）。
• メジャーバージョンのサポート終了（EoS）を計画的に管理する。サポート終了後は RDS 延長サポート（有料） に自動で移行し、追加料金が発生するため注意。
• メジャーアップグレードや大きな変更には Blue/Green Deployments を使い、ダウンタイムとリスクを最小化する。
• 適用待ちのメンテナンス（Pending maintenance）を定期的に確認する。

---

10. コスト最適化

• 長期稼働の本番 DB は リザーブドインスタンス（RI） を検討する。
• Graviton インスタンスへの移行で価格性能比を改善する。
• 開発・検証環境は 夜間・休日に停止する（RDS の停止は最大 7 日で自動起動されるため、スケジュール停止を組む）。
• 使われていないインスタンス、古い手動スナップショットを定期的に棚卸しする。
• Compute Optimizer / Trusted Advisor で過剰サイズのインスタンスを特定する。
• Aurora は I/O コスト比率に応じて Standard と I/O-Optimized を選択する。
• 旧バージョンを放置して延長サポート料金が発生していないか確認する。

---

11. 運用・IaC

• RDS 構成は Terraform / CloudFormation / CDK でコード管理し、手動変更を避ける。
• タグ付け規約（Environment, Owner, Project, CostCenter など）を定めてコスト配分と管理に活用する。
• 環境ごと（本番・ステージング・開発）にアカウントまたは VPC を分離する。
• 本番データを開発環境で使う場合は マスキング・匿名化を行う。
• スキーマ変更はマイグレーションツール（Flyway, Liquibase 等）で管理し、大規模テーブルの変更はオンライン DDL 手法（pt-online-schema-change, gh-ost 等）を検討する。
• 障害対応・フェイルオーバー・リストアの Runbook を整備する。

---

12. チェックリスト

可用性・バックアップ

• 本番は Multi-AZ（または Aurora の複数 AZ 構成）
• 自動バックアップ有効・保持期間が要件を満たしている
• 削除保護が有効
• リストア手順をテスト済み
• DR 方針（RPO/RTO）が定義されている
• アプリにリトライ／再接続処理がある

セキュリティ

• 保管時の暗号化（KMS）が有効
• TLS 接続を強制
• パブリックアクセス無効、プライベートサブネット配置
• セキュリティグループが最小限
• 認証情報を Secrets Manager で管理・ローテーション
• アプリ用に最小権限ユーザーを使用
• 監査ログ・CloudTrail が有効

パフォーマンス・監視

• カスタムパラメータグループを使用
• Performance Insights・拡張モニタリングが有効
• ログを CloudWatch Logs にエクスポート
• 主要メトリクスに CloudWatch アラームを設定
• RDS イベント通知を設定
• ストレージ自動スケーリングが有効

運用・コスト

• メンテナンス／バックアップウィンドウを適切に設定
• エンジンバージョンのサポート期限を把握
• IaC で構成管理
• タグ付け規約を適用
• RI・Graviton・開発環境停止を検討済み

---

参考資料

• Amazon RDS のベストプラクティス（公式ドキュメント）
• Amazon Aurora のベストプラクティス
• Amazon RDS のセキュリティ
• AWS Well-Architected Framework