Citizen traffic risks being blocked when the city API approaches API Gateway throttle limits or STS session quotas. What should developers alarm on?
Select an answer to reveal the explanation.
Short Explanation
Waiting until the gate is slammed shut is a rough day at city hall. Alarm when you're closing in on API Gateway throttle or STS session limits—not after citizens bounce. Headroom alerts beat outage tickets.
Full Explanation
Citizen traffic risks being blocked when the city API approaches API Gateway throttle limits or STS session quotas, so developers should create alarms that fire as utilization approaches those service quotas—not after a full day of failures. Proactive quota alarms protect availability by giving municipal operators time to request increases, shed load, or fix credential churn before citizens are locked out.
Only alarming after all citizen requests have already failed for a full day is too late for availability management.
Alarming exclusively on S3 bucket size growth in an unrelated account ignores the quotas that threaten the API.
Removing API Gateway throttling entirely so quota alarms are never needed can overwhelm backends and is not a substitute for quota monitoring.
Exam caveat: Monitor approaching service quotas that threaten availability (API throttling, STS, concurrency) with CloudWatch alarms.
Operational check: Identify relevant quota metrics/usage, set alarms at e.g. 70–80% of limit, route to SNS on-call, rehearse the quota-increase or load-shed runbook, and verify alarms clear after mitigation. Keep the civic/municipal context in mind: enrollment and tax deadlines create sharp traffic spikes that collide with unchanged default quotas.