一個地端訂單處理平台使用網頁前端 (VMs)、用於訊息傳遞的 RabbitMQ，以及用於容器化後端的 Kubernetes 叢集。該公司希望在不對應用程式進行重大更改且營運開銷最少的情況下遷移到 AWS。哪種架構符合這些限制？

正確選項透過建立現有網頁伺服器 VM 的 AMI，並在 ALB 後方的 EC2 Auto Scaling 群組中運行，實現了前端的最小應用程式更改和低營運開銷。將地端 RabbitMQ 替換為完全託管的 Amazon MQ 服務，可減少管理負擔。將後端遷移到 Amazon EKS 則利用了託管的 Kubernetes 服務，符合容器化後端的需求，同時降低了營運複雜性。 錯誤選項分析： 建立自訂 AWS Lambda runtime 來模擬網頁伺服器需要對應用程式進行重大更改，且不符合「不對應用程式進行重大更改」的限制。 在 EC2 執行個體叢集上安裝 Kubernetes 以託管後端會增加營運開銷，因為需要自行管理 Kubernetes 控制平面，這與「營運開銷最少」的目標不符。 將 RabbitMQ 替換為 Amazon SQS 需要對應用程式的訊息傳遞邏輯進行更改，因為 SQS 是一種佇列服務，而 RabbitMQ 支援更廣泛的訊息模式，這與「不對應用程式進行重大更改」的限制不符。