一個傳統的工作負載，其無狀態應用程式層部署在從 AMI 啟動的單一大型 EC2 執行個體上，而 MySQL 資料庫則部署在單一 EC2 執行個體上。應用程式伺服器的 CPU 經常達到 100%，導致服務中斷。修補程式是手動套用的，並導致了停機。公司需要以最少的開發工作使應用程式具有高可用性。哪種解決方案符合此要求？

正確答案透過建立包含 SSM Agent 的新 AMI 並使用 Auto Scaling group 解決了可用性、擴展和修補問題。SSM Agent 允許自動化修補，減少停機時間。Auto Scaling group 搭配 Application Load Balancer 可根據 CPU 使用率自動擴展，解決了 CPU 瓶頸並提高了可用性。將資料庫遷移到 Amazon Aurora MySQL 提供了高可用性、可擴展性和效能，同時保持與現有 MySQL 資料庫的相容性，最大限度地減少了開發工作。 其他選項不符合「最少的開發工作」要求： 將應用程式重構為 Lambda 函數需要大量的開發工作。 遷移到 Graviton 執行個體本身無法解決修補問題，且遷移到 DynamoDB 需要大幅重構應用程式以適應 NoSQL 模型。 將應用程式容器化並遷移到 ECS 也需要顯著的開發工作，並且遷移到 Amazon Neptune (圖形資料庫) 需要完全重寫資料庫互動邏輯。