某公司的 HTTP 應用程式位於 Network Load Balancer (NLB) 後方。NLB 的目標群組使用 Amazon EC2 Auto Scaling 群組，其中包含多個執行 Web 服務的 EC2 執行個體。NLB 未偵測到 HTTP 錯誤，這需要手動重新啟動 Web 服務的 EC2 執行個體。該公司希望在不編寫自訂指令碼或程式碼的情況下提高可用性。解決方案架構師應該怎麼做？

正確答案是將 NLB 替換為 Application Load Balancer (ALB)。NLB 主要在第 4 層（傳輸層）運作，無法偵測 HTTP 錯誤，這解釋了為什麼它沒有偵測到應用程式層的故障。ALB 在第 7 層（應用程式層）運作，可以執行 HTTP 運作狀態檢查，並根據應用程式的 URL 路徑和預期回應來判斷執行個體是否健康。當 ALB 偵測到不健康的執行個體時，Auto Scaling 群組可以配置為終止並替換這些執行個體，從而提高可用性，而無需手動干預或自訂指令碼。 其他選項不正確的原因： 在 NLB 上啟用 HTTP 運作狀態檢查是無效的，因為 NLB 不理解 HTTP 協定，它只在 TCP 層級進行運作狀態檢查。 新增 cron job 涉及編寫自訂指令碼，這與題目的要求「不編寫自訂指令碼或程式碼」相悖。 監控 NLB 的 UnhealthyHostCount 指標無法解決根本問題，因為 NLB 無法偵測 HTTP 錯誤，所以該指標不會反映應用程式層的故障。