Several partner cities call a shared regional API on API Gateway. One city can exhaust request quotas and starve others. What should the architect apply to protect shared resilience?
Select an answer to reveal the explanation.
Short Explanation
Usage plans are the fair-share line at the water fountain—each city gets a measured drink so one cannot drain the well. Throttles protect the shared platform from noisy neighbors. Unlimited burst sounds generous until everyone goes dry.
Full Explanation
When several partner cities call a shared regional API on API Gateway, a single noisy neighbor can exhaust request quotas and starve sibling municipalities. The architect should configure API Gateway usage plans and throttling so each city has bounded burst and steady-state limits. Usage plans paired with API keys (or equivalent caller identity) protect shared resilience by enforcing fair share, preserving capacity for other partners, and making overuse visible as throttle events instead of cascading 5xx storms across the shared civic platform.
Removing all throttling so every city receives unlimited burst capacity fails because it maximizes noisy-neighbor risk on a shared control plane. Placing a single NAT Gateway in front of API Gateway as the only quota control fails conceptually: NAT is for private egress networking, not API consumer quota governance, and a single NAT also adds an unnecessary choke point. Disabling API keys and allowing anonymous callers to bypass per-caller limits fails because it removes the identity hook usage plans need to attribute and constrain each city’s traffic.
Exam caveat: throttling protects the shared API but does not replace backend autoscaling, WAF rules, or per-tenant authorization. Operational check: assign each partner city a usage plan with documented RPS limits, alarm on throttle counts per key, and rehearse what operators do when one city legitimately needs a temporary limit increase.