A permitting office's asynchronous document-inference endpoint accumulates a growing backlog of queued requests during peak filing season, and the current Auto Scaling policy reacts to a per-instance invocation-rate metric borrowed from a real-time endpoint. Which metric should the scaling policy target instead for this asynchronous workload?

Asynchronous inference queues requests and processes them as capacity becomes available, so the metric that reflects real pressure on the system is how many requests are backed up relative to running instances — which is exactly what ApproximateBacklogSizePerInstance measures, making it the appropriate target-tracking metric for this pattern. InvocationsPerInstance and ModelLatency are both designed around the real-time endpoint pattern, where requests are handled synchronously as they arrive; carrying either metric over to an asynchronous queue measures the wrong thing, since a queue can have a large backlog even while individual processing latency looks fine. CPUUtilization reflects host-level resource pressure rather than queue depth, and an asynchronous endpoint can have a growing backlog while CPU usage stays moderate if the bottleneck is elsewhere (for example, download time for large filing documents), so it's an unreliable proxy for backlog. Scope caveat: because asynchronous inference tolerates some delay, teams often pair backlog-based scaling with a target that reflects an acceptable wait time rather than trying to drive the backlog to zero. Operational check: during a simulated peak-filing load test, confirm the backlog metric triggers scale-out before queued requests accumulate long enough to breach the office's target turnaround time.