某個網站執行在 ALB 後方的四個 EC2 instance 上。當 ALB 將某個 instance 標記為 unhealthy 時，CloudWatch alarm 會進入 ALARM 狀態，然後操作人員手動新增一個替換 instance。該公司希望有一個高可用性的解決方案，可以自動替換失敗的 EC2 instance，同時在遷移到新設計時將停機時間降到最低。解決方案架構師應該使用哪個步驟序列？

正確答案能實現自動替換失敗的 EC2 執行個體，同時將停機時間降到最低。首先建立 Auto Scaling group (ASG) 和啟動範本，然後將 ASG 附加到現有的 ALB，這樣流量就能繼續流向現有執行個體。最後，將現有的 EC2 執行個體新增到 ASG 中，讓 ASG 管理這些執行個體。 其他選項的錯誤原因： 刪除現有的 ALB 會導致停機。 刪除現有的 ALB 和 EC2 執行個體會導致停機。 等待 ALB 將現有 EC2 執行個體註冊到 ASG 是不正確的，因為 ASG 管理的是其自己的執行個體，而不是由 ALB 註冊。