A citizen mobile API on API Gateway occasionally sees abusive request spikes that drive expensive downstream scale-out. Which control best caps that cost risk?
Select an answer to reveal the explanation.
Short Explanation
A bouncer at the door is cheaper than rebuilding the gym every time a crowd rushes in. API Gateway throttling caps abusive spikes before backends scale into debt.
Full Explanation
A citizen mobile API on Amazon API Gateway that occasionally sees abusive request spikes can force Lambda, containers, or downstream RDS/DynamoDB to scale out expensively. Configuring API Gateway throttling—account and stage limits, usage plans, and per-key quotas as needed—caps request rates at the edge of the API so abusive or buggy clients cannot indefinitely amplify backend cost. Throttling returns controlled 429 responses rather than unbounded scale events, protecting municipal budgets during protest traffic, scraper bursts, or misbehaving mobile builds.
Removing all throttling so every abusive client gets unlimited concurrency fails by concept: it maximizes cost and outage risk. Replacing API Gateway with unrestricted public SSH on database hosts abandons API management and creates a severe security exposure. Disabling CloudWatch metrics so spike-driven scale events are "not billed" does not stop scale charges and blinds operators—false economy.
Exam caveat: throttling must be set high enough for legitimate peak citizen use (tax deadlines, permit lotteries) while still bounding abuse; pair with WAF, auth, and sensible backend concurrency limits. Throttling is cost protection, not a substitute for application-layer authorization.
Operational check: baseline normal and peak RPS from access logs, set stage burst/rate limits and usage plans for partner keys, load-test legitimate peaks, simulate abusive floods and confirm backends do not scale without bound, and correlate API Gateway 429 counts with downstream cost anomalies in Cost Explorer.