I have been thinking about this for a while as it would avoid having cloudfront making a origin call to the backend server for db reads on data that does not change frequently. I am trying to figure out why this is a bad idea .
Cache invalidation is tricky. Avoid it by ttl-expiring caches as frequently as budget allows. We, instead, employ a (probably over-engineered) hand-rolled set-reconciliation algorithm to match our read/write patterns.
For origin-requests you get 50MB. See https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope...
And "The same Lambda execution environment may be reused by multiple Lambda invocations to optimize performance. The /tmp area is preserved for the lifetime of the execution environment and provides a transient cache for data between invocations. Each time a new execution environment is created, this area is deleted."
https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-...
https://aws.amazon.com/blogs/compute/choosing-between-aws-la...
Regular Lambda (not edge) are just container images up to 10 GB in size.
There's also the layers thing. A function can use up to five layers at a time. The total unzipped size of the function and all layers can't exceed the unzipped deployment package size limit of 250 MB. Can update separately from the container, almost as fast as a regular fs.
And finally it has access to EFS which is faster than S3.