A burst of credential-stuffing attempts hits the citizen login API in front of API Gateway/CloudFront. Which edge control is commonly proposed?
Select an answer to reveal the explanation.
Short Explanation
When the login door gets shoulder-charged, put a rate gate at the edge—AWS WAF—before API Gateway or CloudFront spends cycles. Turning off logs or passwords-in-public-buckets helps the attacker, not the city.
Full Explanation
Credential-stuffing bursts against a citizen login API fronted by API Gateway or CloudFront are commonly mitigated with AWS WAF rate-based rules at the edge. Rate-based rules throttle abusive request rates to login endpoints before traffic overwhelms Cognito, Lambda authorizers, or origin data stores. That edge control reduces attack volume while account security features and monitoring continue to protect individual identities.
Disabling CloudWatch Logs hides attacker behavior instead of slowing it. Removing authentication from the login API to reduce 401 noise abandons the control under attack. Storing citizen passwords in a public S3 bucket for “faster validation” is a catastrophic exposure unrelated to edge rate limiting.
Exam caveat: WAF complements—not replaces—MFA, breached-password detection, bot control, and sensible Cognito app client settings; tune thresholds so legitimate municipal traffic spikes are not locked out. Operational check: enable a rate-based rule on the login path in a test stage, generate abusive request rates, confirm WAF blocks with 403, and verify legitimate low-rate logins still succeed while metrics show blocked requests. For municipal workloads, document the chosen pattern in the runbook so the next on-call engineer applies the same control instead of inventing a weaker shortcut under pressure.