Caching is useful to improve the performance of repeated access to data, help take pressure off downstream systems or avoid repetition of complex calculations.
Lambda is (mostly) stateless and transparently distributed. Caching inside functions is possible, but from an architectural perspective we must assume that function instances are ephemeral. Any data cached at the function level exists is tied to an internal instance that we have limited control over.
Improve performance by caching at the API Gateway. API Gateway can be configured to automatically cache the output of a Lambda function. As the cache is managed at the API layer, the cache is persistent across requests, independent of Lambda provisioning or concurrency.
When caching is enabled, API Gateway will store the response of the integrated lambda endpoint in a fast memory-backed cache. Subsequent requests within the nominated time-to-live return the response from the cache, rather than invoke the Lambda again. The cache can be configured and to use any of the request path, headers, or query string parameters as a cache key.
The API Gateway Cache can be combined with an Gateway Authorizeriter.
The cache is global in the sense that it does cache for all matching requests BUT you can also cache using a value unique to an individual tenant.
As you can cache on headers, you can associate the cache with a tenant token (api key or bearer token for example) to create per-tenant caching.
Once you know the tenant id, you can do things like have the authorizer check the database to confirm access rights to a particular object, returning a policy, the policy is then applied before returning values from the cache.
|API Gateway||Data Transfer|
|API Gateway*||Cache Instance Hour|
|Lambda||(Compute Time x Memory)|
|CloudWatch||Log Data Ingestion|
* Caching is not eligible for the AWS free tier.