Amazon RDS

解決する課題

• DBサーバーのOSパッチ・バックアップ・監視が重い → 自動化したい
• 障害でDBが止まると困る → 自動フェイルオーバーで可用性を上げたい
• 読み取りが増えてきた → 読み取りをスケールしたい

主要概念と用語

• DBインスタンス: 稼働しているDB本体
• Multi-AZ: 別AZに同期スタンバイを持ち、障害時に自動フェイルオーバー（可用性）
• リードレプリカ: 非同期の読み取り専用コピー（読み取りスケール）
• 自動バックアップ / スナップショット: ポイントインタイムリカバリ
• エンドポイント: 接続先のDNS名（フェイルオーバーで向き先が切替）

仕様・制限・クォータ

• バックアップ保持期間は最大35日（自動）、スナップショットは任意保持
• メンテナンスウィンドウでパッチ適用
• ストレージ自動拡張、IOPS最適化（gp3/Provisioned IOPS）

内部の仕組み

• Multi-AZ: プライマリへの書き込みをスタンバイへ同期複製。プライマリ障害時はDNSエンドポイントをスタンバイへ自動で付け替え（数十秒〜）。可用性のための仕組みで、通常スタンバイは読み取りに使えない
• リードレプリカ: 非同期複製のため遅延がある。読み取りクエリを分散する用途
• Aurora: ストレージを計算層から分離し、3AZ×2＝6コピーへ自動複製・自己修復。フェイルオーバーも高速

設計パターン / ベストプラクティス

• 本番は Multi-AZ を有効化
• 読み取り負荷は リードレプリカ で分散
• DBはプライベートサブネットに置き、外部公開しない
• 認証は IAMデータベース認証 / Secrets Manager でパスワード管理を自動化

運用・監視・トラブルシュート

• CloudWatch / Performance Insights / Enhanced Monitoring で性能を可視化
• 接続不可時は SG・サブネット・エンドポイントを確認
• スロークエリはインデックス・パラメータグループを見直し

コスト

• インスタンス時間＋ストレージ＋I/O＋バックアップ
• 定常稼働は リザーブドインスタンス で割引。停止/right-sizingも有効

セキュリティ

• 保存時暗号化（KMS）は作成時に指定（後付けはスナップショット復元経由）
• 転送時はSSL/TLS
• プライベート配置＋最小限のSG

Well-Architected の観点

• 信頼性: Multi-AZ・自動バックアップ・PITR
• セキュリティ: 暗号化・プライベート配置・最小権限
• パフォーマンス効率: レプリカ/インスタンス種別/ストレージ選定

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# Multi-AZ の PostgreSQL を作成（プライベート前提）
aws rds create-db-instance \
  --db-instance-identifier app-db \
  --engine postgres \
  --db-instance-class db.t3.medium \
  --allocated-storage 20 \
  --multi-az \
  --storage-encrypted \
  --master-username admin \
  --manage-master-user-password

# リードレプリカを追加して読み取りを分散
aws rds create-db-instance-read-replica \
  --db-instance-identifier app-db-replica \
  --source-db-instance-identifier app-db