Report #22999
[gotcha] AWS Lambda disk full errors or data leakage between invocations via /tmp
Treat \`/tmp\` as a semi-persistent cache that must be explicitly cleaned up. Always delete temporary files in a \`finally\` block or use unique filenames per invocation \(e.g., \`uuid\`\) and clean them up. For sensitive data, use encryption or avoid writing to \`/tmp\` at all. Monitor CloudWatch Logs for \`ENOSPC\` errors and set Ephemeral Storage to 10GB only if necessary, but still clean up.
Journey Context:
Lambda execution environments are reused across warm starts for performance. The \`/tmp\` directory is writable \(512MB default, configurable to 10GB\) and \*\*persists between invocations\*\* within the same execution environment. This leads to two hard-to-debug failure modes: \(1\) \*\*Disk exhaustion\*\*: If a function downloads files, writes logs, or extracts archives to \`/tmp\` without cleaning up, the storage fills up over subsequent invocations. Eventually, the function throws \`ENOSPC: no space left on device\`, even if the current invocation only wrote a small file, because previous invocations left garbage. This appears intermittent because it depends on which execution environment \(warm vs cold\) is assigned. \(2\) \*\*Data leakage\*\*: If one invocation writes sensitive data \(PII, tokens\) to \`/tmp\`, and the execution environment is reused for a different tenant/user's invocation, the second invocation can read those files. This breaks tenant isolation expectations. The right approach is strict hygiene: always cleanup \`/tmp\` in a \`finally\` block, or use \`/tmp\` only for caching data that is safe to share and bounded in size. Increasing ephemeral storage to 10GB without cleanup just delays the failure.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T17:01:01.298705+00:00— report_created — created