A review of tenant isolation in reusable AWS Lambda environments. It separates shared clients from request state, explains temporary storage and reset behavior, and treats SnapStart uniqueness as a distinct initialization concern.
At a glance
Key findings
- Reusable SDK clients and mutable caller identity have different lifetimes. Keep request-owned security state out of shared environment state.
- Temporary files can survive reuse and some reset paths. Encryption at rest does not decide which invocation may read a file.
- SnapStart can restore initialized state into multiple environments. Generate values that must be unique at an appropriate later point.
Separate the reusable client from the current caller
Imagine a function that serves two customer organizations. It caches an SDK client to avoid rebuilding it on every request, then also stores the most recently authenticated tenant beside that client. The first choice can be a useful performance optimization; the second can make a later request depend on an earlier caller's state. Review those lifetimes separately instead of categorizing every global variable as either good or bad.
AWS recommends taking advantage of execution environment reuse for suitable clients and connections while warning against retaining user data or other security-sensitive information there. That guidance is a starting point for a state inventory. For every value outside the invocation handler, ask whether it is configuration, a reusable service object, a cache entry, or information owned by one request. [1]
A tenant identifier, authorization result, selected data key, or mutable request header should not become an implicit default for the next invocation. Pass the current request's context explicitly through the relevant calls and derive it from trusted authentication inputs. This proposed design keeps a missing identity visible as an error instead of letting the application fall back to whichever identity happened to be used previously.
Distinguish reuse from a reset
Lambda can freeze an execution environment after work finishes and later reuse it. A reset is a different lifecycle event: the runtime is reinitialized, but the temporary directory is not necessarily cleared. AWS documents these distinctions in its execution environment lifecycle. Do not assume that a handler returning, a process restarting, and an environment being replaced all have the same effect on application state. [2]
Inventory state by storage location and owner. Include module variables, connection objects, dependency caches, files, and any background work the function starts. For each item, state whether reuse is acceptable, whether the next invocation must revalidate it, and what happens if cleanup fails. A request-specific cache key is not a complete boundary if another code path can enumerate or reuse the underlying value without the same authorization decision.
Review error paths as carefully as successful returns. A function can leave a partially written file, a modified client header, or an unfinished operation after an exception. Clearing state at the end of the normal path does not cover those cases. Prefer designs where request state is local and a subsequent invocation starts by establishing its own identity and dependencies, rather than depending on previous cleanup having completed.
State lifetimes in a reusable execution environment
The end of an invocation does not give every value the same lifetime or the same owner.
Source. AWS Lambda best practices, lifecycle, storage, and SnapStart documentation [1][2][3][4][5].
Method. Original lifecycle comparison. Reuse is possible, not guaranteed. Reset does not imply preservation of every in-memory value. No claim of cross-account environment sharing or observed data leakage is made.
Accessible table and figure data
| State | Relevant lifetime | Review decision |
|---|---|---|
| Service client | May survive a warm reuse | Keep mutable caller data separate |
| Request identity | Belongs to the current invocation | Derive and validate for each request |
| Temporary file | Can survive reuse and reset | Check ownership and bounded cleanup |
| SnapStart initialization | Can be restored into multiple environments | Handle values that must be unique |
| State | Relevant lifetime | Review decision |
|---|---|---|
| Service client | May survive a warm reuse | Keep mutable caller data separate |
| Request identity | Belongs to the current invocation | Derive and validate for each request |
| Temporary file | Can survive reuse and reset | Check ownership and bounded cleanup |
| SnapStart initialization | Can be restored into multiple environments | Handle values that must be unique |
Treat temporary files as application data
Lambda's configurable ephemeral storage spans 512 to 10,240 MB in one-megabyte increments. It is specific to an execution environment and encrypted at rest with an AWS-managed key. These properties describe storage capacity and protection, not an authorization rule between customer requests handled by the function. A later invocation running application code can still encounter a file left by an earlier invocation. [3]
Use opaque, collision-resistant identifiers for request-owned temporary paths and keep their relationship to the authorized request explicit. Avoid a shared filename such as latest-report when reports can contain different customers' data. The path design should also account for retries and partial writes. Before returning a download or processing an existing file, verify that the file belongs to the current operation rather than assuming its presence establishes ownership.
Keep cleanup as defense in depth, with bounded retention and appropriate error handling. Do not make tenant separation depend solely on a deletion in the final line of a handler. Where the application needs durable or shareable state, move it to a store whose access decisions and object ownership can be reviewed directly. Temporary storage should not become an undocumented cross-request database because it happened to survive a test.
Review SnapStart as a different initialization boundary
SnapStart can capture initialized memory and disk state and restore that snapshot into new execution environments. AWS warns that values which must be unique need suitable handling, such as generation after initialization or supported runtime hooks. A request identifier, secret, or connection-specific value created once during initialization should therefore be reviewed for the consequences of copying that state into multiple environments. [4]
Separate stable configuration from values that represent a new instance or operation. Review the libraries that generate random values and their documented snapshot behavior rather than inventing a timestamp-based substitute for a cryptographically secure generator. Where a post-restore hook is used, include its failure path in the design. A hook's existence does not prove that every request-specific value was moved out of the captured initialization phase.
SnapStart also has compatibility limits. AWS documents supported runtimes and exclusions, including lack of support for ephemeral storage above 512 MB. Do not combine the ordinary function storage maximum with an assumption that every SnapStart configuration supports it. Review the actual function version and selected features before interpreting a successful ordinary Lambda test as evidence for the snapshot-enabled deployment. [5]
Alternate tenants in a controlled fixture
Build a nonproduction fixture with synthetic tenant A and tenant B, distinct records, and identifiers that make accidental reuse easy to recognize. Invoke an allowed operation for A, then a different allowed operation for B. Include an error after temporary data is created, a missing identity, and a repeated operation. The expected result should describe which data each invocation may read and which state may remain reusable.
Observe whether the exercise actually reused an environment before drawing conclusions about that path. Repeated requests alone do not guarantee that they reached the same environment. Use sanitized lifecycle observations and keep the result scoped to what occurred. Test fresh initialization separately. If SnapStart is enabled, add cases for restored state and values that are supposed to be unique rather than treating ordinary reuse as an equivalent experiment.
Inspect returned data, relevant storage ownership, and authorization decisions without collecting real customer information. Look for stale headers, reused object identifiers, leftover files, and a missing identity that unexpectedly succeeds. A fixture that returns the right response but leaks request content into shared logs is still incomplete. State which observation channels were reviewed and which remain outside the exercise.
Make state ownership part of the performance review
When proposing a new cache or reusable object, include its lifetime and authorization assumptions with the performance rationale. State the cache key, invalidation rule, tenant boundary, and behavior when the expected context is absent. This gives reviewers a way to accept safe reuse without treating every optimization as a security exception or rejecting all shared initialization indiscriminately.
Revisit the inventory when adding a library, changing an SDK credential provider, introducing temporary report generation, or enabling SnapStart. Dependencies can introduce state outside the handler even when application code appears request-local. Keep the test cases that cover the relevant ownership boundary alongside the function's ordinary tests so a future optimization cannot silently erase that expectation.
The desired result is a function whose reusable infrastructure remains useful while every invocation establishes its own authority. A healthy connection pool is compatible with that design; an implicit last customer is not. Document the distinction in terms of the actual variables, files, and stores the application uses. This article addresses application state within a function, not an alleged failure of AWS isolation between customers.
Method and provenance
Primary documentation reviewed on August 28, 2026. The article combines the cited platform behavior with an original review procedure and visual explanation. Suggested acceptance cases are not reported experiments.
No function, tenant-isolation test, reset, or SnapStart restore was executed. The hypothetical failure concerns application-owned state within a function. Actual reuse, dependency behavior, runtime support, and authorization rules require verification in the deployed configuration.
AI assistance. AI assistance was used for source research, drafting, editorial checks, and figure preparation. No human technical review or production experiment is claimed.
Published under the Cloud Security Desk organizational byline. Read the series policy.
References
- AWS Lambda function best practices Amazon Web Services. Accessed .
- AWS Lambda execution environment lifecycle Amazon Web Services. Accessed .
- AWS Lambda ephemeral storage Amazon Web Services. Accessed .
- AWS Lambda SnapStart uniqueness Amazon Web Services. Accessed .
- AWS Lambda SnapStart compatibility Amazon Web Services. Accessed .