某公司執行一個三層式網路應用程式來處理客戶訂單。網路層使用 Application Load Balancer 後方的 Amazon EC2 執行個體。處理層使用 EC2 執行個體。該公司使用 Amazon Simple Queue Service (Amazon SQS) 將網路層和處理層解耦。儲存層是 Amazon DynamoDB。在尖峰時段，有些使用者回報訂單處理延遲。在這些延遲期間，EC2 執行個體的 CPU 使用率達到 100%，且 SQS 佇列積壓。尖峰時段是多變且不可預測的。該公司需要改善應用程式效能。哪種解決方案符合這些要求？

正確答案透過使用 Amazon EC2 Auto Scaling 目標追蹤政策來擴展處理層執行個體，並以 SQS 的 ApproximateNumberOfMessages 屬性作為擴展指標，直接解決了問題的核心。當 SQS 佇列積壓時，表示處理層無法跟上傳入的請求，因此需要增加處理能力。ApproximateNumberOfMessages 能夠反映佇列的積壓程度，使其成為觸發擴展的理想指標，確保處理能力能動態適應不可預測的尖峰負載。 排程擴展不適用於不可預測的尖峰負載。在 DynamoDB 前使用 ElastiCache for Redis 無法解決處理層的瓶頸。新增 CloudFront 分配主要用於快取網路層內容，無法解決處理層的處理能力問題。