在 Auto Scaling group 中的 EC2 執行個體上執行的應用程式，會處理來自 Amazon SQS 佇列的大量訊息。處理一批訊息需要數小時，且 Auto Scaling group 的平均 CPU 使用率未超過其目標追蹤擴展政策的閾值。應用程式日誌會傳送到 Amazon CloudWatch Logs。您需要以最少的營運開銷更快地處理佇列。哪個選項符合此要求？

正確答案是透過指標數學直接在 Auto Scaling 群組上建立目標追蹤擴展政策。此方法利用 CloudWatch 的指標數學功能，將 SQS 的 ApproximateNumberOfMessagesVisible 指標除以 Auto Scaling 群組的 GroupInServiceInstances 指標，以計算每個實例的訊息數量。這提供了一個即時且自動化的擴展機制，無需額外的 Lambda 函數或 EventBridge 排程，最大限度地減少了營運開銷。 選項 A 和 B 涉及建立 Lambda 函數來計算指標並發布自訂指標，這增加了不必要的複雜性和營運開銷。選項 D 透過 Lambda 將 SQS 訊息數寫入 CloudWatch Logs，然後再從日誌中建立指標，這是一個間接且效率較低的方法。