一個電商應用程式透過 Amazon API Gateway 暴露 API，該 API 會叫用 AWS Lambda 函數。資料儲存在 Amazon RDS for PostgreSQL 資料庫實例中。在一次限時搶購活動中，API 呼叫量激增，導致應用程式變慢：CloudWatch 顯示大量的 Lambda 叫用、大量的資料庫連線，以及資料庫實例上高 CPU 使用率。解決方案架構師應該建議什麼來改善效能？

正確答案是建立一個 Amazon RDS Proxy 並更新 Lambda 函數以透過代理端點連線。RDS Proxy 專為處理大量短暫的資料庫連線而設計，這正是 Lambda 函數的典型行為。它能有效地管理連線池，減少資料庫的連線負擔，並降低 CPU 使用率。 增加 Lambda 函數的記憶體可能提高處理速度，但無法解決資料庫連線過多的根本問題。在資料檢索後立即關閉資料庫連線是良好實踐，但頻繁的連線建立和關閉本身就是效能瓶頸。 新增 ElastiCache for Redis 叢集可以快取常用資料，減少資料庫讀取，但對於寫入密集型操作或首次讀取仍需直接連線資料庫，且需要修改應用程式邏輯來利用快取。 在處理常式之外建立並重複使用資料庫連線是常見的優化方式，但 Lambda 函數的無伺服器特性和自動擴展可能導致每個實例仍建立多個連線，且無法像 RDS Proxy 那樣集中管理和池化連線，對於高併發場景效果有限。