A municipal permitting backend scales an Auto Scaling group using average CPU only. During filing deadlines the SQS work queue grows for minutes while CPU stays modest, so citizens see long waits. Which scaling-policy improvement best restores elasticity?
Select an answer to reveal the explanation.
Short Explanation
CPU can look sleepy while the inbox is on fire. For queue-driven permitting work, scale on how deep the backlog is—not how warm the CPUs feel. That is the difference between keeping up and watching tickets pile up.
Full Explanation
An Auto Scaling group for a municipal permitting backend that scales only on average CPU will not react when an SQS work queue grows while CPU stays modest during filing deadlines. Retargeting scaling policies to queue-depth or backlog-per-instance metrics—with safe min/max bounds—makes capacity track pending permit jobs rather than CPU alone, restoring elasticity citizens feel as shorter waits. That improvement works because the true backlog signal for queue workers is unfinished work, not host busy percentage. Removing Auto Scaling and scheduling a fixed maximum fleet every night fails when deadlines do not align to the schedule. Scaling exclusively on S3 request metrics when work arrives on SQS fails conceptually by watching the wrong service. Lowering DesiredCapacity to one instance so CPU averages rise faster fails by reducing capacity during the very backlog event. Exam caveat: pair queue-depth scaling with cooldown and max bounds to avoid overscale on poison-message piles; also alarm on DLQ growth so scale-out is not masking bad messages. Operational check: publish ApproximateNumberOfMessages metrics into the scaling policy, simulate a filing-deadline flood in nonprod, confirm new instances start before citizen wait SLOs breach, and set max capacity consistent with downstream DB limits.