一個用於行動應用程式的單體式 REST API 運行在公共子網路中的五個 EC2 實例上，並由一個直接指向這些實例 IP 的 Route 53 多值回答記錄作為前端。突然的大流量高峰導致應用程式不堪重負。哪種解決方案能讓應用程式擴展以應對新的、可變的負載，同時將操作開銷降到最低？

正確答案是將 Application Load Balancer (ALB) 部署在 API 前，將 EC2 實例移至私有子網路，將實例註冊為 ALB 目標，並更新 Route 53 記錄以指向 ALB。ALB 提供自動負載平衡、健康檢查和自動擴展能力，能有效處理流量高峰，同時將操作開銷降到最低。將 EC2 實例移至私有子網路可提高安全性。 將 API 拆分為 Lambda 函數雖然可擴展，但會涉及大量重構，操作開銷較高。將 API 容器化並在 EKS 上運行也能擴展，但 EKS 的管理複雜度高於 ALB。將 EC2 實例放入 Auto Scaling group 並使用 Lambda 更新 Route 53 記錄是可行的，但 ALB 提供了更直接且整合的解決方案，無需自訂 Lambda 函數來管理 Route 53 記錄。