When authorizer caching is on, API Gateway stores the policy your Lambda authorizer returned and reuses it, without calling the function again. If that policy covers only the method being called, later requests to other methods with the same cache key can be denied, or allowed wrongly if the policy is too wide.
How the flow works
A client calls a method on the API with a bearer token or request parameters. API Gateway calls your Lambda authorizer. The function authenticates the caller and returns an IAM policy and a principal identifier. API Gateway evaluates the policy: if access is denied it returns a status such as 403, otherwise it invokes the method. If you turn on authorization caching, API Gateway caches the policy so the authorizer function is not invoked again for matching requests.
AWS includes a specific instruction: make sure your policy is applicable to all resources and methods across your API.
Why scope matters
Suppose the authorizer returns an Allow policy whose resource is the exact method ARN of the current request, and the cache holds it. A later call from the same cache key to a different method is evaluated against the cached policy, which does not name that method. The result is an unexpected denial that looks like a random permission bug.
The opposite error is worse. If you return Allow for a wildcard resource without checking what the caller should reach, a cached policy grants access across the whole API for the cache period. Decide the policy per caller role, not per request, and make it as narrow as the role allows while still covering every route that role may use.
Token versus request authorizers
There are two types. A token authorizer receives a bearer token such as a JWT or OAuth token, and when caching is on, the token header name is the cache key. A request authorizer receives headers, query string parameters, stage variables and context variables, and every configured identity source contributes to the cache key, in order.
AWS recommends request authorizers, since they can use several identity sources and build finer cache keys. With caching on, if a specified identity source is missing, null or empty, API Gateway returns 401 without calling the function. Changing any cache key part and redeploying makes the authorizer discard the cached policy.
Design guidance
- Return a policy derived from the caller's role, covering the routes that role can use.
- Include in the cache key everything that changes the decision: user or tenant identifier, not just a generic header.
- Keep the cache time short while you learn the traffic pattern. A revoked user keeps access until the cached policy expires, which is a security trade for speed.
- Treat the optional context object as data your backend receives. Do not put sensitive values in it unless needed.
- Test an allowed route, a denied route and a route the role can reach but the caller did not call first.
The trade you are making
Caching cuts latency and authorizer cost. It also delays the effect of permission changes. If you must revoke access immediately, shorten or disable caching on sensitive routes.
Quick check
Why does one route fail after another succeeded?
Often because the cached policy only names the first route. Return a policy that covers every route the caller's role may use.
Which authorizer type does AWS recommend?
The request type, because it can use multiple identity sources and finer cache keys.
Sources
Last reviewed: 19 October 2026.
