Lambda may reuse an execution environment for later invocations of the same function. Anything left in global variables, in the tmp directory, or in unfinished background work can still be there on the next request. Keep per-request data in local variables and clean up anything written to disk.
What the documentation says is reused
After a function finishes, Lambda keeps the execution environment for some time in case another request arrives. When it does, Lambda thaws the same environment. AWS lists three consequences:
- Objects declared outside the handler stay initialized. A database connection opened at startup is reused.
- The tmp directory keeps its content. Each environment gets between 512 MB and 10,240 MB there, and it persists while the environment is frozen.
- Background processes or callbacks that were started and did not finish can resume on reuse.
AWS also notes that a reset after a failed invocation does not clear the tmp directory before the next init phase. So an error does not wipe your disk state either.
Where this becomes a security issue
Reuse is a performance feature, and it is safe in the sense that one function's environment is not shared with other customers' functions. The risk sits inside your own code, between your own requests.
Typical mistakes:
- Storing the current user's identity, token or request body in a module level variable, then reading it from a helper on a later request that does not set it.
- Writing an uploaded file to the tmp directory with a predictable name and reading it back later without checking who created it.
- Caching a result keyed only on part of the input, so one tenant sees another tenant's data.
- Starting an asynchronous call and returning early, so the callback runs during someone else's request and logs or writes with the wrong context.
In a multi-tenant function these become data exposure bugs. The AWS guidance says to avoid global variables for context-specific information and to use a scope local to the handler. That also prevents leaks across invocations.
What is fine to keep global
Clients and connections that carry no per-request state: an SDK client, a configuration object, a compiled regular expression, a cache of public reference data. AWS recommends opening database connections during initialization so they can be reused.
A short checklist
- Search for module level variables that are assigned inside the handler. Each is a candidate for a leak.
- Treat the tmp directory as shared across requests. Use unpredictable names, delete files you create, and never trust that it is empty.
- Include the tenant or user identifier in every cache key.
- Finish all asynchronous work before returning.
- Do not assume the environment lives forever. Lambda terminates environments every few hours for runtime updates and maintenance, even for functions that are invoked continuously.
Quick check
Is the tmp directory cleaned between invocations?
No. Its content remains while the environment is frozen and reused, and a reset after an invoke failure does not clear it either.
Can one customer's function see another customer's tmp files?
The documentation describes each execution environment as isolated. The exposure risk in this post is between requests handled by your own function.
Static analysis can spot some of these patterns. Safeguard offers code scanning alongside dependency scanning, and the free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
