客戶將檔案上傳到 S3，並傳送包含物件 ARN 的 SQS 訊息。一個基於 EC2 的 worker 會輪詢 SQS 並處理檔案；處理時間會因檔案大小而異。為了減少客戶感受到的延遲，管理員從現有執行個體建立了一個 AMI 和一個啟動範本。應如何設定 Auto Scaling 以提高響應能力？

正確答案是建立自訂指標，結合 SQS 的 ApproximateNumberOfMessagesVisible 和 Auto Scaling 群組中 InService 狀態的執行個體數量。這樣可以動態調整 Auto Scaling，確保每個執行個體處理的訊息量保持在最佳範圍，從而提高響應能力。應用程式需要修改以計算此指標並發佈到 CloudWatch。 選項一不正確，因為 Auto Scaling 政策通常根據單一指標進行擴展，且在啟動範本中新增多種執行個體大小本身並不能直接解決響應能力問題，除非有更精確的邏輯來選擇。 選項二不正確，ApproximateNumberOfMessagesDelayed 指標反映的是延遲訊息的數量，這通常用於處理失敗或需要重試的訊息，而非直接用於響應能力擴展。 選項三不正確，ASGAverageCPUUtilization 和 GroupPendingInstances 雖然是 Auto Scaling 的相關指標，但它們並未直接反映 SQS 佇列的負載情況，無法有效預測和響應訊息處理需求。