RDSのスケーリング・監視・暗号化・キャッシュ連携

スケールアップ（垂直スケーリング）

性能不足の典型は CPU・メモリ不足 と ディスク I/O 不足 です。

• DB インスタンスクラス … より大きな vCPU／メモリ、または メモリ最適化などファミリーを変更。
• ストレージタイプ／IOPS … プロビジョンド IOPS への変更や、IOPS 上限の引き上げ。

変更時はメンテナンスウィンドウ内で適用するか即時適用かを選べることがあり、マルチ AZ ではスタンバイへの切り替えを伴い可用性への影響が小さい、という説明が資料に出ます（エンジン・操作により異なる）。

ストレージ容量と自動拡張

割り当てストレージは増やすことはできても、減らすことは基本できない、という制約が SAA で頻出です。ストレージの自動拡張を有効にし、使用量に応じて上限値まで伸ばす運用で、ディスク満杯による停止を防ぎます（上限とコストは設計で固定）。

書き込み最適化（Optimized Writes など）

一部の MySQL 互換構成では、16KB ページへの書き込み効率化などにより、書き込みスループットを高めるオプションが説明されます。MySQL 8.0.30 以上や特定のインスタンスクラスなど条件付きの記述があります。試験では「常にオンでよい」より、**前提条件とトレードオフ（I/O パターン）**を読む問題になります。最新仕様は RDS の該当リリースノート／ユーザガイドを参照してください。

スケールアウト（読み取り）

読み取り負荷が高い場合は、リードレプリカを増やしてクエリを分散します。さらに ElastiCache（Redis／Memcached） にホットな読み取り結果やセッションを載せ、RDS への往復を減らすのが典型パターンです。

書き込みのスケールアウトはリードレプリカでは解決できません。シャーディングや Aurora への移行など、アーキテクチャ変更の選択肢が別トピックとして出ます。

監視とアラート（サービス別の整理）

次のような積み上げで整理すると理解しやすいです。

仕組み	役割
CloudWatch メトリクス（標準）	CPU、接続数、空きストレージ、レプリカラグなど。5 分粒度の説明が基本。
Enhanced Monitoring	OS プロセスに近い粒度（秒単位）でメトリクス取得。追加コスト。
CloudWatch アラーム	閾値超過で SNS・Auto Scaling（別リソース） などへ通知。
CloudWatch Logs 連携	スロークエリログ、エラーログ、一般ログなどを検索・保持。エンジンごとに取得できるログ種別が異なる。
EventBridge（旧 CloudWatch Events）	メンテナンス完了、フェイルオーバーなどのイベントを検知し、Lambda や SNS に連携。

ログのデフォルト保持期間はエンジン・ログ種別で異なります（数字は暗記より**「ドキュメントで確認」**が試験向き）。

暗号化

• 転送中 … アプリから RDS へ SSL/TLS 接続。RDS は証明書を提供し、クライアント側で検証します。
• 保管時 … AWS KMS の CMK でボリューム・バックアップ・スナップショットを暗号化。作成時にのみ有効化できるケースが基本で、非暗号化からのその場切り替えは不可という問題が出ます。移行はスナップショット経由。

暗号化されたリソースをコピーや共有するとき、キーへのアクセス権が復旧の前提になります。

メンテナンスウィンドウ

OS や DB エンジンのパッチは、メンテナンスウィンドウで適用されます。マルチ AZ ではスタンバイに先に適用してからフェイルオーバー、という説明がよく出て、ダウンタイム最小化の文脈で選ばれます。

よくある誤答

• 「リードレプリカを増やせば書き込み性能も線形に伸びる」→ 誤り。
• 「空きストレージアラームは不要。RDS が勝手に無限に伸ばす」→ 自動拡張にも上限があり、監視は必要。
• 「拡張モニタリングは無料で常に有効がよい」→ 追加コストあり。

公式ドキュメント（深掘り）

• Monitoring metrics in Amazon RDS
• Enhanced Monitoring
• Publishing logs to Amazon CloudWatch Logs
• Encrypting Amazon RDS resources