Error: ENOSPC: no space left on device, write

What it means

Every Lambda execution environment gets a writable /tmp directory, sized by the function's ephemeral storage setting — 512 MB by default, configurable up to 10 GB. It is real disk, it is fast, and it is the only writable location in the filesystem. ENOSPC means a write to it failed because it was full.

The detail that makes this error behave strangely is lifetime. /tmp belongs to the execution environment, not to the invocation. Lambda reuses environments to avoid cold starts, and everything in /tmp persists across that reuse. A function that writes a 20 MB file and does not delete it will succeed twenty-five times and fail on the twenty-sixth — on that container. A different container, freshly started, handles the same request perfectly.

That produces a failure pattern that is genuinely confusing when observed one invocation at a time: an error rate that is neither zero nor total, that does not correlate with input, and that appears to move around. Each container independently accumulates until it hits the wall, then keeps failing every request routed to it until it is recycled. Seen per-invocation it looks random; seen per-execution-environment it is a clean sawtooth — a run of successes, a cliff, and then a fresh container starting the climb again.

The same persistence is also useful, and worth keeping rather than fighting. Caching a font set, a model file, or a downloaded certificate in /tmp on the first invocation and reusing it on subsequent ones is a legitimate and effective optimisation — that is exactly what warm containers are for. The distinction is between a bounded cache, which reaches a stable size, and unbounded accumulation, which does not. Files named after the request ID are the classic version of the second: every invocation adds one, and nothing ever removes it.

What it looks like in CloudWatch

This is the shape the failure arrives in: the lines of one invocation scattered among everything else the log group received at the same moment.

The panel on the right is generated by running the excerpt on the left through the same parser that powers the free web stitcher — it is what the tool actually produces for this input, not an illustration of it.

How to confirm it from the logs

Look at when in the container's life it happens. ENOSPC on a cold start means one invocation genuinely wrote more than the ephemeral storage allows. ENOSPC after many successful invocations on the same execution environment means accumulation — each run leaving a file behind until the sum crosses the limit.

The pattern to look for across a log stream is a run of successes followed by a cliff, then another run of successes on a fresh container. That sawtooth is the signature, and it is invisible if you look at the failing invocation alone: nothing in it explains why the same code worked a minute earlier.

Causes, most likely first

Fixes

jsimport { mkdtemp, rm } from "node:fs/promises";
import { tmpdir } from "node:os";
import { join } from "node:path";

export const handler = async (event) => {
  const dir = await mkdtemp(join(tmpdir(), "job-"));
  try {
    await download(event.key, join(dir, "input.bin"));
    return await transform(dir);
  } finally {
    // Runs on success and on failure — the failure path is the one that matters.
    await rm(dir, { recursive: true, force: true });
  }
};

yamlResources:
  TranscodeFunction:
    Type: AWS::Serverless::Function
    Properties:
      EphemeralStorage:
        Size: 2048   # MB; 512 default, 10240 maximum

jsimport { pipeline } from "node:stream/promises";

// No intermediate file, so nothing to accumulate or clean up.
await pipeline(
  (await s3.send(new GetObjectCommand(source))).Body,
  createGunzip(),
  uploadStream(destination)
);

jsimport { readdir, stat } from "node:fs/promises";

const names = await readdir("/tmp");
const sizes = await Promise.all(
  names.map(async (name) => (await stat(`/tmp/${name}`)).size)
);
console.log("tmp", { files: names.length, bytes: sizes.reduce((a, b) => a + b, 0) });

Also seen as

The same underlying failure, worded differently by a different runtime, SDK version, or logging layer. All of these land here — there is no separate page for each phrasing.

Related errors

Errors that show up alongside this one, or that people mistake for it.

References

• AWS Lambda Developer Guide — Configuring ephemeral storage
• AWS Lambda Developer Guide — Lambda execution environment