A 311 application stack includes an EC2 Auto Scaling group and a DynamoDB table. The architect must define when capacity grows. What is the sound approach?

High-performing architectures grow capacity when measurable application signals cross thresholds. For a 311 stack with an EC2 Auto Scaling group and a DynamoDB table, define explicit scaling policies and metrics—for example request count or CPU for EC2, and consumed capacity or Application Auto Scaling targets for DynamoDB—so each tier reacts in near real time to its own pressure. Clear metrics and thresholds are the sound Task 3.2 approach to deciding when municipal capacity should grow. Scaling EC2 only when DynamoDB throttle events appear in printed weekly reports fails because weekly offline review is far too slow for 311 responsiveness and uses a database symptom as the sole compute trigger. Increasing DynamoDB capacity only after EC2 CPU averages below 5% for a month fails conceptually: that inverted, lagging signal does not indicate DynamoDB pressure and can leave the table under-provisioned during citizen spikes. Disabling all CloudWatch metrics to avoid noisy scaling decisions fails because without metrics there is no automated, timely scale action—noise control belongs to careful metric choice and alarms, not blindness. Exam caveat: each service scales on its own signals; do not assume one tier’s metric correctly represents the other, and watch for oscillation from thresholds that are too tight. Operational check: implement ASG and DynamoDB Application Auto Scaling policies with documented thresholds, simulate a 311 surge, verify both tiers scale before SLOs breach, and review CloudWatch dashboards after the test for thrash or lag.