目次
1. 結論
Amazon RDS Proxyは、「アプリとDBの間の仲介役（コネクション管理人）」です。特に、大量に起動するLambda関数などが直接DBに接続すると、DBの接続数上限（メモリ消費）ですぐにパンクしてしまいます。RDS Proxyが接続を「プール（共有）」して使い回すことで、DBを守り、システム全体の弾力性を高めます。
2. SAAで出やすいポイント
- コネクションプーリング: 大量のアプリケーション接続を少数のデータベース接続に集約し、DBリソースを節約する。
- フェイルオーバーの高速化: RDSがMulti-AZで切り替わる際、アプリ側で接続エラーを出さずに、Proxyが自動で新しいメイン機へ繋ぎ変えてくれる。これにより切り替え時間が最大60%短縮される。
- サーバーレスとの相性: 起動・終了が激しいLambda環境において、DB接続のオーバーヘッドを無くすために必須。
- セキュリティ: DBの認証情報（パスワード）を直接アプリに持たせず、Secrets Managerと連携してProxy経由で安全に認証できる。
3. キーワードでの判断
| 問題文のキーワード | 疑うべきサービス/機能 | 判断理由 |
|---|---|---|
| 「LambdaからRDSへの接続が多すぎてエラー」 | RDS Proxy | 接続集約（プーリング）が必要 |
| 「フェイルオーバー時のダウンタイムを最小化」 | RDS Proxy | Proxyによる接続維持機能 |
| 「データベース接続のオーバーヘッドを削減」 | RDS Proxy | 既存コネクションの再利用 |
4. ひっかけポイント
- 全てのDBに対応しているわけではない: 現在はMySQL、PostgreSQL、SQL Serverなどの主要エンジンに対応しているが、古いバージョンや特殊なエンジンは注意。
- コスト: 無料ではない。Proxyを通るトラフィック量ではなく、Proxyが管理するDBインスタンスのキャパシティ（vCPU）に基づいて課金される。
- 読み書き分離: RDS Proxy自体に「読み取りクエリを自動でレプリカに飛ばす」機能はない（エンドポイントを使い分ける必要がある）。
5. 覚え方
- 「居酒屋の予約席管理」。
- お客さん（Lambda）がバラバラに来ても、管理人が空いている席（DB接続）へ効率よく案内し、席の入れ替え時（フェイルオーバー）もスムーズに誘導してくれるイメージ。
6. 関連サービス
| サービス名 | 関連する理由 |
|---|---|
| Lambda | RDS Proxyを導入する最大の理由となるコンピューティングサービス。 |
| Secrets Manager | DBパスワードを安全に保管し、Proxyがそれを使ってDBにログインする。 |
| RDS Multi-AZ | Proxyと組み合わせることで、最強の可用性を実現する。 |
7. Obsidian管理メモ
- 復習ポイント: 「Lambda × RDS」という組み合わせが出てきたら、高確率でRDS Proxyがセットで検討される。
- 関連ノート: サーバーレスDBアクセスのベストプラクティス
8. HTMLファイル名
amazon-rds-proxy-connection-pooling.html
