You are launching a public REST API on Amazon API Gateway with a free tier and a paid tier. How do usage plans give each customer its own rate limit and monthly allowance, and what are the practical limits of that mechanism?

## What a usage plan actually is Stage and method throttles limit *the API*. They cannot tell one caller from another, so a single aggressive customer consumes the shared bucket and everyone else is throttled. A **usage plan** is API Gateway's answer to that: a named object holding - a **throttle** — rate and burst, applied per API key rather than per API, - an optional **quota** — a request count per `DAY`, `WEEK` or `MONTH`, - the set of **API stages** the plan applies to, with optional per-method throttle overrides. You then attach **API keys** to the plan. Each key gets its own token bucket and its own quota counter. Tiering is therefore trivial: create `Free` and `Gold` plans with different numbers and move a customer's key between them. ```bash aws apigateway create-usage-plan \ --name Gold \ --throttle rateLimit=100,burstLimit=200 \ --quota limit=1000000,period=MONTH \ --api-stages apiId=abc123,stage=prod ``` ## Wiring it up Three things must line up or the plan silently does nothing: 1. The **method must require an API key**. If it does not, requests arrive anonymously, no key is identified, and only the stage and account throttles apply. 2. The **caller must send the key**, by default in the `x-api-key` header. The API key source can instead be an authorizer, which is how you attach metering to an identity your authorizer resolved rather than to a header the client controls. 3. The **key must be attached to a plan** that includes the stage being called. A key with no plan is accepted as a key but metered by nothing. When the key's bucket is empty the caller gets the `THROTTLED` gateway response; when its quota is spent it gets `QUOTA_EXCEEDED`. Both are 429 by default. ## The limits of the mechanism **REST APIs only.** HTTP APIs — the cheaper, lower-latency flavour — support route and stage throttling but have no API keys and no usage plans. If per-customer quotas are a product requirement, that requirement alone can decide REST over HTTP, and it is a decision worth stating explicitly in a design discussion because the cost difference is real. **A key is not authentication.** An API key is a plain string identifying a caller for metering. It is not signed, not scoped, and confers no permissions by itself. Anyone holding it can use it. Authentication and authorization are a separate concern — the key answers "whose quota do I decrement", not "is this caller allowed here". **Enforcement is best-effort.** Throttle and quota accounting is distributed, so a caller may occasionally slip slightly past a boundary. That is fine for protecting a backend and for a commercial guardrail; it is not an exact meter. If you bill per request, bill from your own usage records or from access logs, not from the assumption that the quota was enforced to the request. **Quotas are blunt.** A customer that exhausts a monthly quota on day three is simply refused for twenty-seven days. Real products soften this with usage notifications, overage tiers, or a plan change workflow — none of which API Gateway provides. Usage data is retrievable per key and per day, which is what you build those workflows on. **Key distribution is your problem.** Creating, rotating and revoking keys per customer is an onboarding workflow you have to build and secure; a leaked key is a stolen quota until it is revoked. ## How to reason about it in an interview The strong answer distinguishes the three jobs that are easy to blur together: *authenticating* a caller (an authorizer), *identifying whose allowance to charge* (the API key and its usage plan), and *protecting the backend from total load* (stage, method and account throttles). Usage plans do the middle job well and the third job per-caller — but they do not do the first at all, and relying on a key as a secret is the single most common mistake with this feature.