An internal Amazon API Gateway REST API fronts a fragile legacy backend that can handle only a limited number of concurrent requests before it degrades. The provider wants API Gateway itself to reject excess traffic with a throttling response so the backend is protected, and wants the limit applied to one specific high-volume method rather than to the whole stage. Which configuration achieves this?
- ALower the account-level throttle and burst limits for the Region so the whole account is capped, which keeps total request volume to the legacy backend within the level it can tolerate during peak periods.
- BAttach an AWS WAF web ACL with a rate-based rule to the API stage so requests beyond a threshold per source address are blocked before they are forwarded to the legacy backend integration.
- CConfigure a per-method throttle on the high-volume method by overriding its stage method settings with a specific rate and burst, so API Gateway returns throttling responses once that method exceeds the limit. Correct
- DEnable response caching on the high-volume method with a long time-to-live so most requests are served from the cache and never reach the legacy backend, reducing the concurrent load it has to handle.
Why A is wrong: The account-level throttle applies across every API and method in the Region, so it would constrain unrelated APIs as well and is far broader than the single fragile method, which is not the targeted protection requested.
Why B is wrong: A WAF rate-based rule throttles per source IP and applies to the whole stage rather than one method, so it neither targets the specific high-volume method nor enforces a backend concurrency-safe rate as a method throttle would.
Why C is correct: Method-level throttling overrides let you set a rate and burst on just the chosen method, so API Gateway returns a throttling response when that one method exceeds the limit while leaving other methods unaffected, which precisely protects the fragile backend.
Why D is wrong: Caching only helps for cacheable repeated responses and does nothing to cap concurrency for cache-miss or non-idempotent traffic, so the backend can still be overwhelmed and this is not a throttling control.