某公司運行一個關鍵應用程式，其中 API Gateway 暴露了一個與 Lambda 函數整合的 HTTP API。該應用程式將資料儲存在 RDS for MySQL 實例中（2 個 vCPU，64 GB RAM）。在不可預測的尖峰時段，某些 API 呼叫會返回 HTTP 500 錯誤。CloudWatch Logs 顯示「連線過多」。除了排定的維護期間，資料庫必須保持可用。公司如何使應用程式能夠彈性應對連線高峰？

當 Lambda 函數與關聯式資料庫互動時，連線管理是一個常見挑戰。Lambda 函數的無伺服器特性意味著它們會頻繁啟動和終止，導致資料庫連線的建立和關閉開銷很大，並可能迅速耗盡資料庫的連線限制。Amazon RDS Proxy 透過建立和管理資料庫連線池來解決此問題。它允許 Lambda 函數重複使用現有的資料庫連線，而不是為每個叫用建立新連線，從而減少資料庫上的負載並防止「連線過多」錯誤。 減少 vCPU 不會解決連線問題，反而可能降低效能。增加 maxconnections 可能會暫時緩解問題，但如果沒有適當的連線管理，資料庫仍可能不堪重負，且可能導致記憶體不足。CloudWatch 警報更改實例類別是一種反應性措施，無法預防連線問題，且實例類別變更會導致停機。EventBridge 規則增加 maxconnections 也是反應性措施，且 CPU 使用率與連線數不直接相關。