Control external API consumption with an API key, usage plan, throttling, and quotas
A company creates an Amazon API Gateway API and shares the API with an external development team. The API uses AWS Lambda functions and is deployed to a stage that is named Production. The external development team is the sole consumer of the API. The API experiences sudden increases of usage at specific times, leading to concerns about increased costs. The company needs to limit cost and usage without reworking the Lambda functions. Which solution will meet these requirements MOST cost-effectively?
Community Votes
100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
A usage plan attaches throttling limits and quotas to an API key, so the control is applied at the API Gateway stage rather than inside the function code, and a single external consumer means one key with a defined budget is sufficient.
An API Gateway API backed by Lambda functions is shared with an external development team as its sole consumer, and usage spikes at specific times are raising cost concerns. Cost and usage must be limited without changing the Lambda functions.
Adding provisioned concurrency. Provisioned concurrency keeps functions warm to reduce latency, which increases cost rather than limiting it, and it does nothing to cap how many requests the consumer can send. Routing through SQS also requires modifying the Lambda functions, which the requirement explicitly excludes.
Community Discussion (6 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The requirement is to limit cost and usage without reworking the Lambda functions, so the control has to live in API Gateway. Creating an API Gateway API key and a usage plan lets the company define throttling limits, which cap the request rate, and quotas, which cap the total requests over a period, and associating the plan with the Production stage and the API key means every call made with that key is subject to those limits. The external team receives only the API key, and because they are the sole consumer a single key with a defined budget is the whole control surface. When the limit is reached the requests are throttled rather than billed, so the cost spike cannot recur, and nothing inside the Lambda code changes.Why the Other Options Are Wrong
A: Introducing SQS between API Gateway and Lambda requires modifying the Lambda functions to consume from the queue, which directly violates the requirement not to rework them, and the option also contradicts itself by setting the queues to invoke the functions as well. B: Provisioned concurrency keeps execution environments initialised so they respond faster, which raises the baseline cost rather than limiting consumption, and registering Lambda functions with Application Auto Scaling to vary provisioned concurrency is a scaling mechanism rather than a usage cap. C: An API key with a WAF rate-based rule and a custom aggregation on the X-API-Key header can throttle by header, but WAF is a request filter that adds a layer to operate and is being used to emulate what a usage plan does natively, so it is not the most cost-effective mechanism for setting per-consumer quotas.Community Comment Notes
The community voted 100 to 0 for D, and the top-voted comments linked the API Gateway usage plans documentation and explained that usage plans set throttling limits and quotas on API keys, which directly controls the requests per second and per day the external team can make. Another commenter framed the concept plainly, that a usage plan defines who gets how much API usage, and a further comment confirmed the key plus usage plan combination as the effective way to control API consumption.Official Reference
Related Analysis
Practice All SAP-C02 Questions
Access 85 questions with complete answers and detailed explanations.
View Full SAP-C02 Practice Test →